<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Courier New">Hi Tobias,<br>
      <br>
    </font><font face="Courier New">Thank you very much for your help
      and detailed description.<br>
      I checked the responder's daemon.log, and found the the same error
      messages you've mentioned.<br>
      I think, our customer will accept this fact and will choose a
      different integrity algorithm or switch to ESP.<br>
      <br>
      Best regards,<br>
      Gyula<br>
    </font><br>
    <br>
    <div class="moz-cite-prefix">On 2016.11.10. 19:08, Tobias Brunner
      wrote:<br>
    </div>
    <blockquote
      cite="mid:961f66f4-ac1a-b850-881e-f337b22a163d@strongswan.org"
      type="cite">
      <pre wrap="">Hi Gyula,

</pre>
      <blockquote type="cite">
        <pre wrap="">I'm running the test between two identical Debian 8.6 VMs.
Both have the same version of strongSwan (v5.5.1), compiled withe the
same switches.
</pre>
      </blockquote>
      <pre wrap="">
I was able to reproduce this in our testing environment.  On the
responder you should have seen the following messages:

</pre>
      <blockquote type="cite">
        <pre wrap="">[CHD] no keylength defined for AES_128_GMAC
[IKE] unable to install inbound and outbound IPsec SA (SAD) in kernel
</pre>
      </blockquote>
      <pre wrap="">
These are caused because for AES-GMAC the key length is not explicitly
encoded in the proposal, instead each length has its own identifier
(compared to ESP with AES-GCM or NULL-AES-GMAC where there is only one
identifier and the key length is transmitted).  But when deriving keys
we currently don't map these identifiers back to the required key length.

Another issue is that the kernel-netlink plugin currently doesn't map
these identifiers to algorithm names either, so the plugin isn't able to
install the SAs after deriving the keys.

However, as it turns out, the Linux kernel can't actually be configured
to use AES-GMAC with AH, only with ESP.  So what you want to do is
currently not possible at all.

If you are not dead set on using AH you could use esp=aes128gmac
instead, to configure ESP with NULL encryption and AES-GMAC authentication.

Regards,
Tobias


</pre>
    </blockquote>
    <br>
  </body>
</html>