[Openswan Users] OpenSWAN fails to negotiate NAT-T draft 2 with Netscreen

[sean at obstacle9.com]

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
104 "dmz" #1: STATE_MAIN_I1: initiate
003 "dmz" #1: ignoring unknown Vendor ID payload 
[166f932d55eb64d8e4df4fd37e2313f0d0fd84510000000000000000]
003 "dmz" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
003 "dmz" #1: received Vendor ID payload [Dead Peer Detection]
003 "dmz" #1: ignoring Vendor ID payload [HeartBeat Notify 386b0100]
106 "dmz" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "dmz" #1: NAT-Traversal: Result using 
draft-ietf-ipsec-nat-t-ike-00/01: i am NATed
108 "dmz" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "dmz" #1: STATE_MAIN_I4: ISAKMP SA established
117 "dmz" #2: STATE_QUICK_I1: initiate
003 "dmz" #2: ignoring informational payload, type 
IPSEC_RESPONDER_LIFETIME
004 "dmz" #2: STATE_QUICK_I2: sent QI2, IPsec SA established 
{ESP=>0x24d1f2a3 <0x71a6a403 NATOA=0.0.0.0}

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....From the IETF interop 
meetings, it was specified that the vendor ID string in draft 02 was 
wrong for the hash value. Implementers should use the MD5 hash hex value, 
not the string to interoperate with other implementations.

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."

What format is OpenSwan sending draft-ietf-ipsec-nat-t-ike-02 to peers?

thanks,
Sean