Hi misc@, I'm using iked to establish ipsec tunnels on a multi-homed OpenBSD system (classical failover setup). iked is used to initialize key exchanges between various servers (which run strongswan/charon for IKE via ikev2).
The iked.conf basically consists of entries like ikev2 active esp from $localsubnet to $remotesubnet peer $peerip The thing that I've noticed is that whenever iked initiates the IKE, the following line is logged: ikev2_msg_send: IKE_SA_INIT request from 0.0.0.0:500 to $peerip:500... The strongswan server on the peer then detects that a NAT is in place, while the iked detects no such thing. This leads to the OpenBSD system expecting/sending ESP packets while the peer expects and sends udp-encapsulated ESP packets on port 4500. This leads to a non-working ipsec configuration (even though it probably shouldn't matter). If, on the other hand, the very same configuration is used, but the IKE is initialized by the peer, then iked logs: ikev2_msg_send: IKE_SA_INIT request from $interfaceip:500 to $peerip:500 ... In this case, no NAT is detected and everything works as expected. I'm neither an expert on ipsec and its related protocols, and neither are my C skills sufficient to understand the code behind iked, but it seems that iked doesn't include the proper NAT detection IP if multiple routes/interfaces are present. Clearly, this can be avoided if one adds the "local $interfaceip" statement to the entries in iked.conf, but this would require two configurations, one for each interface and a restart of iked when failover occurs (at least as far as I can tell). In fact, looking iked's debug output, one gets ikev2_nat_detection: local source 0x17284e621a47c05d 0x0000000000000000 0.0.0.0:500 w/o the "local" statement and ikev2_nat_detection: local source 0x5b69fb18d2980778 0x0000000000000000 10.10.0.151:500 w/ the "local" statement in place. Is this behaviour intentional i.e. is there no way around specifying a fixed local IP? The primary interface has a dynamic IP, which would require me to recreate the iked.conf whenever an IP-change or failover has been detected (which is how I've worked around the problem right now, but this feels like a hackish solution). Also, shouldn't iked accept udp-encapsulated ESP regardless of whether a NAT was detected? RFC 5996 at least mentions in section 2.23 that "implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected.", but as far as I can tell iked discards the UDP-encapsulated ESP packets. Cheers, Sascha [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
