On Fri, Feb 1, 2019, at 11:44 PM, Paul Wouters wrote:
> On Fri, 1 Feb 2019, Kostya Vasilyev wrote:
>
> > Now I've set ikev2=insist and see this in the logs:
> >
> > pluto[8407]: "mytunnel" #7: STATE_V2_IPSEC_R: IPsec SA established
> > transport mode {ESP=>0x0530016d <0x1813ca67
> > xfrm=AES_CBC_128-HMAC_SHA2_256_128 NATOA=none NATD=none DPD=active}
> > pluto[8407]: "mytunnel" #5: suppressing retransmit because superseded by #7
> > try=1. Drop this negotitation
> > pluto[8407]: "mytunnel" #5: deleting state (STATE_PARENT_I1) and NOT
> > sending notification
>
> It is still weird you have two instances competing for the same. Are you
> sure #5 didn't start yet a new keying attempt?
>
> Paul
Couldn't one of those two instances be the client also trying to initiate a
connection?
At this time with both sides set to IKEv2 and after everything has settled,
this is "ipsec status":
000 #19: "mytunnel":4500 STATE_PARENT_R2 (received v2I2, PARENT SA
established); EVENT_SA_REPLACE in 236s; newest ISAKMP; idle;
000 #22: "mytunnel":4500 STATE_V2_IPSEC_R (IPsec SA established);
EVENT_SA_REPLACE in 28343s; newest IPSEC; eroute owner; isakmp#19; idle;
000 #22: "mytunnel" esp.57e5080@89.208.22.144 esp.a6efd7ae@139.162.238.65 ref=0
refhim=0 Traffic: ESPin=9KB ESPout=62KB! ESPmax=0B
Looks like no "extra" connections, just one?
Server logs are quiet too - no more retries or unrecognized messages from
unknown connections.
Oh just as I was about to hit Send, this showed up:
pluto[8407]: "mytunnel" #19: initiate rekey of IKEv2 CREATE_CHILD_SA IKE Rekey
pluto[8407]: "mytunnel" #23: message id deadlock? wait sending, add to send
next list using parent #19 unacknowledged 96 next message id=96 ike exchange
window 1
Any reasons to worry about the "id deadlock"?
#23 showed up in ipsec status like this:
000 #23: "mytunnel":4500 STATE_V2_REKEY_IKE_I0 (STATE_V2_REKEY_IKE_I0);
EVENT_SA_REPLACE in 82s; lastlive=0s; crypto/dns-lookup;
And after those 82 seconds expired:
pluto[8407]: "mytunnel" #23: deleting state (STATE_V2_REKEY_IKE_I0) and NOT
sending notification
and #23 is not listed anymore in ipsec status.
-- K
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
