<div dir="ltr">I've tried the changes you suggested, but the result is still the same.<div><br></div><div>In the conn config, I've added retransmit-timeout and retransmit-interval.</div><div>```</div><div><div>conn customer</div><div> auto=start</div><div> authby=secret</div><div> dpddelay=40</div><div> dpdtimeout=120</div><div> dpdaction=restart </div><div> pfs=yes</div><div> ike=aes256-sha1</div><div> phase2alg=aes256-sha1</div><div> left=%defaultroute</div><div> leftid=184.X.X.X</div><div> leftsourceip=184.X.X.X</div><div> leftsubnet=184.X.X.X/32</div><div> right=64.Y.Y.Y</div><div> rightid=64.Y.Y.Y</div><div> rightsubnet=128.B.B.B/32</div><div> retransmit-timeout=40</div><div> retransmit-interval=2000</div></div><div>```</div><div><br></div><div>While the output for `ipsec whack status` shows that will try again in 2 seconds, it still tries to reconnect multiple times per second.</div><div>```</div><div><div>app1[~]$ sudo ipsec whack --status | grep customer</div><div>000 "customer": 184.X.X.X/32===172.A.A.A[184.X.X.X]---172.A.A.1...64.Y.Y.Y<64.Y.Y.Y>===128.B.B.B/32; prospective erouted; eroute owner: #0</div><div>000 "customer": oriented; my_ip=184.X.X.X; their_ip=unset</div><div>000 "customer": xauth us:none, xauth them:none, my_username=[any]; their_username=[any]</div><div>000 "customer": our auth:secret, their auth:secret</div><div>000 "customer": modecfg info: us:none, them:none, modecfg policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset, cat:unset;</div><div>000 "customer": labeled_ipsec:no;</div><div>000 "customer": policy_label:unset;</div><div>000 "customer": ike_life: 3600s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;</div><div>000 "customer": retransmit-interval: 2000ms; retransmit-timeout: 40s;</div><div>000 "customer": sha2-truncbug:no; initial-contact:no; cisco-unity:no; fake-strongswan:no; send-vendorid:no; send-no-esp-tfc:no;</div><div>000 "customer": policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO;</div><div>000 "customer": conn_prio: 32,32; interface: ens3; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none;</div><div>000 "customer": nflog-group: unset; mark: unset; vti-iface:unset; vti-routing:no; vti-shared:no;</div><div>000 "customer": dpd: action:restart; delay:40; timeout:120; nat-t: encaps:auto; nat_keepalive:yes; ikev1_natt:both</div><div>000 "customer": newest ISAKMP SA: #0; newest IPsec SA: #0;</div><div>000 "customer": IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP2048(14), AES_CBC(7)_256-SHA1(2)-MODP1536(5)</div><div>000 "customer": IKE algorithms found: AES_CBC(7)_256-SHA1(2)-MODP2048(14), AES_CBC(7)_256-SHA1(2)-MODP1536(5)</div><div>000 "customer": ESP algorithms wanted: AES(12)_256-SHA1(2)</div><div>000 "customer": ESP algorithms loaded: AES(12)_256-SHA1(2)</div><div>000 #155: "customer":4500 STATE_MAIN_I3 (sent MI3, expecting MR3); EVENT_v1_RETRANSMIT in 2s; nodpd; idle; import:admin initiate</div><div>155: pending Phase 2 for "customer" replacing #0</div></div><div>```</div><div>It's not stopping after 40 seconds, not after 60 seconds, it just goes on.</div><div>Notice it says `EVENT_v1_RETRANSMIT in 2s`, it doesnt increment on subsequent checks.</div><div>Here is a sample of the `/var/log/auth.log` file for a little more over a minute using the above config, notice it doesnt actually wait 2 seconds as it said above: <span style="color:rgb(68,68,68);font-family:Roboto,Helvetica,Arial,sans-serif;font-size:13px"><a href="https://goo.gl/Dbn9f8">https://goo.gl/Dbn9f8</a></span></div><div><span style="color:rgb(68,68,68);font-family:Roboto,Helvetica,Arial,sans-serif;font-size:13px">Notice it goes from #1 to #</span><font color="#444444" face="Roboto, Helvetica, Arial, sans-serif">1585 in 64 seconds, and it's not gonna stop unless I stop ipsec.</font></div><div><font color="#444444" face="Roboto, Helvetica, Arial, sans-serif"><br></font></div><div><font color="#444444" face="Roboto, Helvetica, Arial, sans-serif">I tried to change `</font>auto=ondemand`, while it doesnt try to reconnect on ipsec (re)start, the moment the tunnel is needed, it start flooding auth.log in the same manner, multiple times per second, without stopping.</div><div><br></div><div>I tried to add `keyingtries=2`, it doesnt change the behaviour, it goes on forever.</div><div><br></div><div><br><div>Again, I don't care that much about the tunnel not working as I care about flooding the log file and banging on customer firewall, but I would like to keep my end of the tunnel up for client to upgrade her end and test the connection.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 18, 2017 at 6:02 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Fri, 16 Jun 2017, Bob Cribbs wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am in the process of upgrading from libreswan 3.12 to libreswan 3.20 and I'm noticing some weird behaviour on tunnels retransmit interval.<br>
<br>
If the tunnel is not connecting, it retransmits a few times per second, and flooding my /var/auth.log file and banging on our customer's firewall.<br>
</blockquote>
<br></span>
This change of behaviour should only happen when you have auto=start<br>
Previously, when the remote send a DELETE, we would end up in auto=add<br>
state, waiting on them to initiate. Now, since the conn is configured<br>
with auto=start, we try again.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
000 #42: "customer":4500 STATE_QUICK_I1 (sent QI1, expecting QR1); EVENT_v1_RETRANSMIT in 0s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate<br>
000 #41: "customer":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 3052s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin<br>
initiate<br>
</blockquote>
<br></span>
So I guess the IKE SA comes up, but there is an IPsec SA configuration<br>
mismatch?<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
000 "customer": retransmit-interval: 500ms; retransmit-timeout: 60s;<br>
</blockquote>
<br>
</span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
000 #51: "customer":500 STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_v1_RETRANSMIT in 0s; nodpd; idle; import:admin initiate<br>
</blockquote>
<br></span>
Although this shows there is no existinng IKE SA here.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Notice both of them have `EVENT_v1_RETRANSMIT in 0s`, sometimes it's at -1 too.<br>
</blockquote>
<br></span>
The initial timer is 500ms, then it doubles (1s, 2s, 4s until it hits<br>
the timeout of 60s)<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would like to keep this tunnel configured as the customer works on updating their settings so they can test it's working, but the auth.log files ends up<br>
in GB of space in a day and the customer is not happy with the firewall trouble.<br>
</blockquote>
<br></span>
So in your case, you could use auto=add, which means "load but not<br>
initiate" or you can use auto=ondemand (same, but also try initiate<br>
when there is outgoing traffic matching the tunnel)<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I have other tunnels that are failing too, but their retransmit interval is incremental.<br>
</blockquote>
<br></span>
That's what I would expect, yes.<span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Is there a config Im missing to increase the time between retransmits in this scenario?<br>
And what can I do to make it incremental?<br>
</blockquote>
<br></span>
There is retransmit-timeout= and retransmit-interval=. And also<br>
keyingtries=. But I think auto=add would be best for you for now,<br>
until the misconfiguration is resolved.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div></div>