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" [email protected]
[email protected] [email protected] [email protected] 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" [email protected]
[email protected] [email protected] [email protected] 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" [email protected]
[email protected] [email protected] [email protected] 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" [email protected]
[email protected] [email protected] [email protected] 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" [email protected]
[email protected] [email protected] [email protected] 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" [email protected]
[email protected] [email protected] [email protected] 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" [email protected]
[email protected] [email protected] [email protected] 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" [email protected]
[email protected] [email protected] [email protected] 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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
