> With IKEv2, pluto treats the liveness exchange (nee dpd probe) the
> same as any other. It uses:
> retransmit-timeout=...
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.
Oct 18 17:17:34.768743: "to-vsrx-01" #62: deleting state
(STATE_V2_ESTABLISHED_IKE_SA) aged 300.047581s and NOT sending notification
Oct 18 17:17:34.769920: "to-vsrx-01" #62: deleting IKE SA but connection is
supposed to remain up; schedule EVENT_REVIVE_CONNS
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
Oct 18 17:17:34.770697: "to-vsrx-01" #64: initiating IKEv2 connection
Oct 18 17:17:34.779194: "to-vsrx-01" #64: sent IKE_SA_INIT request
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}
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'
Oct 18 17:17:34.910602: "to-vsrx-01" #65: up-client output:
net.ipv4.conf.vti01.disable_policy = 1
Oct 18 17:17:34.946892: "to-vsrx-01" #65: up-client output:
net.ipv4.conf.vti01.rp_filter = 0
Oct 18 17:17:34.951496: "to-vsrx-01" #65: up-client output:
net.ipv4.conf.vti01.forwarding = 1
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}
Oct 18 17:17:34.953122: netlink_acquire got message with length 116 < 232
bytes; ignore message
Oct 18 17:17:34.953132: netlink_acquire got message with length 116 < 232
bytes; ignore message
Oct 18 17:17:34.953150: netlink_acquire got message with length 116 < 232
bytes; ignore message
Oct 18 17:17:34.953160: netlink_acquire got message with length 60 < 232
bytes; ignore message
Oct 18 17:17:34.953166: netlink_acquire got message with length 52 < 232
bytes; ignore message
Oct 18 17:17:34.953195: netlink_acquire got message with length 52 < 232
bytes; ignore message
*This led me to believe there is another setting that I could adjust in
libreswan that is waiting ~300s before trying to retransmit. Is there a
setting that controls " aged 300.047581s and NOT sending notifications"?*
>> #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 honour the old dpdtimeout). Can you file a bug?
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.
On Sat, Oct 16, 2021 at 10:08 PM Andrew Cagney <andrew.cag...@gmail.com>
wrote:
> 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
