[Openswan Users] IPSec/L2TP with Mac OS X drops connection after 1 hour

[Paul Wouters]

On Sat, 18 Jul 2009, Kevin J. Arunski wrote:

> From: Kevin J. Arunski <kevin.arunski at netwitness.com>
> To: users at openswan.org
> Subject: [Openswan Users] IPSec/L2TP with Mac OS X drops connection after 1
>     hour
> 
> I'm using Openswan in a roadwarrior setup for IPsec/L2TP clients, and
> it appears the IPsec SA is dropped at exactly the one hour mark when
> Mac OS X or Windows Vista clients connect.
>
> I'm using openswan 2.4.15 because the 2.6.X versions don't seem to
> work at all. I'm using NETKEY on kernel 2.6.18-128.1.10.el5.
>
> Here is the configuration:
>
> conn L2TP-PSK-NAT
> 	authby=secret
> 	pfs=no
> 	auto=add
> 	keyingtries=3
> 	rekey=no
> 	ikelifetime=8h
> 	keylife=1h
> 	type=transport
> 	left=---.---.---.---
> 	leftprotoport=17/1701
> 	right=%any
> 	rightprotoport=17/%any
> 	rightsubnet=vhost:%no,%priv
>
>
> After about ~50 minutes I see the following in my logs:
>
> Jul 18 15:11:21 localhost pluto[2049]: "L2TP-PSK-NAT"[5] W.X.Y.Z #8:
> responding to Quick Mode {msgid:84e8d5a5}
> Jul 18 15:11:21 localhost pluto[2049]: "L2TP-PSK-NAT"[5] W.X.Y.Z #8:
> cannot install eroute -- it is in use for "L2TP-PSK-NAT"[2] W.X.Y.Z #4

Do you have uniqueids=yes (or not entry at all, since it is the default)
in "config setup" in ipsec.conf? Then this should not happen.

I know there was a Windows bug where they started a completely new IKE
instead of using Quickmode to re-key, but since I see "responding to Quick Mode"
that does not seem to be the case here.

> Then, a few minutes later:
>
>
> Jul 18 15:16:21 localhost pluto[2049]: "L2TP-PSK-NAT"[5] W.X.Y.Z:
> deleting connection "L2TP-PSK-NAT" instance with peer W.X.Y.Z
> {isakmp=#0/ipsec=#0}

That's the client side cleaning up after failure.

> Jul 18 15:23:19 localhost pluto[2049]: "L2TP-PSK-NAT"[2] W.X.Y.Z #3:
> ISAKMP SA expired (--dontrekey)
> Jul 18 15:23:20 localhost pluto[2049]: "L2TP-PSK-NAT"[2] W.X.Y.Z #4:
> IPsec SA expired (--dontrekey)

And the SA that failed to rekey hit the expiration. Why they would both do that
at the same time when you have ikelifetime <> keylife, I don't know.

This might be a bug that's fixed in 2.6, but that won't help you know since you
need 2.4.x for bug #1004. We're working on chasing it down, hopefully in a few
days we can release a new 2.6.x

Paul