[strongSwan] [Strongswan5.0.1]Strongswan is not sending phase2 Identification payload in Ikev1 for IPv6, which leads to negotiation failure

[Martin Willi]

Hi,

> In response to quick mode message of IKev1, strongswan is sending a
> quick mode message with no identification payload, which results in
> negotiation failure for transport mode.

If no ID payload is sent, the identities are implicitly the same as the
outer address without any port/protocol restrictions. Have a look at [1]
for the details.

> Router1 is sending Quick mode message with identification data as
> 2007:1234::4/ffff:ffff:ffff:ffff::, but in response to quick mode,
> strongswan is changing identification data as
> 2007:1234::4/2007:1234::ffff:ffff:ffff:ffff, which results in
> negotiation failure(ID mistmatch).

Instead of sending an ID mismatch error, strongSwan tries to narrow
quick mode IDs, as it is done with IKEv2. This probably won't work with
other implementations, but should not harm as the ID payload wouldn't
match otherwise.

>     leftsubnet=2007:1234::5/64
>     rightsubnet=2007:1234::4/64

These don't look like valid subnet definitions. You can't configure IPv6
prefixes here, but networks in CIDR notation.

Regards
Martin

[1]http://tools.ietf.org/html/rfc2409#section-5.5