[Openswan Users] [NAT-T] one side thinks "established", the other...doesn't.

[Ferdinand O. Tempel]

Hi,

Though I've been using {free,open}swan for ages, and I'm pretty well
versed in it, this is the first time I get to have anything to do with
NAT-T. So exuse my cluelesness :P

First the situation:

192.168.1.200 (right) == (192.168.1.1 X 10.164.10.1) --- 10.100.100.2 ==
10.100.100.1 (left)

192.168.1.200 is a 2.6.7 based client running openswan-2.2.0dr1 on
native ipsec using NAT-T. The thing in the middle between braces is a
dumb NAT box which NATs 192.168.1.0/24 to 10.164.10.1. The 10.100.100.2
is the gateway for 10.100.100.1, which is the receiving ipsec server
(2.6.6, native ipsec, openswan-2.2.0dr1).

The setup is pretty simple, just your basic PSK ipsec connection:

left:
conn nattest
  left=%defaultroute
  right=%any
  rightsubnet=192.168.1.200/32
  authby=secret
  auto=ignore

right:
conn nattest
  right=%defaultroute
  left=10.100.100.1
  leftnexthop=10.100.100.2
  authby=secret
  auto=ignore

When I try to initiate the ipsec tunnel from 192.168.1.200 (10.100.100.1
is just listening, it's the server), it establishes an ipsec tunnel
pretty quick. At least, that's what 192.168.1.200 thinks:

polarwolf at dualbox:~$ sudo ipsec auto --up nattest
104 "nattest" #10: STATE_MAIN_I1: initiate
003 "nattest" #10: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-03]
106 "nattest" #10: STATE_MAIN_I2: sent MI2, expecting MR2
003 "nattest" #10: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
108 "nattest" #10: STATE_MAIN_I3: sent MI3, expecting MR3
004 "nattest" #10: STATE_MAIN_I4: ISAKMP SA established
112 "nattest" #11: STATE_QUICK_I1: initiate
004 "nattest" #11: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0x5ff8ae37 <0x04ff3c53 NATOA=0.0.0.0}

However, looking on the other end (10.100.100.1, server), it doesn't get
any further than STATE_QUICK_R1:

Jul  1 22:15:40 gw-left pluto[1124]: added connection description
"nattest"
Jul  1 22:15:43 gw-left pluto[1124]: packet from 10.164.10.1:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Jul  1 22:15:43 gw-left pluto[1124]: packet from 10.164.10.1:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but
already using method 108
Jul  1 22:15:43 gw-left pluto[1124]: packet from 10.164.10.1:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[1] 10.164.10.1 #6:
responding to Main Mode from unknown peer 10.164.10.1
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[1] 10.164.10.1 #6:
transition from state (null) to state STATE_MAIN_R1
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[1] 10.164.10.1 #6:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is
NATed
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[1] 10.164.10.1 #6:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[1] 10.164.10.1 #6: Peer
ID is ID_IPV4_ADDR: '192.168.1.200'
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[2] 10.164.10.1 #6:
deleting connection "nattest" instance with peer 10.164.10.1
{isakmp=#0/ipsec=#0}
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[2] 10.164.10.1 #6: I did
not send a certificate because I do not have one.
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[2] 10.164.10.1 #6:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jul  1 22:15:43 gw-left pluto[1124]: | NAT-T: new mapping
10.164.10.1:500/4500)
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[2] 10.164.10.1:4500 #6:
sent MR3, ISAKMP SA established
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[2] 10.164.10.1:4500 #7:
responding to Quick Mode
Jul  1 22:15:43 gw-left pluto[1124]: "nattest"[2] 10.164.10.1:4500 #7:
transition from state (null) to state STATE_QUICK_R1
Jul  1 22:15:43 gw-left pluto[1124]: packet from 192.168.1.200:4500:
Quick Mode message is for a non-existent (expired?) ISAKMP SA

Odd. It correctly identifies the incoming connection as NAT, and
successfully sets up an ISAKMP SA. It doesn't seem to get past the
quickmode IPsec SA negotiations though, even though the client side
thinks everything is just peachy. Has anyone ever seen this behaviour
before, and/or has a solution? I'm lost :)

PS: Both ipsec.conf's have "nat_traversal=yes", and tcpdump shows
traffic on udp/{500,4500} flying back and forth.
PPS: This is my second test, and the first test with a totally different
server shows the same behaviour. Granted, it's also running
openswan-2.2.0dr1.
-- 
Regards,

Ferdinand O. Tempel

Your friendly neighborhood linuxops.net administrator.