<div dir="ltr"><div dir="ltr"><a class="gmail_plusreply" id="plusReplyChip-0" href="mailto:paul@nohats.ca" tabindex="-1">@Paul Wouters</a> Thanks for the details as always. I think I should share more of my story of what we are trying to accomplish as it may help with finding the correct solution. <br>Our topology is the following:<br><br>| Juniper router 01 |
-----to-vsrx-01----- | Host01 | ------
to-vsrx-02 ----- | Juniper router 02 |<br><br>- Anything within "||" is a host<br>- Anything between "--" is a connection name<br><br>"Host01" is where Libreswan is running. <br>The host needs to connect to two separate Juniper routers on two separate ipsec tunnels. <br>"to-vsrx-01" is connection 01.<div>"to-vsrx-02" is connection 02.<br><br>Here is the current state of the to-vsrx-01 config</div><div><br><font face="monospace">conn to-vsrx-01b<br> auto=start <br> keyexchange=ike <br> authby=secret <br> ike=aes256-sha2_256;dh20 <br> esp=aes256-sha2_256<br> left=2.2.0.2 <br> leftid=2.2.0.2 <br> leftupdown=/opt/_updown_vti01 <br> right=3.3.0.2<br> leftsubnet=<a href="http://172.21.0.0/29">172.21.0.0/29</a><br> rightsubnet=<a href="http://0.0.0.0/0">0.0.0.0/0</a><br> dpddelay=5s<br> dpdtimeout=30s<br> dpdaction=hold<br> ikelifetime=24h<br> salifetime=24h</font><br><br>The purpose of the two connections is for redundancy / failover. If one router goes down, Host01 must have an active ipsec connection.<br>Our WANT is to make sure to-vsrx-01 and to-vsrx-02 connections have the same "rightsubnet" and are active at the same time. However, as we found, this is not possible in the latest release of libreswan. This was found from another email string I started with you, believe you are still working on fixing this as I have not heard back.<br>Not sure if Libreswan has this capability, but it would be great if a peer is down, Liberswan can recognize if a peer is dead, then shift traffic to the other connection. I don't believe this is possible. Therefore, as a workaround I scripted a way of doing this outside of Libreswan. However I rather not use this if the functionality is built into Libreswan.<br><br>The problem at hand, and why this email string was opened, is the Juniper Router admins need to be able to perform these commands at times. These commands perform a manual rekey of each IKE Phase. <br><br>Phase1 = clear security ike security-associations<br>Phase2 = clear security ipsec security-associations<br><br>First of all, automatic rekeying works just fine when the Juniper ike / sa lifetime and Libreswan ikelifetime or salifetime. Rekeying happens, the tunnel stays up. So I know rekeying is not a problem as far as I can tell. <br>When testing manually, running "clear security ike security-associations" on the Juniper, works fine as well, and IKE P1 rekeys manually when performed. The tunnel stays up.</div><div>When testing manually, running "clear security ipsec security-associations" on the Juniper, the tunnel immediately stops and is torn down on the Juniper and Libreswan side.<br>- Juniper shows no connection when checking ipsec SA status.</div><div>- Libreswan `ipsec whack --trafficstatus` shows no connection.</div><div>- Libreswan pluto.log shows two entries that appear after running the above command:<br><br>Oct 20 17:49:50.846500: "to-vsrx-01" #35: ESP traffic information: in=0B out=0B<br>Oct 20 17:49:50.938362: "to-vsrx-0b" #33: established IKE SA</div><div><br></div><div>Since the rekey-timers are not synced in anyway some times I will see these messages on the pluto.log</div><div><br></div><div>Oct 20 18:36:22.399410: "to-vsrx-01" #75: initiating rekey to replace IKE SA #73<br>Oct 20 18:36:22.405764: "to-vsrx-01" #75: sent CREATE_CHILD_SA request to rekey IKE SA<br>Oct 20 18:36:22.425346: "to-vsrx-01" #75: rekeyed #73 STATE_V2_REKEY_IKE_I1 and expire it remaining life 343.067679s<br>Oct 20 18:36:22.425640: "to-vsrx-01" #75: established IKE SA {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=DH20}<br>Oct 20 18:36:23.425747: "to-vsrx-01" #73: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 58.066437s and sending notification<br>Oct 20 18:36:23.428217: packet from <a href="http://3.3.0.2:500">3.3.0.2:500</a>: INFORMATIONAL response has no corresponding IKE SA; message dropped<br><br>Then nothing happens for a period of time, then the connection will re-establish. I am not sure what mechanism re-establishes this connection but I think it's based on re-keying on the Juniper end as a rekey from Libreswan looks like it failed above.<br></div><div><br>So I tried changing the following settings to narrow down which system is performing the rekey:<br>- Libreswan, I set the following<br><font face="monospace">ikelifetime=400s</font></div><div><font face="monospace">salifetime=500s</font></div><div>- Juniper I set the following:<br><font face="monospace">set security ike proposal ike-prop-01 lifetime-seconds 180<br>set security ipsec proposal ike-prop-01 lifetime-seconds 300</font><br><br>I performed the test again. After 300s, the connection was rebuilt. And the output from above will appear in the pluto.log</div><div><div>I noticed that this line changed to "180s" in the pluto.log:<br><br><font face="monospace">Oct 20 18:46:48.704224: "to-vsrx-01" #81: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 180.038216s and NOT sending notification</font><br></div><div> </div><div>Which I believe is based on the change I made on the Juniper Ike P1 rekey time. However that time is not necessarily accurate to how much time actually lapsed. As the connection was re-established after ~120s. But after testing again and again with the same timer settings, the actual time the connection tries to re-establish just seems to be random. Sometimes it's quick, and sometimes its longer, ~5 min. Be aware these two systems are in an enclosed env, and do not have access to NTP, not sure if that has anything to do with it?</div></div><div><br>So from what I understand, the connection will only be rebuilt based on if a re-keying happens. What I don't get is why the tunnel goes down in the first place, this is just a rekey of the SA being done manually from the Juniper. But the automatic rekey of the SA works fine. Is there some way to make Libreswan try to re-establish the connection, or recognize the connection went down outside of rekeying? I rather not have to set rekeys to such low values on both systems to keep the connection up.<br>The only workaround I have thought of so far is to integrate some logic in my script that keeps the tunnels up to try to reconnect if the tunnel goes down outside of libreswan. But I want to make sure there isn't some other way to do this functionality within Libreswan.<br><br>I apologize if you and Andrew have been beating a dead horse with me, and I do not mean to make you all repeat yourselfs, I just want to make sure I am clear in defining my problem in hopes that we can find a solution that fits. <br><br>Lastly, here is the status of the tunnel after the connection fails. Let me know what you all think.<br><br><font face="monospace"># ipsec auto status<br>ipsec auto: warning: obsolete command syntax used<br>000 using kernel interface: xfrm<br>000<br>000 interface lo UDP [::1]:500<br>000 interface lo UDP <a href="http://127.0.0.1:4500">127.0.0.1:4500</a><br>000 interface lo UDP <a href="http://127.0.0.1:500">127.0.0.1:500</a><br>000 interface ens3 UDP <a href="http://192.168.0.14:4500">192.168.0.14:4500</a><br>000 interface ens3 UDP <a href="http://192.168.0.14:500">192.168.0.14:500</a><br>000 interface ens4 UDP <a href="http://2.2.0.2:4500">2.2.0.2:4500</a><br>000 interface ens4 UDP <a href="http://2.2.0.2:500">2.2.0.2:500</a><br>000 interface virbr0 UDP <a href="http://192.168.122.1:4500">192.168.122.1:4500</a><br>000 interface virbr0 UDP <a href="http://192.168.122.1:500">192.168.122.1:500</a><br>000<br>000 fips mode=disabled;<br>000 SElinux=disabled<br>000 seccomp=disabled<br>000<br>000 config setup options:<br>000<br>000 configdir=/etc, configfile=/etc/ipsec.conf, secrets=/etc/ipsec.secrets, ipsecdir=/etc/ipsec.d<br>000 nssdir=/etc/ipsec.d, dumpdir=/run/pluto, statsbin=unset<br>000 dnssec-rootkey-file=/var/lib/unbound/root.key, dnssec-trusted=<unset><br>000 sbindir=/usr/sbin, libexecdir=/usr/libexec/ipsec<br>000 pluto_version=v4.5-216-g66c256610c-main, pluto_vendorid=OE-Libreswan-v4.5-216, audit-log=yes<br>000 nhelpers=-1, uniqueids=yes, dnssec-enable=yes, logappend=yes, logip=yes, shuntlifetime=900s, xfrmlifetime=30s<br>000 ddos-cookies-threshold=25000, ddos-max-halfopen=50000, ddos-mode=auto, ikev1-policy=accept<br>000 ikebuf=0, msg_errqueue=yes, crl-strict=no, crlcheckinterval=0, listen=<any>, nflog-all=0<br>000 ocsp-enable=no, ocsp-strict=no, ocsp-timeout=2, ocsp-uri=<unset><br>000 ocsp-trust-name=<unset><br>000 ocsp-cache-size=1000, ocsp-cache-min-age=3600, ocsp-cache-max-age=86400, ocsp-method=get<br>000 global-redirect=no, global-redirect-to=<unset><br>000 secctx-attr-type=32001<br>000 debug:<br>000<br>000 nat-traversal=yes, keep-alive=20, nat-ikeport=4500<br>000 virtual-private (%priv):<br>000 - allowed subnets: <a href="http://192.168.0.0/16">192.168.0.0/16</a>, <a href="http://172.16.0.0/12">172.16.0.0/12</a>, <a href="http://25.0.0.0/8">25.0.0.0/8</a>, <a href="http://100.64.0.0/10">100.64.0.0/10</a>, fd00::/8, fe80::/10, <unset-subnet><br>000<br>000 Kernel algorithms supported:<br>000<br>000 algorithm ESP encrypt: name=3DES_CBC, keysizemin=192, keysizemax=192<br>000 algorithm ESP encrypt: name=AES_CBC, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=AES_CCM_12, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=AES_CCM_16, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=AES_CCM_8, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=AES_CTR, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=AES_GCM_12, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=AES_GCM_16, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=AES_GCM_8, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=CAMELLIA_CBC, keysizemin=128, keysizemax=256<br>000 algorithm ESP encrypt: name=CHACHA20_POLY1305, keysizemin=256, keysizemax=256<br>000 algorithm ESP encrypt: name=NULL, keysizemin=0, keysizemax=0<br>000 algorithm ESP encrypt: name=NULL_AUTH_AES_GMAC, keysizemin=128, keysizemax=256<br>000 algorithm AH/ESP auth: name=AES_CMAC_96, key-length=128<br>000 algorithm AH/ESP auth: name=AES_XCBC_96, key-length=128<br>000 algorithm AH/ESP auth: name=HMAC_MD5_96, key-length=128<br>000 algorithm AH/ESP auth: name=HMAC_SHA1_96, key-length=160<br>000 algorithm AH/ESP auth: name=HMAC_SHA2_256_128, key-length=256<br>000 algorithm AH/ESP auth: name=HMAC_SHA2_256_TRUNCBUG, key-length=256<br>000 algorithm AH/ESP auth: name=HMAC_SHA2_384_192, key-length=384<br>000 algorithm AH/ESP auth: name=HMAC_SHA2_512_256, key-length=512<br>000 algorithm AH/ESP auth: name=NONE, key-length=0<br>000<br>000 IKE algorithms supported:<br>000<br>000 algorithm IKE encrypt: v1id=5, v1name=OAKLEY_3DES_CBC, v2id=3, v2name=3DES, blocksize=8, keydeflen=192<br>000 algorithm IKE encrypt: v1id=8, v1name=OAKLEY_CAMELLIA_CBC, v2id=23, v2name=CAMELLIA_CBC, blocksize=16, keydeflen=128<br>000 algorithm IKE encrypt: v1id=-1, v1name=n/a, v2id=20, v2name=AES_GCM_C, blocksize=16, keydeflen=128<br>000 algorithm IKE encrypt: v1id=-1, v1name=n/a, v2id=19, v2name=AES_GCM_B, blocksize=16, keydeflen=128<br>000 algorithm IKE encrypt: v1id=-1, v1name=n/a, v2id=18, v2name=AES_GCM_A, blocksize=16, keydeflen=128<br>000 algorithm IKE encrypt: v1id=13, v1name=OAKLEY_AES_CTR, v2id=13, v2name=AES_CTR, blocksize=16, keydeflen=128<br>000 algorithm IKE encrypt: v1id=7, v1name=OAKLEY_AES_CBC, v2id=12, v2name=AES_CBC, blocksize=16, keydeflen=128<br>000 algorithm IKE encrypt: v1id=-1, v1name=n/a, v2id=28, v2name=CHACHA20_POLY1305, blocksize=16, keydeflen=256<br>000 algorithm IKE PRF: name=HMAC_MD5, hashlen=16<br>000 algorithm IKE PRF: name=HMAC_SHA1, hashlen=20<br>000 algorithm IKE PRF: name=HMAC_SHA2_256, hashlen=32<br>000 algorithm IKE PRF: name=HMAC_SHA2_384, hashlen=48<br>000 algorithm IKE PRF: name=HMAC_SHA2_512, hashlen=64<br>000 algorithm IKE PRF: name=AES_XCBC, hashlen=16<br>000 algorithm IKE DH Key Exchange: name=MODP1536, bits=1536<br>000 algorithm IKE DH Key Exchange: name=MODP2048, bits=2048<br>000 algorithm IKE DH Key Exchange: name=MODP3072, bits=3072<br>000 algorithm IKE DH Key Exchange: name=MODP4096, bits=4096<br>000 algorithm IKE DH Key Exchange: name=MODP6144, bits=6144<br>000 algorithm IKE DH Key Exchange: name=MODP8192, bits=8192<br>000 algorithm IKE DH Key Exchange: name=DH19, bits=512<br>000 algorithm IKE DH Key Exchange: name=DH20, bits=768<br>000 algorithm IKE DH Key Exchange: name=DH21, bits=1056<br>000 algorithm IKE DH Key Exchange: name=DH31, bits=256<br>000<br>000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}<br>000<br>000 Connection list:<br>000<br>000 "to-vsrx-01b": <a href="http://172.21.0.0/29===2.2.0.2">172.21.0.0/29===2.2.0.2</a><2.2.0.2>...3.3.0.2<3.3.0.2>===<a href="http://0.0.0.0/0">0.0.0.0/0</a>; prospective erouted; eroute owner: #0<br>000 "to-vsrx-01b": oriented; my_ip=unset; their_ip=unset; my_updown=/opt/_updown_vti01;<br>000 "to-vsrx-01b": xauth us:none, xauth them:none, my_username=[any]; their_username=[any]<br>000 "to-vsrx-01b": our auth:secret, their auth:secret, our autheap:none, their autheap:none;<br>000 "to-vsrx-01b": modecfg info: us:none, them:none, modecfg policy:push, dns:unset, domains:unset, cat:unset;<br>000 "to-vsrx-01b": sec_label:unset;<br>000 "to-vsrx-01b": ike_life: 86400s; ipsec_life: 86400s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;<br>000 "to-vsrx-01b": retransmit-interval: 500ms; retransmit-timeout: 60s; iketcp:no; iketcp-port:4500;<br>000 "to-vsrx-01b": initial-contact:no; cisco-unity:no; fake-strongswan:no; send-vendorid:no; send-no-esp-tfc:no;<br>000 "to-vsrx-01b": policy: IKEv2+PSK+ENCRYPT+TUNNEL+PFS+UP+IKE_FRAG_ALLOW+ESN_NO;<br>000 "to-vsrx-01b": v2-auth-hash-policy: none;<br>000 "to-vsrx-01b": conn_prio: 29,0; interface: ens4; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none;<br>000 "to-vsrx-01b": nflog-group: unset; mark: unset; vti-iface:unset; vti-routing:no; vti-shared:no; nic-offload:auto;<br>000 "to-vsrx-01b": our idtype: ID_IPV4_ADDR; our id=2.2.0.2; their idtype: ID_IPV4_ADDR; their id=3.3.0.2<br>000 "to-vsrx-01b": dpd: action:hold; delay:5; timeout:30; nat-t: encaps:auto; nat_keepalive:yes; ikev1_natt:both<br>000 "to-vsrx-01b": newest ISAKMP SA: #33; newest IPsec SA: #0; conn serial: $4;<br>000 "to-vsrx-01b": IKE algorithms: AES_CBC_256-HMAC_SHA2_256-DH20<br>000 "to-vsrx-01b": IKEv2 algorithm newest: AES_CBC_256-HMAC_SHA2_256-DH20<br>000 "to-vsrx-01b": ESP algorithms: AES_CBC_256-HMAC_SHA2_256_128<br>000<br>000 Total IPsec connections: loaded 1, active 0<br>000<br>000 State Information: DDoS cookies not required, Accepting new IKE connections<br>000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0)<br>000 IPsec SAs: total(0), authenticated(0), anonymous(0)<br>000<br>000 #33: "to-vsrx-01b":500 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); REKEY in 85040s; newest ISAKMP; idle;<br>000<br>000 Bare Shunt list:<br>000<br></font><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 18, 2021 at 10:36 PM Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</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, Dave Houser wrote:<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>
I recommend dpdaction=hold and let the revive/restart mechanism handle<br>
the 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<br>
> timeout?<br>
<br>
In IKEv1, IKE messages are sent with a random MSGID. If you sent one IKE<br>
request and you don't get a reply, you can still send another request.<br>
For example, you could send a Quick Mode request, hear no reply, and<br>
decide to send a DPD request. So the way DPD is implemented is that if<br>
it does not get a reply within "retransmit-interval", it resends the<br>
existing packet and doubles the interval. (eg 500ms, 1s, 2s). When it<br>
hits the "retransmit-timeout", the exchange is deemed lost and no more<br>
packet retransmits happen. But the daemon has DPD timer, and it will<br>
send a _new_ DPD request after "dpddelay" time. if that packet also gets<br>
no answer, at the "dpdtimeout" time, the entire IKE SA and and IPsec<br>
SA's are torn down as the peer is deemed lost.<br>
<br>
With IKEv2, IKE messages are sent with a sequential MSGID. You cannot<br>
send #3 if you did not receive a reply for #2. So here, the method of<br>
sending new IKE requests for DPD does not work. If packet #7 is a DPD<br>
packet, and it gets no reply, there can be no further communication with<br>
the peer. You cannot send another DPD as #8. So, after the<br>
retransmit-timeout is reached for packet #7, the whole thing is torn<br>
down.<br>
<br>
Basically, dpdtimeout is a no-op for IKEv2, as the exchange is<br>
dead when retransmit-timeout is reached.<br>
<br>
We have been wanting to remove dpdaction (and only do "hold") and let<br>
other mechanisms do delete or restart. And we have been wanting to<br>
remove dpdtimeout by only using the retransmit-timeout. Then dpddelay=<br>
is the only option left to determine how often one wants to test if<br>
the connection is still there if the IPsec and IKE is idle and not<br>
sending any packets.<br>
<br>
And to complete the story, seperate from all of this are NAT keepalives,<br>
which any IKE peer behind NAT will send every 20 seconds just to ensure<br>
the NAT gateway doesn't close the port mapping used for ESPinUDP and<br>
IKE. These are 1 byte packets that the receiver's kernel eats up and<br>
the userland never sees these at all.<br>
<br>
Paul<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>
> 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.<br>
> The tunnel will just stay down until a new rekey is initialized by the far end SA, in which case the connection will rebuild.<br>
> 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<br>
> 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>
> <br>
> <br>
><br>
</blockquote></div></div>