[Swan] SA lifetime duration

[Kostya Vasilyev]

On Mon, Feb 11, 2019, at 9:32 PM, Paul Wouters wrote:
> On Mon, 11 Feb 2019, Kostya Vasilyev wrote:
> 
> >> Usually, watching SAs in Mikrtoik web UI and "ipsec status", there is a
> >> tendency to have 4 or even 6 SA's and for them to rotate / expire a few
> >> times a day.
> 
> It depends on how quickly the endpoints rekey their IPsec and IKE SAs.
> 
> This is an I state, an initiator state. So you have both endpoints
> likely with similar timings, sometimes rekeying at the same time.

Yes both client and server are set to initiate (I believe) - and I guess sometimes they do at more or less the same time.

> > 000 #290: "mytunnel":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_EXPIRE in 496s; isakmp#289; idle;
> > 000 #290: "mytunnel" esp.a76f21d at 89.0.0.1 esp.366391ef at 139.0.0.1 ref=0 refhim=0 Traffic: ESPin=553KB ESPout=23MB! ESPmax=4194303B
> > 000 #300: "mytunnel":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 708s; newest ISAKMP; lastdpd=10s(seq in:25763 out:0); idle;
> > 000 #301: "mytunnel":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 28023s; newest IPSEC; eroute owner; isakmp#300; idle;
> 
> So since you _just_ rekeyed, it looks like you have salifetime=500s
> which is way shorter than you should have it. Why did you set such
> a short lifetime?

I don't have salifetime in my libreswan config.

> > I know the old pair of SA's will expire in a while - and that traffic is using the new pair already.
> 
> So since we linger the old states for about 5-15 minutes, I see why you
> gain a few old lingering IKE and IPsec states.

Yep seen this - usually after 5 minutes it seems.

> 
> > But I'm still curious - what is going on?
> 
> [snip] - thanks for the explanation, read carefully

I just tried to change libreswan to auto=ignore so that conns are only initiated by the client.

Curiously this doesn't work (on already tested and otherwise working .conf).

When client (Mikrotik) initiates:

Feb 11 21:10:48 kman.mobi pluto[13958]: | processing: start from 89.0.0.1:500 (in process_md() at demux.c:391)
Feb 11 21:10:48 kman.mobi pluto[13958]: | #null state always idle
Feb 11 21:10:48 kman.mobi pluto[13958]: | find_host_connection me=139.0.0.1:500 him=89.0.0.1:500 policy=IKEV1_ALLOW
Feb 11 21:10:48 kman.mobi pluto[13958]: | find_next_host_connection policy=IKEV1_ALLOW
Feb 11 21:10:48 kman.mobi pluto[13958]: | find_next_host_connection returns empty
Feb 11 21:10:48 kman.mobi pluto[13958]: | find_host_connection me=139.0.0.1:500 him=%any:500 policy=RSASIG+IKEV1_ALLOW
Feb 11 21:10:48 kman.mobi pluto[13958]: | find_next_host_connection policy=RSASIG+IKEV1_ALLOW
Feb 11 21:10:48 kman.mobi pluto[13958]: | find_next_host_connection returns empty
Feb 11 21:10:48 kman.mobi pluto[13958]: packet from 89.0.0.1:500: initial Main Mode message received on 139.0.0.1:500 but no connection has been authorized with policy RSASIG+IKEV1_ALLOW

Now when libreswan initiated (and it connected just fine) the "capabilities" (???) were somewhat different:

Feb 11 21:11:44 kman.mobi pluto[14199]: "mytunnel" #2: initiating Quick Mode RSASIG+ENCRYPT+PFS+UP+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:7f30139f proposal=AES_CBC_128-HMAC_SHA2_256_128-MODP2048 pfsgroup=MODP2048}

Client is  89.0.0.1
Server is 139.0.0.1

Does "auto=ignore" completely ignore a peer's config section?

I also tried "auto=add", same thing or almost.

What's the setting then (can't find it in the docs) to set libreswan to not initiate but have the peer config be ready to go - when the other side initiates?

Thanks again!

-- K