[Swan] Retransmit interval

[Bob Cribbs]

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 <paul at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170619/d1a50539/attachment-0001.html>