On Sat, 16 Oct 2021 at 19:33, Dave Houser <davehous...@gmail.com> wrote:
>
> Here is the version:
>
> Linux Libreswan 4.5 (XFRM) on 4.18.0-305.19.1.el8_4.x86_64
>
> I tried not setting dpdtimeout, but this message gets displayed when I try to
> re-add my config:
>
> "conn: "to-mx104-02" warning dpd settings are ignored unless both dpdtimeout=
> and dpddelay= are set"
With IKEv2, pluto treats the liveness exchange (nee dpd probe) the
same as any other. It uses:
> retransmit-timeout=...
If there's no response within that time the exchange initiator assumes
that the responder (peer) is dead. This way any exchange timeout will
trigger the creation of a new IKE pair. Hence the log line:
> #1: ... 60 second timeout exceeded after 7 retransmits. No response (or no
> acceptable response) to our IKEv2 message
I guess the above check should be dropped for IKEv2 (the alternative
would be to kind of sort of honour the old dpdtimeout). Can you file
a bug?
> Therefore I configured the following will need to wait until Monday to test
> again:
>
> dpddelay=5
> dpdtimeout=30
> dpdaction=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?
>
> On Fri, Oct 15, 2021 at 8:07 PM Andrew Cagney <andrew.cag...@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 <davehous...@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@lists.libreswan.org
>> > https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
