[Swan] Retransmit interval

[Bob Cribbs]

Hello,

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 is what the conn config looks like:
```
conn customer
authby=secret
        dpddelay=40
        dpdtimeout=120
        dpdaction=restart
        auto=start
        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
```

And this is what `ipsec whack --status shows`

```
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: 500ms; retransmit-timeout: 60s;
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: #41; newest IPsec SA: #0;
000 "customer":   IKE algorithms wanted:
AES_CBC(7)_256-SHA1(2)-MODP1024(2), 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)-MODP1024(2), AES_CBC(7)_256-SHA1(2)-MODP2048(14),
AES_CBC(7)_256-SHA1(2)-MODP1536(5)
000 "customer":   IKE algorithm newest: AES_CBC_256-SHA1-MODP1536
000 "customer":   ESP algorithms wanted: AES(12)_256-SHA1(2)
000 "customer":   ESP algorithms loaded: AES(12)_256-SHA1(2)
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


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: 500ms; retransmit-timeout: 60s;
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)-MODP1024(2), 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)-MODP1024(2), 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 #51: "customer":500 STATE_MAIN_I1 (sent MI1, expecting MR1);
EVENT_v1_RETRANSMIT in 0s; nodpd; idle; import:admin initiate
```

Notice both of them have `EVENT_v1_RETRANSMIT in 0s`, sometimes it's at -1
too.

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.

I have other tunnels that are failing too, but their retransmit interval is
incremental.

Is there a config Im missing to increase the time between retransmits in
this scenario?
And what can I do to make it incremental?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170616/1905f465/attachment.html>