[Openswan Users] NAT-T: reconnect to gateway fails

[Pepijn Oomen]

Problem description: connection to the gateway works fine, but problems 
arise when reconnecting after taking down the VPN. Waiting for a period 
of time solves this problem.

Probable cause: an orphaned IPsec SA prevents proper TCP/IP flow on 
reconnect.

Extended description: it looks like an orphaned IPsec SA is the cause of 
the reconnection problem. On reconnect, the ISAKMP and IPsec SAs are 
established correctly, but no traffic flows (from server to client?) 
through the tunnel making it impossible to establish the L2TP connection.

A similar problem seems to be caused by two types of scenarios:

a) OpenSWAN leaves an orphaned IPsec SA after a replacement IPsec SA is 
installed,
b) MacOSX does not reestablish the ISAKMP SA after it is dropped, 
causing failure in communication for controlling the connection and thus 
causing an orphaned IPsec SA on the OpenSWAN side.

Software in use:

client: MacOSX 10.4.10 builtin L2TP/IPSEC client behind NAT

server:
- Debian Etch 4.0r0 (2.6.18-4-686 /w NETKEY) behind NAT
- OpenSWAN 2.4.9, xl2tpd 1.1.11 (both build from sources)

Analysis:

T = 0

[...]
"l2tp"[1] x.x.x.x #1: NAT-Traversal: Result using RFC 3947 
(NAT-Traversal): both are NATed
[...]
"l2tp"[2] x.x.x.x #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established 
{auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha 
group=modp1024}
[...]
"l2tp"[2] x.x.x.x #2: STATE_QUICK_R2: IPsec SA established 
{ESP=>0x0bda84bf <0x2cdb6add xfrm=AES_128-HMAC_SHA1 NATD=x.x.x.x:4500 
DPD=none}

The connection is establised without problems. The ISAKMP and IPsec SAs 
are in place and traffic is flowing throught the tunnel. When the tunnel 
is taken down at this point, all works fine.

T + 50 minutes

"l2tp"[2] x.x.x.x #3: NAT-Traversal: received 2 NAT-OA. using first, 
ignoring others
"l2tp"[2] x.x.x.x #3: responding to Quick Mode {msgid:aaaadf8d}
"l2tp"[2] x.x.x.x #3: transition from state STATE_QUICK_R0 to state 
STATE_QUICK_R1
"l2tp"[2] x.x.x.x #3: STATE_QUICK_R1: sent QR1, inbound IPsec SA 
installed, expecting QI2
"l2tp"[2] x.x.x.x #3: transition from state STATE_QUICK_R1 to state 
STATE_QUICK_R2
"l2tp"[2] x.x.x.x #3: STATE_QUICK_R2: IPsec SA established 
{ESP=>0x0563b499 <0x96c23648 xfrm=AES_128-HMAC_SHA1 NATD=x.x.x.x:4500 
DPD=none}

The client has decided it is time to replace the IPsec SA. The server 
responds accordingly and a new IPsec SA is established. The old IPsec SA 
is still available but no longer used. Traffic flows through the tunnel 
correctly, but taking down the tunnel at this point makes reconnection 
impossible, scenario (a).

T + 60 minutes

"l2tp"[2] x.x.x.x #1: ISAKMP SA expired (--dontrekey)

The server drops the ISAKMP SA. Traffic is still flowing through the 
tunnel, but when dropping the connection, the server is not notified of 
this and an orphaned IPsec SA is left, scenario (b).

T + 100 minutes

"l2tp"[2] x.x.x.x #4: STATE_MAIN_R3: sent MR3, ISAKMP SA established 
{auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha 
group=modp1024}
[...]
"l2tp"[2] x.x.x.x #5: STATE_QUICK_R2: IPsec SA established 
{ESP=>0x0d9e5585 <0x6eff9828 xfrm=AES_128-HMAC_SHA1 NATD=x.x.x.x:4500 
DPD=none}

The IPsec SA is again replaced by the client, but it notices the missing 
ISAKMP SA, which is first re-established. Traffic flow is still intact, 
but on disconnect OpenSWAN leaves an orphaned IPsec SA in place, which 
prevents succesfull reconnect, scenario (a).

T + 110 minutes

The orphan IPsec SA is abandoned, leaving the 'normal' situation of one 
ISAKMP SA and one IPsec SA. Disconnection now works as expected and a 
reconnect is possible.

-- 
We are perfect, but the code is terrible.
  -- Microsoft Software Developer