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 _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
