On Mon, 13 Feb 2012, Yoav Nir wrote:
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.
I'm not sure I follow you. L2TP/IPSec uses transport mode ESP, so the inner IP is inside the L2TP tunnel. That address is assigned in the IPCP protocol by your gateway.
I'm sorry, inner IP and outer IP were a bad choice of words. The devices send an Encapsulation Mode attribute 61443 (private use, but generally known as ENCAPSULATION_MODE_UDP_TUNNEL_DRAFTS) and starts using this ESPinUDP where the UDP header has the same public IP as the encapsulated ESP packet. Normally, clients use their pre-NATed IP address for that.
So what is the issue?
In roadwarrior connections, imagine I setup my LAN to be 193.110.157.0/24. My public IP is 1.2.3.4. I now setup a connection using ESPinUDP where I negotiate 193.110.157.101/32 as my address on the ESP packet encapsulated in the UDP packet that has 1.2.3.4. Now I will get all the traffic of www.openswan.org (193.110.157.101) that the remote gateway meant to send to www.openswan.org. For this reason, we try to limit the addresses that can be used to RFC1918 addresses. The OSX bug is causing us to have to allow any public IP address for no good reason, as it should not be using ESPinUDP to begin with when it is on an unfiltered public IP. (though the mention that IKEv2 tells us we need to accept this anyway is unfortunate, so we will have to deal with this anyway) The best openswan can do now, is to allow 0/0 with the exception of its own network and the network it assigns via L2TP. And have another layer of packet inspection to avoid sending traffic to the wrong destinations. (like SAref tracking, or Labeled IPsec) Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
