Paul, for IKEv2, according to RFC 5996: "If Network Address Translation Traversal (NAT-T) is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP-encapsulated ESP and non-UDP-encapsulated ESP packets at any time. Either side can decide whether or not to use UDP encapsulation for ESP irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST use UDP encapsulation for ESP."
I'm not aware of similar statements that you could appeal to for IKEv1, but in the long run you're going to need to accommodate this behavior anyway, at least for IKEv2. Scott Moonen ([email protected]) Secure Hybrid Cloud and z/OS Communications Server http://www.linkedin.com/in/smoonen From: Paul Wouters <[email protected]> To: [email protected] Date: 2012-02-13 15:24 Subject: [IPsec] iOSX 5.x and IOX Lion's use of UDP_ENCAP problem Sent by: [email protected] Hi, There are many IPsec related standards, and I was hoping to use the combined experience of the list to tell me if in fact, these new apple devices have a bug, or whether it is an RFC or draft anywhere. When using L2TP/IPsec mode with IKEv1, the latest iphones/OSX machines, when on public IP, and when no NAT is detected, send UDP_ENCAP packets where the inner IP is the same as the outer IP. On the server, this is a problem. We now need to build tunnels to a random publicly addressable IP. Since that is dangerous and could be hijacking a real IP address, openwan only limits per default to RFC1918 space (and 25/8 since too many North American telco's use this and the UK MoD seems to not care). As a result, to make this work, we need to allow basically any public IP to be tunnelled. Is this indeed a bug in these devices? If so, is there anyone from Apple here that I can talk to and resolve this. Or if this is a feature/draft/rfc, could someone point me to it? Thanks, Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
