<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you Paul, my old version was the issue and the behavior is as expected now.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Also, thanks for the tip on creating an interface pair.  I'll give that a try.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
-Mike</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Paul Wouters <paul@nohats.ca><br>
<b>Sent:</b> Tuesday, July 13, 2021 7:07 PM<br>
<b>To:</b> Mike Brown <mikebrown@pws.bz><br>
<b>Cc:</b> swan@lists.libreswan.org <swan@lists.libreswan.org><br>
<b>Subject:</b> Re: [Swan] DPD settings in config does not trigger updown script on disconnect</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Tue, 13 Jul 2021, Mike Brown wrote:<br>
<br>
> Subject: [Swan] DPD settings in config does not trigger updown script on<br>
>     disconnect<br>
> <br>
> Hello, first time writing the list.  Let me know if this is going to the wrong place.<br>
<br>
This is exactly the right place :)<br>
<br>
> My overall goal is for a peer running a pair HA tunnels to terminate at my libreswan node (so my node has 2<br>
> tunnels using the same right/left-subnets in their .conf, but different marks).  My local "switching" to implement<br>
> the HA behavior is an updown script - on up/route it writes iptables connmark rules to send packets to the mark of<br>
> the tunnel referenced in the updown invocation.  (I have no preferred "primary".)  On down/unroute it removes<br>
> rules for the tunnel referenced in the invocation, leaving rules to the remaining tunnel mark only.<br>
<br>
Note that a better more modern design would be using the XFRM<br>
interfaces. Then you can create an ipsec1 and ipsec2 interface for your<br>
tunnels, and then you can just handle things with regular routing.<br>
Whichever interface you route into, the traffic gets encrypted for that<br>
endpoint.<br>
<br>
But, your solution _should_ work too!<br>
<br>
> Libreswans.)  All router boxes are Libreswan 3.23, Ubuntu 18.04.5 LTS, running in the AWS cloud free-tier.<br>
<br>
3.23 is very very old - January 2018. That is from before Tesla launched<br>
a car into space. We have done 14 releases since that version. I<br>
recommend grapping the 4.4 tar.gz and running "make deb". You might need<br>
to tweak some settings in mk/config.mk to disable some things due to<br>
older versions of nss/unbound libraries.<br>
<br>
> HA switching behavior works as intended if I issue "ipsec auto --delete p1_to_n" while on P1.<br>
<br>
> But, where I am having trouble is when I try to make this more realistic by suddenly blocking traffic instead of<br>
> issuing a --delete.  My expectation for this scenario was that DPD would detect the disconnect, down the tunnel<br>
> (as suggested in libreswan DPD code tests) and call my updown script; but that has not been the case.<br>
<br>
Yes, it should do that.<br>
<br>
>  I see NAT-T<br>
> packets go out, but not DPD and lastdpd=-1 never changes.  If I disable NAT-T (which may cause me other problems<br>
> with AWS public addressing) I do see an R_U_THERE and _ACK, but only once.<br>
<br>
That is actually a bug that was fixed :)<br>
<br>
NAT-T keepalives are only needed for libreswan behind a NAT. It sends a<br>
1 byte packet every 20s that the other end's kernel eats up just to keep the NAT<br>
mapping open on the NAT routers in the path. When there is no NAT, these<br>
packets are not send, but older versions send 1 of them by mistake.<br>
<br>
But DPD should really kick in.<br>
<br>
>  After the first NAT-T disabled DPD<br>
> exchange, I see "DPD: no need to send or schedule DPD for replaced IPsec SA" repeatedly (every 30 seconds,<br>
> matching my dpdtimeout) but I never see another DPD exchange.<br>
<br>
Seems like a bug. What this means is that you have two IPsec SAs for the<br>
same connection. This happens when your connection rekeys. The older<br>
rekeyed ones lingers for a bit to ensure overlap between old and new<br>
tunnel. If the old one triggers a DPD event, it ignores it since it is<br>
expected to be "idle" since it is not the newest active tunnel. In your<br>
case, it seems there is a false positive for this check.<br>
<br>
> I've done quite a bit of diving to see what's happening and am happy to drop both my digest and/or raw-logs here,<br>
> but as a new user I first wanted to check if I'm just missing something entirely before I completely word vomit on<br>
> the mail list.<br>
<br>
Please try a newer version first. If 4.4 fails for you too, we are happy<br>
to help you investigate and fix your issue and make the world a better<br>
place. But we don't really want to waste our time on looking at very<br>
old versions of our code - there is not much gain to the world at large<br>
with that.<br>
<br>
Cheers,<br>
<br>
Paul<br>
</div>
</span></font></div>
</body>
</html>