[vpn-help] From another angle...

Matthew Grooms mgrooms at shrew.net
Thu Aug 10 22:59:59 CDT 2006


Peter Eisch wrote:
>  
> I can't test the scenario (no NAT-T) that we've been doing rounds on, but on
> a whim I figured I'd try from at home.  This would be a "NAT-T: Both" config
> (same 10.1.101.26 server as in the other traces).  This is with the alpha-2
> client.  I got seemingly similar results from the alpha-1 client.
> 

Thanks again for trying this stuff out. I just cant say that enough :)

> We don't get so far to even get phase 1 up -- maybe it would be worth the
> read until I can test the app in the lab tomorrow.
> 

I can say with a high level of confidence that the NAT-T support in the 
client is solid and has been very throughly tested with both racoon, a 
cisco concentrator and a cisco ASA. In fact, most of my lab test cases 
are configured for this scenario. That said, there is no such thing as 
too much testing especially if it yields a good bug report ;)

Racoon keeps retransmitting the second packet in the exchange even 
though the third packet has been transmitted by the client. The third 
packet would be the first packet via udp port 4500. Either the peer is 
rejecting the third packet in the exchange or its not getting there 
because of a firewall or udp port forwarding problem between the client 
and racoon.

> 
> ## : IPSEC Daemon, ver 1.1.0
> ## : Copyright 2006 Shrew Soft Inc.
> ## : This product linked OpenSSL 0.9.8a 11 Oct 2005
> ii : opened 'dump-prv.cap'
> ii : rebuilding interface list ...
> ii : skipping interface with null address
> ii : interface IP=206.197.64.216, MTU=1500 active
> ii : 1 adapter(s) active
> ii : client ctrl thread begin ...
> DB : tunnel added
> DB : tunnel dereferenced ( ref count = 0, tunnel count = 1 )
> ii : peer config message received
> DB : ipsec peer not found
> ii : local address selected for peer
> ii : 206.197.64.216 ( Broadcom 440x 10/100 Integrated Controller - Packet
> Scheduler Miniport )
> ii : user credentials message received
> ii : client keyfile message received
> ii : '\Documents and
> Settings\peter\Desktop\certs\cow.visionshareinc.com\ca.crt' loaded
> ii : tunnel enable message received
> DB : new phase1 sa ( ISAKMP initiator )
> DB : exchange type is aggressive
> DB : 206.197.64.216:500 <-> 66.162.50.84:500
> DB : 6b520b00711b5769:0000000000000000
> DB : phase1 sa added
>>> : security association payload
>>> : key exchange payload
>>> : nonce payload
>>> : identification payload
>>> : vendor id payload
>>> : vendor id payload
>>> : vendor id payload
>>> : vendor id payload
>>> : vendor id payload
>>> : vendor id payload

Aggressive Packet #1 initiator ...

> -> : send IKE packet to 66.162.50.84:500 ( 364 bytes )
> DB : phase1 sa dereferenced ( ref count = 0, phase1 count = 1 )
> ii : vnet inf 'C:\Program Files\ShrewSoft\VPN Client\drivers\virtualnet.inf'

Aggressive Packet #2 part 1 responder

> <- : recv IKE packet from 66.162.50.84:500 ( 548 bytes )
> DB : ipsec peer found
> DB : phase1 sa found
> << : fragment payload
> ii : ike fragment received, waiting on complete packet
> DB : phase1 sa dereferenced ( ref count = 0, phase1 count = 1 )
> DB : tunnel dereferenced ( ref count = 1, tunnel count = 1 )

Aggressive Packet #2 part 2 responder

> <- : recv IKE packet from 66.162.50.84:500 ( 548 bytes )
> DB : ipsec peer found
> DB : phase1 sa found
> << : fragment payload
> ii : ike fragment received, waiting on complete packet
> DB : phase1 sa dereferenced ( ref count = 0, phase1 count = 1 )
> DB : tunnel dereferenced ( ref count = 1, tunnel count = 1 )

Aggressive Packet #2 part 3 responder

> <- : recv IKE packet from 66.162.50.84:500 ( 548 bytes )
> DB : ipsec peer found
> DB : phase1 sa found
> << : fragment payload
> ii : ike fragment received, waiting on complete packet
> DB : phase1 sa dereferenced ( ref count = 0, phase1 count = 1 )
> DB : tunnel dereferenced ( ref count = 1, tunnel count = 1 )

Aggressive Packet #2 part 4 responder

> <- : recv IKE packet from 66.162.50.84:500 ( 416 bytes )
> DB : ipsec peer found
> DB : phase1 sa found
> << : fragment payload
> ii : ike fragment received, processing complete packet
> << : security association payload
> ii : matched phase1 proposal
> ii : - protocol     = isakmp
> ii : - transform    = ike
> ii : - key length   = default
> ii : - cipher type  = 3des
> ii : - hash type    = md5
> ii : - dh group     = modp-1024
> ii : - auth type    = hybrid-initiator-rsa
> ii : - life seconds = 86400
> ii : - life kbytes  = 0
> << : key exchange payload
> << : nonce payload
> << : identification payload
> << : certificate payload
> << : signature payload
> << : vendor id payload
> ii : peer supports XAUTH
> << : vendor id payload
> ii : peer supports UNITY
> << : cert request payload
> << : vendor id payload
> ii : peer supports NAT-T RFC
> << : nat discovery payload
> ii | NAT discovery - our address is translated
> << : nat discovery payload
> ii | NAT discovery - peers address is translated
> << : vendor id payload
> ii : peer supports DPDv1
> == : DH shared secret ( 128 bytes )
> == : SETKEYID ( 16 bytes )
> == : SETKEYID_d ( 16 bytes )
> == : SETKEYID_a ( 16 bytes )
> == : SETKEYID_e ( 16 bytes )
> == : cipher key ( 32 bytes )
> == : cipher iv ( 8 bytes )
> == : phase1 hash_i ( computed ) ( 16 bytes )
> ii : switching to NAT-T UDP port 4500
>>> : hash payload
>>> : nat discovery payload
>> = : encrypt iv ( 8 bytes )
> => : encrypt packet ( 68 bytes )
> == : stored iv ( 8 bytes )

Aggressive Packet #3 initiator

> -> : send IKE packet to 66.162.50.84:4500 ( 68 bytes )
> ii : unable to get certificate CRL(3) at depth:0
> ii : subject :/C=US/ST=Minnesota/L=Minneapolis/O=VisionShare,
> Inc./OU=Managed
> Services/CN=cow.visionshareinc.com/emailAddress=peter.eisch at visionshareinc.c
> om
> ii : unable to get certificate CRL(3) at depth:1
> ii : subject :/C=US/ST=Minnesota/L=Minneapolis/O=VisionShare,
> Inc./OU=Managed
> Services/CN=vpnca.visionshareinc.com/emailAddress=peter.eisch at visionshareinc
> .com
> == : phase1 hash_r ( computed ) ( 16 bytes )
> == : phase1 hash_r ( received ) ( 16 bytes )
> II | phase1 sa established
> II | 206.197.64.216:4500 <-> 66.162.50.84:4500
> II | 6b520b00711b5769:6fa4f818ee9e3274
>>> : hash payload
>>> : notification payload
> == : new informational hash ( 16 bytes )
> == : new phase2 iv ( 8 bytes )
>> = : encrypt iv ( 8 bytes )
> => : encrypt packet ( 76 bytes )
> == : stored iv ( 8 bytes )

Informational Packet initiator ( notification )

At this point the client will set idle and wait for an XAuth challenge.

> -> : send IKE packet to 66.162.50.84:4500 ( 76 bytes )
> ii : sent peer notification, INITIAL-CONTACT
> ii : 206.197.64.216 -> 66.162.50.84
> ii : isakmp spi = 6b520b00711b5769:6fa4f818ee9e3274
> ii : data size 0
> DB : phase1 sa dereferenced ( ref count = 0, phase1 count = 1 )
> DB : tunnel dereferenced ( ref count = 1, tunnel count = 1 )
> ii : created vnet device 'ROOT\VNET\0000'
> ii : rebuilding interface list ...
> ii : skipping interface with null address
> ii : skipping interface with null address
> ii : interface IP=206.197.64.216, MTU=1500 active
> ii : 1 adapter(s) active

Peer never got the third packet or it was rejected so it falls back to 
retransmitting packet #2.

Retransmit of Aggressive Packet #2 part 1 responder

> <- : recv IKE packet from 66.162.50.84:500 ( 548 bytes )
> DB : ipsec peer found
> DB : phase1 sa found
> << : fragment payload
> ii : ike fragment received, waiting on complete packet
> DB : phase1 sa dereferenced ( ref count = 0, phase1 count = 1 )
> DB : tunnel dereferenced ( ref count = 1, tunnel count = 1 )

Retransmit of Aggressive Packet #2 part 2 responder

> <- : recv IKE packet from 66.162.50.84:500 ( 548 bytes )
> DB : ipsec peer found
> DB : phase1 sa found
> << : fragment payload
> ii : ike fragment received, waiting on complete packet
> DB : phase1 sa dereferenced ( ref count = 0, phase1 count = 1 )
> DB : tunnel dereferenced ( ref count = 1, tunnel count = 1 )

Retransmit of Aggressive Packet #2 part 3 responder

> <- : recv IKE packet from 66.162.50.84:500 ( 548 bytes )
> DB : ipsec peer found
> DB : phase1 sa found
> << : fragment payload
> ii : ike fragment received, waiting on complete packet
> DB : phase1 sa dereferenced ( ref count = 0, phase1 count = 1 )
> DB : tunnel dereferenced ( ref count = 1, tunnel count = 1 )

Retransmit of Aggressive Packet #2 part 4 responder

> <- : recv IKE packet from 66.162.50.84:500 ( 416 bytes )
> DB : ipsec peer found
> DB : phase1 sa found
> << : fragment payload

Client ignores because its seen this part of the exchange before ...

> ii : ike fragment received, processing complete packet
> << : ignoring duplicate security association payload
> !! : unprocessed phase1 payload data

Would it be possible to see what racoon thinks of this? If racoon gets 
the packet, what is the error message. If its not getting the packet, 
what does the firewall say? Is it configured to forward 4500 as well as 
500 to racoon?

Thanks,

-Matthew



More information about the vpn-help mailing list