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@89.0.0.1 esp.366391ef@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
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
