[Swan] Duplicate, lingering SAs

Paul Wouters paul at nohats.ca
Fri Jan 17 12:01:05 UTC 2020


On Wed, 15 Jan 2020, Alan Szlosek wrote:

> We're running version 3.29 on Ubuntu with Linux kernel 4.15 and we're seeing an issue with duplicate SAs. As I understand, it's normal behavior to have 2 of a 1x1 Phase 2 SA, for example. The newer one will
> replace the one expiring soon. But we're seeing many many more than that for some connections.
> 
> Here's the output from `ipsec auto --status`:
>       000 #476937: "someconnection/1x1":4500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 10800s; newest ISAKMP; lastdpd=30s(seq in:5880 out:0); idle;
>       000 #493485: "someconnection/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 28s; isakmp#476937; idle;
>       000 #493485: "someconnection/1x1" esp.f1fe58dd at M.M.M.M esp.f399709c at N.N.N.N tun.0 at M.M.M.M tun.0 at N.N.N.N ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
>       000 #493560: "someconnection/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 108s; isakmp#476937; idle;
>       000 #493560: "someconnection/1x1" esp.27c2bd16 at M.M.M.M esp.ab211c5d at N.N.N.N tun.0 at M.M.M.M tun.0 at N.N.N.N ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
>       000 #493653: "someconnection/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 188s; isakmp#476937; idle;
>       000 #493653: "someconnection/1x1" esp.5f057b15 at M.M.M.M esp.9cda7919 at N.N.N.N tun.0 at M.M.M.M tun.0 at N.N.N.N ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
>       000 #493735: "someconnection/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 258s; isakmp#476937; idle;
>       000 #493735: "someconnection/1x1" esp.34bdbc9 at M.M.M.M esp.a5be9699 at N.N.N.N tun.0 at M.M.M.M tun.0 at N.N.N.N ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
>       000 #493823: "someconnection/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 338s; isakmp#476937; idle;
>       000 #493823: "someconnection/1x1" esp.67112f99 at M.M.M.M esp.b60f3f58 at N.N.N.N tun.0 at M.M.M.M tun.0 at N.N.N.N ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
>       000 #493898: "someconnection/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 418s; isakmp#476937; idle;
>       000 #493898: "someconnection/1x1" esp.f52d069 at M.M.M.M esp.89ef4b84 at N.N.N.N tun.0 at M.M.M.M tun.0 at N.N.N.N ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
>       000 #493985: "someconnection/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 498s; isakmp#476937; idle;
>       000 #493985: "someconnection/1x1" esp.82c1eac3 at M.M.M.M esp.d95669e9 at N.N.N.N tun.0 at M.M.M.M tun.0 at N.N.N.N ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
>       000 #494085: "someconnection/1x1":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 578s; isakmp#476937; idle;
>       000 #494085: "someconnection/1x1" esp.44878df8 at M.M.M.M esp.58d0461c at N.N.N.N tun.0 at M.M.M.M tun.0 at N.N.N.N ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B

Those all have a very short expire time. And the latest one as a large
10800s replace time. So I am a bit confused how you are accumulating
these. Does the remote peer have an extremely short lifetime set? We
do linger replaced IPsec SA's for much longer than I think we should.

> And here's the config:
>
>       conn someconnection
>     type=tunnel
>     authby=secret
>     left="N.N.N.N"
>     leftid=A.A.A.A
>     leftsubnets=" B.B.B.B/32 C.C.C.C/32 D.D.D.D/32 "
>     right=M.M.M.M
>     rightsubnets=" E.E.E.E/32 F.F.F.F/32 G.G.G.G/32 "
>     auto=start
>     ike=REDACTED
>     phase2alg=REDACTED
>     ikelifetime=28800
>     salifetime=3600

So these times are normal and you shouldn't be gaining old IPsec SA's
that much. Does the other endpoint have the same timers?

>     dpdaction=restart
>     dpddelay=30
>     dpdtimeout=120

Could you disable dpd and see if that is triggering the tunnels to be
re-setup all the time?

Paul


More information about the Swan mailing list