[Vpn-help] Wrong IKE port?

[David Santinoli]

Hallo,
  it appears that, under some circumstances, the Windows client tries to
talk ISAKMP on the wrong port.  When I click the "Connect" button in the
connection window, the log states that the client attempts to contact
the peer on port 500, as in the following excerpt:

>> : vendor id payload
ii : local is CHECKPOINT compatible
-> : send IKE packet 10.1.10.50:500 -> mangled:500 ( 3828 bytes )
ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
ii : fragmented packet to 882 bytes ( MTU 1500 bytes )
ii : resending 1 phase1 exchange packet(s)
ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
ii : fragmented packet to 882 bytes ( MTU 1500 bytes )
ii : resending 1 phase1 exchange packet(s)
ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
ii : fragmented packet to 882 bytes ( MTU 1500 bytes )
ii : phase1 packet resend limit exceeded
DB : phase1 deleted before expire time ( phase1 count = 0 )
DB : policy not found
DB : policy not found
ii : removed IPSEC policy route for 10.30.0.0/24
ii : adapter ROOT\VNET\0000 already disabled
ii : adapter ROOT\VNET\0000 already disabled
DB : removing all tunnel refrences
DB : tunnel deleted ( tunnel count = 0 )
DB : peer deleted ( peer count = 0 )
ii : admin process thread exit ...

However, a packet dump on the gateway's side shows packets hitting port
4500, not 500:

14:05:36.946355 IP mangled.35567 > 192.168.1.1.4500: UDP-encap: ESP(spi=0xf16059c7,seq=0x38cd2f07), length 1472
14:05:41.948938 IP mangled.35567 > 192.168.1.1.4500: UDP-encap: ESP(spi=0xf16059c7,seq=0x38cd2f07), length 1472
14:05:46.954899 IP mangled.35567 > 192.168.1.1.4500: UDP-encap: ESP(spi=0xf16059c7,seq=0x38cd2f07), length 1472

Needless to say, the connection fails to be established.

Regarding the circumstances under which this behaviour is displayed, I
haven't come to a definite conclusion yet, but it looks like it's more
likely to happen immediately after a failed connection attempt (this
makes me think of iked incorrectly retaining a previous NAT-T detection
result).

My setup: 2.1.0a6 on Windows 2000/VMWare (client), StrongSwan 4.1.4
(gateway).

Thanks,
 David
-- 
 David Santinoli
 Tieffe Sistemi S.r.l.                      viale Piceno 21, Milano
 www.tieffesistemi.com                         tel. +39 02 76115215