[Swan] dpd question

[Paul Wouters]

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 at 89.208.22.144 esp.a6efd7ae at 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