[Ipsec-tools-devel] Cisco VPN client and NAt-T: help wanted

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi

I'm working on getting NAT-T working with racoon and Cisco VPN client. I 
need input from someone familiar with NAT-T...

Here is how it normally works:
client         server
    (phase 1)
  <-- Xauth req --
  -- Xauth rep -->
  <-- Xauth set --
  -- Xauth ack -->
  -- config req -->
  <-- config rep --
    (phase 2)

Now, with NAT-T: racoon (server) sends the Xauth request. the Cisco VPN
client answers, but racoon will never take that answer into account.

In the following, private is the private IP address of the client behind the
NAT, public is the NAT address, and server is the server address (raccon)

The Cisco VPN client log (revelant parts only):
SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Nat-T), VI
D(Frag), VID(Unity)) to server
RECEIVING <<< ISAKMP OAK AG (SA, KE, NON, ID, CERT, SIG, VID(Nat-T), NAT-D, NAT-
D, VID(Xauth), VID(Unity), CERT_REQ) from server
SENDING >>> ISAKMP OAK AG *(HASH, NOTIFY:STATUS_INITIAL_CONTACT, NOTIFY:PRESHARE
D_KEY_HASH, NAT-D, NAT-D, VID(?), VID(Unity)) to server
IKE Port in use - Local Port =  0x1194, Remote Port = 0x1194
Automatic NAT Detection Status:
   Remote end is NOT behind a NAT device
   This   end IS behind a NAT device
Packet size greater than ip header
Packet size greater than ip header
RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from server  (1)
SENDING >>> ISAKMP OAK TRANS *(HASH, ATTR) to server
Sent a keepalive on the IPSec SA
Sent a keepalive on the IPSec SA
Sent a keepalive on the IPSec SA
(no reply)

(1) is the Xauth request

Here are the packets seen by the client behind the NAT:
15:42:22.173991 IP private.isakmp > server.isakmp: isakmp: phase 1 I agg
15:42:22.330546 IP server.isakmp > private.isakmp: isakmp: phase 1 R agg
15:42:22.330557 IP server > private: udp
15:42:22.702116 IP private.ipsec-msft > server.ipsec-msft: UDP, length: 224
15:42:22.702478 IP private.ipsec-msft > server.ipsec-msft: UDP, length: 1
15:42:22.705849 IP server.isakmp > private.isakmp: isakmp: phase 2/others R #6[E] (2)
15:42:25.735847 IP private.ipsec-msft > server.ipsec-msft: UDP, length: 88
15:42:32.917520 IP private.ipsec-msft > server.ipsec-msft: UDP, length: 1
15:42:42.917313 IP private.ipsec-msft > server.ipsec-msft: UDP, length: 1
15:42:52.917451 IP private.ipsec-msft > server.ipsec-msft: UDP, length: 1

(2) This is an ISAKMP ecange mode: the Xauth request paquet

The packets seen bu the server:
15:49:14.687012 public.42667 > server.isakmp: isakmp: phase 1 I agg: [|sa]
15:49:14.840918 server.isakmp > public.42667: isakmp: phase 1 R agg: [|sa] (frag 35879:1480@0+)
15:49:14.840927 server > public: (frag 35879:37@1480)
15:49:15.214865 public.42669 > server.4500: udp 224
15:49:15.214870 public.42669 > server.4500: udp 1
15:49:15.217625 server.isakmp > public.42667: isakmp: phase 2/others R #6[E]: [encrypted hash] 
15:49:18.248826 public.42669 > server.4500: udp 88
15:49:25.432023 public.42669 > server.4500: udp 1
15:49:35.432717 public.42669 > server.4500: udp 1
15:49:45.434345 public.42669 > server.4500: udp 1

And finnally, racoon log on the server:
2004-09-20 15:49:14: INFO: respond new phase 1 negotiation: server[500]<=>public[42667]
2004-09-20 15:49:14: INFO: begin Aggressive mode.
2004-09-20 15:49:14: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
2004-09-20 15:49:14: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02

2004-09-20 15:49:14: INFO: received Vendor ID: CISCO-UNITY
2004-09-20 15:49:14: INFO: Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02

2004-09-20 15:49:14: INFO: Adding remote and local NAT-D payloads.
2004-09-20 15:49:14: INFO: Hashing public[42667] with algo #2
2004-09-20 15:49:14: INFO: Hashing server[500] with algo #2
2004-09-20 15:49:15: WARNING: remote address mismatched. db=public[42667], act=public[42669]
2004-09-20 15:49:15: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1.
2004-09-20 15:49:15: WARNING: ignore HEARTBEAT notification
2004-09-20 15:49:15: INFO: Hashing server[500] with algo #2
2004-09-20 15:49:15: INFO: NAT-D payload #0 verified
2004-09-20 15:49:15: INFO: Hashing public[42667] with algo #2
2004-09-20 15:49:15: INFO: NAT-D payload #1 doesn't match
2004-09-20 15:49:15: INFO: received Vendor ID: CISCO-UNITY
2004-09-20 15:49:15: INFO: NAT detected: PEER
2004-09-20 15:49:15: INFO: No SIG was passed, but hybrid auth is enabled
2004-09-20 15:49:15: INFO: Sending Xauth request
2004-09-20 15:49:15: INFO: ISAKMP-SA established server[500]-public[42667] spi:6c90417032587bca:9bd5c327e91ef0e6

Any idea? There are fragments in that game, Maybe CVPN sends them to
detect some fragmentation problems? That's probably the job of the frag
vendor id, but as we don't answer to it, I don't understand why CVPN still
uses it.

Anyone has an idea of what is going wrong?

-- 
Emmanuel Dreyfus
ma...@ne...