On 02/16/2012 09:49 AM, Yoav Nir wrote: > > On Feb 16, 2012, at 4:43 PM, Paul Wouters wrote: > >> On Thu, 16 Feb 2012, Yoav Nir wrote: >> >>>> 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. >> >> I'll make sure this is not an implementation issue on our side. >> >> Did any large deployment switch to removing all the draft VIDs? If so, >> how many problems did that cause? I'd be happy to remove the ancient >> drat cruft, especially if it increases interoperability. > > Our implementation supports the RFC and "draft-02\n", which is what Microsoft > clients added in some service pack of XP. We reply according to the last > recognized NAT-T VID, which in this case is the draft-02\n one. > > When we do this, we don't get any weird encapsulation modes like you do. Do > you reply with the RFC one?
It turns out we had a special check on OSX and did some workaround for a bug that AFAIK is no longer there (involving sending a 0.0.0.0 NAT-OA), and fell back to a draft instead of rfc version. I also removed sending some of the draft vendorids. This together seems to have resolved the problem, and OSX/iOS can now properly connect from public as well as through NAT-T. Thanks for all the feedback from everyone! Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
