[Swan] dead peer deduction not working

Paul Wouters paul at nohats.ca
Tue Oct 19 02:36:48 UTC 2021


On Sat, 16 Oct 2021, Dave Houser wrote:

> Therefore I configured the following will need to wait until Monday to test again:
> 
>     dpddelay=5
>     dpdtimeout=30
>     dpdaction=restart

I recommend dpdaction=hold and let the revive/restart mechanism handle
the restart.

> >in IKEv2 it is a retransmit timeout that will trigger a restart.
> 
> By retransmit timeout, do you mean rekeying? or do you mean the dpdtimeout? If neither, can you clarify what you mean by retransmit
> timeout?

In IKEv1, IKE messages are sent with a random MSGID. If you sent one IKE
request and you don't get a reply, you can still send another request.
For example, you could send a Quick Mode request, hear no reply, and
decide to send a DPD request. So the way DPD is implemented is that if
it does not get a reply within "retransmit-interval", it resends the
existing packet and doubles the interval. (eg 500ms, 1s, 2s). When it
hits the "retransmit-timeout", the exchange is deemed lost and no more
packet retransmits happen. But the daemon has DPD timer, and it will
send a _new_ DPD request after "dpddelay" time. if that packet also gets
no answer, at the "dpdtimeout" time, the entire IKE SA and and IPsec
SA's are torn down as the peer is deemed lost.

With IKEv2, IKE messages are sent with a sequential MSGID. You cannot
send #3 if you did not receive a reply for #2. So here, the method of
sending new IKE requests for DPD does not work. If packet #7 is a DPD
packet, and it gets no reply, there can be no further communication with
the peer. You cannot send another DPD as #8. So, after the
retransmit-timeout is reached for packet #7, the whole thing is torn
down.

Basically, dpdtimeout is a no-op for IKEv2, as the exchange is
dead when retransmit-timeout is reached.

We have been wanting to remove dpdaction (and only do "hold") and let
other mechanisms do delete or restart. And we have been wanting to
remove dpdtimeout by only using the retransmit-timeout. Then dpddelay=
is the only option left to determine how often one wants to test if
the connection is still there if the IPsec and IKE is idle and not
sending any packets.

And to complete the story, seperate from all of this are NAT keepalives,
which any IKE peer behind NAT will send every 20 seconds just to ensure
the NAT gateway doesn't close the port mapping used for ESPinUDP and
IKE. These are 1 byte packets that the receiver's kernel eats up and
the userland never sees these at all.

Paul

> On Fri, Oct 15, 2021 at 8:07 PM Andrew Cagney <andrew.cagney at gmail.com> wrote:
>       Are you running libreswan 4.5?  If not can you try that or mainline?
>
>       This is what 4.5 looks like when it revives a connection:
>
>       "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_V2_ESTABLISHED_IKE_SA:
>       retransmission; will wait 1 seconds for response
>       "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_V2_ESTABLISHED_IKE_SA: 60
>       second timeout exceeded after 7 retransmits.  No response (or no
>       acceptable response) to our IKEv2 message
>       "westnet-eastnet-ipv4-psk-ikev2" #1: liveness action - restarting all
>       connections that share this peer
>       "westnet-eastnet-ipv4-psk-ikev2": terminating SAs using this connection
>       "westnet-eastnet-ipv4-psk-ikev2" #2: ESP traffic information: in=84B out=84B
>       "westnet-eastnet-ipv4-psk-ikev2" #3: initiating IKEv2 connection
>       "westnet-eastnet-ipv4-psk-ikev2" #3: established IKE SA; authenticated
>       using authby=secret and peer ID_FQDN '@west'
>       "westnet-eastnet-ipv4-psk-ikev2" #4: established Child SA; IPsec
>       tunnel [192.0.2.0-192.0.2.255:0-65535 0] ->
>       [192.0.1.0-192.0.1.255:0-65535 0] {ESP=>0x5ef243d3 <0xdb669f85
>       xfrm=AES_GCM_16_256-NONE NATOA=none NATD=none DPD=active}
>
>       https://testing.libreswan.org/v4.5-0-gf36ab1b1df-main/ikev2-liveness-02/OUTPUT/east.pluto.log.gz
>
>       For IKEv2 the only settings that matter are (values are what the above
>       test uses):
>
>       > dpdaction=restart
>       > dpddelay=5
>
>       I'm pretty sure:
>
>       > dpdtimeout=30
>
>       is ignored - in IKEv2 it is a retransmit timeout that will trigger a restart.
>
>       On Fri, 15 Oct 2021 at 17:34, Dave Houser <davehouser1 at gmail.com> wrote:
>       >
>       > Hello,
>       >
>       > I am trying to implement dead peer detection. However when the far end SA kills the connection, the tunnel is never rebuilt.
>       The tunnel will just stay down until a new rekey is initialized by the far end SA, in which case the connection will rebuild.
>       BTW the far end is a Juniper SRX.
>       >
>       > Here is the output of /var/log/pluto.log right after I kill the connection on the far end, nothing else:
>       >
>       > Oct 15 23:33:10.518021: "to-vsrx-01" #6: ESP traffic information: in=756B out=1KB
>       > Oct 15 23:33:10.584609: "to-vsrx-01" #3: established IKE SA
>       >
>       >
>       > Here is my config:
>       >
>       > conn to-vsrx-01
>       >     auto=start
>       >     keyexchange=ike
>       >     authby=secret
>       >     ike=aes256-sha2_256;dh20
>       >     esp=aes256-sha2_256
>       >     left=2.2.1.2
>       >     leftid=2.2.1.2
>       >     leftsubnet=172.21.0.0/29
>       >     leftupdown=/opt/_updown_vti01
>       >     right=3.3.0.2
>       >     rightsubnet=0.0.0.0/0
>       >     dpddelay=1s
>       >     dpdtimeout=1s
>       >     dpdaction=restart
>       >
>       > Here is my leftupdown script I use
>       >
>       > #!/bin/bash
>       >
>       > set -o nounset
>       > set -o errexit
>       >
>       > VTI_IF="vti01"
>       >
>       > case "${PLUTO_VERB}" in
>       >     up-client)
>       >         ip tunnel add $VTI_IF local 2.2.0.2 remote 3.3.0.2 mode vti key 42
>       >         ip link set $VTI_IF up
>       >         ip addr add  172.21.0.3 dev $VTI_IF
>       >         ip route add 172.21.0.0/29 dev $VTI_IF
>       >         ip route add 10.0.26.0/24 dev $VTI_IF
>       >         sysctl -w "net.ipv4.conf.$VTI_IF.disable_policy=1"
>       >         sysctl -w "net.ipv4.conf.$VTI_IF.rp_filter=0"
>       >         sysctl -w "net.ipv4.conf.$VTI_IF.forwarding=1"
>       >         ;;
>       >     down-client)
>       >         ip tunnel del $VTI_IF
>       >         ;;
>       > esac
>       >
>       > Am I misunderstanding what the dpd settings do? I need this tunnel to try to re-establish if it ever goes down. How can I
>       accomplish this?
>       >
>       > - Dave
>       >
>       > _______________________________________________
>       > Swan mailing list
>       > Swan at lists.libreswan.org
>       > https://lists.libreswan.org/mailman/listinfo/swan
> 
> 
>


More information about the Swan mailing list