On Feb 16, 2012, at 4:11 PM, Tero Kivinen wrote: > Paul Wouters writes: >> 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. > > Are you really telling me they are using a private numbers from the > internet draft that expired more than 10 years ago, and which is not > compatible with the RFC3947 (which (which was published January 2005, > i.e. 7 years ago).
They don't always do that. But looking at their MainMode packet 1 in wireshark, They send the following VIDs: - RFC 3947 Negotiation of the NAT-Traversal in the IKE - draft-ietf-ipsec-nat-t-ike - draft-ietf-ipsec-nat-t-ike-08 - draft-ietf-ipsec-nat-t-ike-07 - draft-ietf-ipsec-nat-t-ike-06 - draft-ietf-ipsec-nat-t-ike-05 - draft-ietf-ipsec-nat-t-ike-04 - draft-ietf-ipsec-nat-t-ike-03 - draft-ietf-ipsec-nat-t-ike-02 - draft-ietf-ipsec-nat-t-ike-02\n - RFC 3706 DPD (Dead Peer Detection) I guess what they later do depends on what VID they get in the reply. There were quite a few versions of Windows server that returned 90cb80…427b1f (draft-ietf-ipsec-nat-t-ike-02\n), so maybe Paul's implementation was a surprise for iOS. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
