On Sat, 2 Feb 2019, Kostya Vasilyev wrote:
It is still weird you have two instances competing for the same. Are you sure #5 didn't start yet a new keying attempt?
Couldn't one of those two instances be the client also trying to initiate a connection?
Yes.
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?
Looks that way, yes.
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"?
There is a false positive in that code. Try git master or 3.28 in the next few days to see if that warning has gone away?
#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.
Seems it tried to rekey and fail. I wonder what will happen near the end of your ikelifetime. It better be able to rekey :P Paul _______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
