I've tried the changes you suggested, but the result is still the same. In the conn config, I've added retransmit-timeout and retransmit-interval. ``` conn customer auto=start authby=secret dpddelay=40 dpdtimeout=120 dpdaction=restart pfs=yes ike=aes256-sha1 phase2alg=aes256-sha1 left=%defaultroute leftid=184.X.X.X leftsourceip=184.X.X.X leftsubnet=184.X.X.X/32 right=64.Y.Y.Y rightid=64.Y.Y.Y rightsubnet=128.B.B.B/32 retransmit-timeout=40 retransmit-interval=2000 ```
While the output for `ipsec whack status` shows that will try again in 2 seconds, it still tries to reconnect multiple times per second. ``` app1[~]$ sudo ipsec whack --status | grep customer 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 000 "customer": oriented; my_ip=184.X.X.X; their_ip=unset 000 "customer": xauth us:none, xauth them:none, my_username=[any]; their_username=[any] 000 "customer": our auth:secret, their auth:secret 000 "customer": modecfg info: us:none, them:none, modecfg policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset, cat:unset; 000 "customer": labeled_ipsec:no; 000 "customer": policy_label:unset; 000 "customer": ike_life: 3600s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; 000 "customer": retransmit-interval: 2000ms; retransmit-timeout: 40s; 000 "customer": sha2-truncbug:no; initial-contact:no; cisco-unity:no; fake-strongswan:no; send-vendorid:no; send-no-esp-tfc:no; 000 "customer": policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO; 000 "customer": conn_prio: 32,32; interface: ens3; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none; 000 "customer": nflog-group: unset; mark: unset; vti-iface:unset; vti-routing:no; vti-shared:no; 000 "customer": dpd: action:restart; delay:40; timeout:120; nat-t: encaps:auto; nat_keepalive:yes; ikev1_natt:both 000 "customer": newest ISAKMP SA: #0; newest IPsec SA: #0; 000 "customer": IKE algorithms wanted: AES_CBC(7)_256-SHA1(2)-MODP2048(14), AES_CBC(7)_256-SHA1(2)-MODP1536(5) 000 "customer": IKE algorithms found: AES_CBC(7)_256-SHA1(2)-MODP2048(14), AES_CBC(7)_256-SHA1(2)-MODP1536(5) 000 "customer": ESP algorithms wanted: AES(12)_256-SHA1(2) 000 "customer": ESP algorithms loaded: AES(12)_256-SHA1(2) 000 #155: "customer":4500 STATE_MAIN_I3 (sent MI3, expecting MR3); EVENT_v1_RETRANSMIT in 2s; nodpd; idle; import:admin initiate 155: pending Phase 2 for "customer" replacing #0 ``` It's not stopping after 40 seconds, not after 60 seconds, it just goes on. Notice it says `EVENT_v1_RETRANSMIT in 2s`, it doesnt increment on subsequent checks. 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: https://goo.gl/Dbn9f8 Notice it goes from #1 to #1585 in 64 seconds, and it's not gonna stop unless I stop ipsec. I tried to change `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. I tried to add `keyingtries=2`, it doesnt change the behaviour, it goes on forever. 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. On Sun, Jun 18, 2017 at 6:02 PM, Paul Wouters <p...@nohats.ca> wrote: > On Fri, 16 Jun 2017, Bob Cribbs wrote: > > 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. >> >> 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. >> > > This change of behaviour should only happen when you have auto=start > Previously, when the remote send a DELETE, we would end up in auto=add > state, waiting on them to initiate. Now, since the conn is configured > with auto=start, we try again. > > 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 >> 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 >> initiate >> > > So I guess the IKE SA comes up, but there is an IPsec SA configuration > mismatch? > > 000 "customer": retransmit-interval: 500ms; retransmit-timeout: 60s; >> > > 000 #51: "customer":500 STATE_MAIN_I1 (sent MI1, expecting MR1); >> EVENT_v1_RETRANSMIT in 0s; nodpd; idle; import:admin initiate >> > > Although this shows there is no existinng IKE SA here. > > Notice both of them have `EVENT_v1_RETRANSMIT in 0s`, sometimes it's at -1 >> too. >> > > The initial timer is 500ms, then it doubles (1s, 2s, 4s until it hits > the timeout of 60s) > > 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 >> in GB of space in a day and the customer is not happy with the firewall >> trouble. >> > > So in your case, you could use auto=add, which means "load but not > initiate" or you can use auto=ondemand (same, but also try initiate > when there is outgoing traffic matching the tunnel) > > I have other tunnels that are failing too, but their retransmit interval >> is incremental. >> > > That's what I would expect, yes. > > Is there a config Im missing to increase the time between retransmits in >> this scenario? >> And what can I do to make it incremental? >> > > There is retransmit-timeout= and retransmit-interval=. And also > keyingtries=. But I think auto=add would be best for you for now, > until the misconfiguration is resolved. > > Paul >
_______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan