<div dir="ltr"><div>> With IKEv2, pluto treats the liveness exchange (nee dpd probe) the<br>> same as any other. It uses:<br>> retransmit-timeout=...<br></div><div><br></div><div>I tried setting the "retransmit-timeout" setting to something lower like "5s", then readded my config and turned up the tunnel. I then cleared the SA on the Juniper, and then waited 5 seconds, nothing happened in the logs. HOwever after ~300s I see this in the logs.<br><br><font face="monospace">Oct 18 17:17:34.768743: "to-vsrx-01" #62: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 300.047581s and NOT sending notification</font><br><font face="monospace">Oct 18 17:17:34.769920: "to-vsrx-01" #62: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS</font><br><font face="monospace">Oct 18 17:17:34.770566: "to-vsrx-01": initiating connection 'to-vsrx-01' with serial $6 which received a Delete/Notify but must remain up per local policy</font><br><font face="monospace">Oct 18 17:17:34.770697: "to-vsrx-01" #64: initiating IKEv2 connection</font><br><font face="monospace">Oct 18 17:17:34.779194: "to-vsrx-01" #64: sent IKE_SA_INIT request</font><br><font face="monospace">Oct 18 17:17:34.792279: "to-vsrx-01" #64: sent IKE_AUTH request {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=DH20}</font><br><font face="monospace">Oct 18 17:17:34.797184: "to-vsrx-01" #64: established IKE SA; authenticated using authby=secret and peer ID_IPV4_ADDR '3.3.0.2'</font><br><font face="monospace">Oct 18 17:17:34.910602: "to-vsrx-01" #65: up-client output: net.ipv4.conf.vti01.disable_policy = 1</font><br><font face="monospace">Oct 18 17:17:34.946892: "to-vsrx-01" #65: up-client output: net.ipv4.conf.vti01.rp_filter = 0</font><br><font face="monospace">Oct 18 17:17:34.951496: "to-vsrx-01" #65: up-client output: net.ipv4.conf.vti01.forwarding = 1</font><br><font face="monospace">Oct 18 17:17:34.952857: "to-vsrx-01" #65: established Child SA; IPsec tunnel [172.21.0.0-172.21.0.7:0-65535 0] -> [0.0.0.0-255.255.255.255:0-65535 0] {ESP=>0x37d6ca25 <0x37a32da4 xfrm=AES_CBC_256-HMAC_SHA2_256_128 DPD=active}</font><br><font face="monospace">Oct 18 17:17:34.953122: netlink_acquire got message with length 116 < 232 bytes; ignore message</font><br><font face="monospace">Oct 18 17:17:34.953132: netlink_acquire got message with length 116 < 232 bytes; ignore message</font><br><font face="monospace">Oct 18 17:17:34.953150: netlink_acquire got message with length 116 < 232 bytes; ignore message</font><br><font face="monospace">Oct 18 17:17:34.953160: netlink_acquire got message with length 60 < 232 bytes; ignore message</font><br><font face="monospace">Oct 18 17:17:34.953166: netlink_acquire got message with length 52 < 232 bytes; ignore message</font><br><font face="monospace">Oct 18 17:17:34.953195: netlink_acquire got message with length 52 < 232 bytes; ignore message</font><br><br><font face="arial, sans-serif"><b>This led me to believe there is another setting that I could adjust in libreswan that is waiting ~300s before trying to retransmit. <br>Is there a setting that controls "
aged 300.047581s and NOT sending notifications"?</b></font><font face="monospace"><br></font><br>>> #1: ... 60 second timeout exceeded after 7 retransmits. No response (or no acceptable response) to our IKEv2 message<br>><br>> I guess the above check should be dropped for IKEv2 (the alternative<br>> would be to kind of honour the old dpdtimeout). Can you file a bug?<br><br>I am not clear on what the bug is here. This log entry does not appear in my logs. Is this an entry in your logs? Would be happy to open a bug, can you help clarify what the problem is and how I can recreate it in my system? apologies if I am confused. <br><br><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 16, 2021 at 10:08 PM Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com">andrew.cagney@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 16 Oct 2021 at 19:33, Dave Houser <<a href="mailto:davehouser1@gmail.com" target="_blank">davehouser1@gmail.com</a>> wrote:<br>
><br>
> Here is the version:<br>
><br>
> Linux Libreswan 4.5 (XFRM) on 4.18.0-305.19.1.el8_4.x86_64<br>
><br>
> I tried not setting dpdtimeout, but this message gets displayed when I try to re-add my config:<br>
><br>
> "conn: "to-mx104-02" warning dpd settings are ignored unless both dpdtimeout= and dpddelay= are set"<br>
<br>
With IKEv2, pluto treats the liveness exchange (nee dpd probe) the<br>
same as any other. It uses:<br>
> retransmit-timeout=...<br>
If there's no response within that time the exchange initiator assumes<br>
that the responder (peer) is dead. This way any exchange timeout will<br>
trigger the creation of a new IKE pair. Hence the log line:<br>
<br>
> #1: ... 60 second timeout exceeded after 7 retransmits. No response (or no acceptable response) to our IKEv2 message<br>
<br>
I guess the above check should be dropped for IKEv2 (the alternative<br>
would be to kind of sort of honour the old dpdtimeout). Can you file<br>
a bug?<br>
<br>
> Therefore I configured the following will need to wait until Monday to test again:<br>
><br>
> dpddelay=5<br>
> dpdtimeout=30<br>
> dpdaction=restart<br>
><br>
> >in IKEv2 it is a retransmit timeout that will trigger a restart.<br>
><br>
> By retransmit timeout, do you mean rekeying? or do you mean the dpdtimeout? If neither, can you clarify what you mean by retransmit timeout?<br>
><br>
> On Fri, Oct 15, 2021 at 8:07 PM Andrew Cagney <<a href="mailto:andrew.cagney@gmail.com" target="_blank">andrew.cagney@gmail.com</a>> wrote:<br>
>><br>
>> Are you running libreswan 4.5? If not can you try that or mainline?<br>
>><br>
>> This is what 4.5 looks like when it revives a connection:<br>
>><br>
>> "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_V2_ESTABLISHED_IKE_SA:<br>
>> retransmission; will wait 1 seconds for response<br>
>> "westnet-eastnet-ipv4-psk-ikev2" #1: STATE_V2_ESTABLISHED_IKE_SA: 60<br>
>> second timeout exceeded after 7 retransmits. No response (or no<br>
>> acceptable response) to our IKEv2 message<br>
>> "westnet-eastnet-ipv4-psk-ikev2" #1: liveness action - restarting all<br>
>> connections that share this peer<br>
>> "westnet-eastnet-ipv4-psk-ikev2": terminating SAs using this connection<br>
>> "westnet-eastnet-ipv4-psk-ikev2" #2: ESP traffic information: in=84B out=84B<br>
>> "westnet-eastnet-ipv4-psk-ikev2" #3: initiating IKEv2 connection<br>
>> "westnet-eastnet-ipv4-psk-ikev2" #3: established IKE SA; authenticated<br>
>> using authby=secret and peer ID_FQDN '@west'<br>
>> "westnet-eastnet-ipv4-psk-ikev2" #4: established Child SA; IPsec<br>
>> tunnel [192.0.2.0-192.0.2.255:0-65535 0] -><br>
>> [192.0.1.0-192.0.1.255:0-65535 0] {ESP=>0x5ef243d3 <0xdb669f85<br>
>> xfrm=AES_GCM_16_256-NONE NATOA=none NATD=none DPD=active}<br>
>><br>
>> <a href="https://testing.libreswan.org/v4.5-0-gf36ab1b1df-main/ikev2-liveness-02/OUTPUT/east.pluto.log.gz" rel="noreferrer" target="_blank">https://testing.libreswan.org/v4.5-0-gf36ab1b1df-main/ikev2-liveness-02/OUTPUT/east.pluto.log.gz</a><br>
>><br>
>> For IKEv2 the only settings that matter are (values are what the above<br>
>> test uses):<br>
>><br>
>> > dpdaction=restart<br>
>> > dpddelay=5<br>
>><br>
>> I'm pretty sure:<br>
>><br>
>> > dpdtimeout=30<br>
>><br>
>> is ignored - in IKEv2 it is a retransmit timeout that will trigger a restart.<br>
>><br>
>> On Fri, 15 Oct 2021 at 17:34, Dave Houser <<a href="mailto:davehouser1@gmail.com" target="_blank">davehouser1@gmail.com</a>> wrote:<br>
>> ><br>
>> > Hello,<br>
>> ><br>
>> > 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.<br>
>> ><br>
>> > Here is the output of /var/log/pluto.log right after I kill the connection on the far end, nothing else:<br>
>> ><br>
>> > Oct 15 23:33:10.518021: "to-vsrx-01" #6: ESP traffic information: in=756B out=1KB<br>
>> > Oct 15 23:33:10.584609: "to-vsrx-01" #3: established IKE SA<br>
>> ><br>
>> ><br>
>> > Here is my config:<br>
>> ><br>
>> > conn to-vsrx-01<br>
>> > auto=start<br>
>> > keyexchange=ike<br>
>> > authby=secret<br>
>> > ike=aes256-sha2_256;dh20<br>
>> > esp=aes256-sha2_256<br>
>> > left=2.2.1.2<br>
>> > leftid=2.2.1.2<br>
>> > leftsubnet=<a href="http://172.21.0.0/29" rel="noreferrer" target="_blank">172.21.0.0/29</a><br>
>> > leftupdown=/opt/_updown_vti01<br>
>> > right=3.3.0.2<br>
>> > rightsubnet=<a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a><br>
>> > dpddelay=1s<br>
>> > dpdtimeout=1s<br>
>> > dpdaction=restart<br>
>> ><br>
>> > Here is my leftupdown script I use<br>
>> ><br>
>> > #!/bin/bash<br>
>> ><br>
>> > set -o nounset<br>
>> > set -o errexit<br>
>> ><br>
>> > VTI_IF="vti01"<br>
>> ><br>
>> > case "${PLUTO_VERB}" in<br>
>> > up-client)<br>
>> > ip tunnel add $VTI_IF local 2.2.0.2 remote 3.3.0.2 mode vti key 42<br>
>> > ip link set $VTI_IF up<br>
>> > ip addr add 172.21.0.3 dev $VTI_IF<br>
>> > ip route add <a href="http://172.21.0.0/29" rel="noreferrer" target="_blank">172.21.0.0/29</a> dev $VTI_IF<br>
>> > ip route add <a href="http://10.0.26.0/24" rel="noreferrer" target="_blank">10.0.26.0/24</a> dev $VTI_IF<br>
>> > sysctl -w "net.ipv4.conf.$VTI_IF.disable_policy=1"<br>
>> > sysctl -w "net.ipv4.conf.$VTI_IF.rp_filter=0"<br>
>> > sysctl -w "net.ipv4.conf.$VTI_IF.forwarding=1"<br>
>> > ;;<br>
>> > down-client)<br>
>> > ip tunnel del $VTI_IF<br>
>> > ;;<br>
>> > esac<br>
>> ><br>
>> > 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?<br>
>> ><br>
>> > - Dave<br>
>> ><br>
>> > _______________________________________________<br>
>> > Swan mailing list<br>
>> > <a href="mailto:Swan@lists.libreswan.org" target="_blank">Swan@lists.libreswan.org</a><br>
>> > <a href="https://lists.libreswan.org/mailman/listinfo/swan" rel="noreferrer" target="_blank">https://lists.libreswan.org/mailman/listinfo/swan</a><br>
</blockquote></div>