[Openswan Users] NAT-T broken with Netscreen

[sean at obstacle9.com]

On Tue, 6 Dec 2005, Jacco de Leeuw wrote:

> 
> Sean wrote:
> 
> > It looks like OpenSWAN isn't recognizing draft-ietf-ipsec-nat-t-ike-02
> > Vendor ID/payload sent by the Netscreen and/or vice versa. I've confirmed
> > this is the case with the latest version of OpenSWAN.
> > 
> > linux:~ # ipsec auto --up dmz
> > 003 "dmz" #1: NAT-Traversal: Result using
> > draft-ietf-ipsec-nat-t-ike-00/01: i am NATed
> 
> Oops, they negotiate a very old NAT-T draft. That is a pity.

Yeah, they don't support very many drafts:

draft-ietf-ipsec-nat-t-ike-00.txt
draft-ietf-ipsec-nat-t-ike-02.txt
draft-ietf-ipsec-udp-encaps-00.txt
draft-ietf-ipsec-udp-encaps-02.txt

> 
> > While researching the same problem with VPN Tracker clients to a
> > Netscreen, Juniper said this was the problem:
> > 
> > "Some vendors use the MD5 hash value in the draft, while others use the
> > vendor id string, and do the hash in the code.
> 
> Yes, this is a well-known problem in the specs:
> http://www.vpnc.org/ietf-ipsec/02.ipsec/msg01150.html
> 
> > Because VPNTracker is using the vendor id string, instead of the MD5 hash,
> > ScreenOS is not recognizing this is a draft-02 NAT-T implementation."
> 
> I can't comment on whether the problem you are having with Openswan is
> the same as with VPNTracker but Juniper could have chosen to support
> _both_ MD5 hashes, just like Openswan. Now you are left in the cold.
> Even better would have been support for the official RFC 3947, which
> has been out for almost a year now.

I wish more commercial vendors would pay heed to the adage "Be liberal in 
what you accept, conservative in what you send." Back here in reality, 
I'll push JTAC for info about adopting RFC 3947 and pressure them to 
accept both MD5 hashes for draft 2.

> 
> > What format is OpenSwan sending draft-ietf-ipsec-nat-t-ike-02 to peers?
> 
> As a responder Openswan accepts both hashes but as an initiator it sends
> only the hash without the extra "\n", as you have found out. I am not sure
> if there is a particular reason behind this, but if you would like to
> experiment then you can try the following simple patch.

Thanks for the patch (I should have taken the time to write it myself). I 
applied the patch and it does work; I was able to negotiate NAT-T 
draft-2 with a Netscreen. 

cheers,
sk