[Openswan Users] Problem with Windows Road Warrior

[Torsten Luettgert]

Hello,

I try to make an IPSec connection from a Windows XP Pro SP 2
to an OpenS/WAN 2.4.5 installation on a trimmed-down CentOS 4.3.

This is a road warrior configuration with certificates.
I used the ipsec.exe tool from http://vpn.ebootis.de/ and followed the
instructions from Nate Carlson (referenced at that page).

I get errors as follows:

packet from 212.87.49.7:500: ignoring Vendor ID payload [MS NT5
ISAKMPOAKLEY 00000004]
packet from 212.87.49.7:500: ignoring Vendor ID payload [FRAGMENTATION]
packet from 212.87.49.7:500: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
packet from 212.87.49.7:500: ignoring Vendor ID payload
[Vid-Initial-Contact]
"combox-fotofinder"[1] 212.87.49.7 #9: responding to Main Mode from
unknown peer 212.87.49.7
"combox-fotofinder"[1] 212.87.49.7 #9: transition from state
STATE_MAIN_R0 to state STATE_MAIN_R1
"combox-fotofinder"[1] 212.87.49.7 #9: STATE_MAIN_R1: sent MR1,
expecting MI2
"combox-fotofinder"[1] 212.87.49.7 #9: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
"combox-fotofinder"[1] 212.87.49.7 #9: transition from state
STATE_MAIN_R1 to state STATE_MAIN_R2
"combox-fotofinder"[1] 212.87.49.7 #9: STATE_MAIN_R2: sent MR2,
expecting MI3
"combox-fotofinder"[1] 212.87.49.7 #9: next payload type of ISAKMP Hash
Payload has an unknown value: 91
"combox-fotofinder"[1] 212.87.49.7 #9: malformed payload in packet
"combox-fotofinder"[1] 212.87.49.7 #9: sending notification
PAYLOAD_MALFORMED to 212.87.49.7:500
packet from 212.87.33.5:500: ignoring informational payload, type
NO_PROPOSAL_CHOSEN
packet from 212.87.33.5:500: received and ignored informational message

I think this line is the most interesting:

next payload type of ISAKMP Hash Payload has an unknown value: 91

Playing around with different IKE and ESP modes (windows doesn't
seem to support AES, only 3DES), I got the following "unknown value"
errors:

next payload type of ISAKMP Hash Payload has an unknown value: 162
next payload type of ISAKMP Hash Payload has an unknown value: 158
next payload type of ISAKMP Hash Payload has an unknown value: 116
next payload type of ISAKMP Hash Payload has an unknown value: 54
next payload type of ISAKMP Hash Payload has an unknown value: 63
next payload type of ISAKMP Hash Payload has an unknown value: 96
next payload type of ISAKMP Hash Payload has an unknown value: 246
next payload type of ISAKMP Hash Payload has an unknown value: 67
next payload type of ISAKMP Hash Payload has an unknown value: 188
next payload type of ISAKMP Hash Payload has an unknown value: 78
next payload type of ISAKMP Hash Payload has an unknown value: 149
next payload type of ISAKMP Hash Payload has an unknown value: 67
next payload type of ISAKMP Hash Payload has an unknown value: 212
next payload type of ISAKMP Hash Payload has an unknown value: 232
next payload type of ISAKMP Hash Payload has an unknown value: 87
next payload type of ISAKMP Hash Payload has an unknown value: 239
next payload type of ISAKMP Hash Payload has an unknown value: 228
next payload type of ISAKMP Hash Payload has an unknown value: 89
next payload type of ISAKMP Hash Payload has an unknown value: 91

Is this a bug in OpenS/WAN? I can't believe Windows generated
so many different proprietary payloads.

Please help...
Torsten Lüttgert