[Swan] dpd question
paul at nohats.ca
Fri Feb 1 22:54:24 UTC 2019
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?
> 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 at 18.104.22.168 esp.a6efd7ae at 22.214.171.124 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: "mytunnel" #19: initiate rekey of IKEv2 CREATE_CHILD_SA IKE Rekey
> pluto: "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: "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
More information about the Swan