[strongSwan] tunnel not negotiated after keylife expiration

[Noel Kuntze]

Hi,



On 04.09.2017 14:51, Marco Berizzi wrote:
> conn servizitalia
>         left=205.223.229.254
>         right=156.54.166.66
>         leftsubnet=10.28.130.32/27
>         rightsubnet=192.168.42.0/24
>         authby=secret
>         auto=start
>         esp=aes256-sha1
>         compress=no
>         leftid=205.223.229.254
>         rightid=156.54.166.66
>         keyingtries=%forever
>         keylife=1h
>         ikelifetime=8h
>         ike=aes256-md5-modp1024

Avoid modp1024[1] and md5, they're broken, use aesxcbc, sha384 or sha512 instead as hmac and PRF function, use something stronger for the DH exchange, even if it's modp1536.
Avoid sha256, because there's ambiguity between peers about what algorithm is actually used (draft with 96 bit truncation or the standardized version with 128 bit truncation. You can
switch between them since 5.6.0 with a special keyword in the configuration).

Use auto=route[2] instead of auto=start.

The only commonality strongSwan and openswan have is the "swan" at the end, the configuration *format* and that they both implement IKEv1 and IKEv2 (to varying degrees however).
You can mostly NOT apply your knowledge about openswan to strongSwan.

> I'm now experimenting this behaviour on every tunnel configured on this
> strongSwan server.
> When I run 'ipsec start', strongSwan will start all the configured tunnels,
> but after sometime (close to the keylife parameter) the CHILD_SA is deleted
> and it is not negotiated anymore.
>
> strongSwan ipsec start:
> Sep  1 09:36:50 falcon charon: 12[IKE] initiating Main Mode IKE_SA servizitalia[14] to 156.54.166.66
> Sep  1 09:36:50 falcon charon: 10[IKE] IKE_SA servizitalia[14] established between 205.223.229.254[205.223.229.254]...156.54.166.66[156.54.166.66]
> Sep  1 09:36:50 falcon charon: 06[IKE] CHILD_SA servizitalia{14} established with SPIs with SPIs c1478566_i ca7492c1_o and TS 10.28.130.32/27 === 192.168.42.0/24
>
> after about 30 minutes:
> Sep  1 10:07:17 falcon charon: 06[NET] received packet: from 156.54.166.66[500] to 205.223.229.254[500] (76 bytes) 
> Sep  1 10:07:17 falcon charon: 06[ENC] parsed INFORMATIONAL_V1 request 1251768816 [ HASH D ] 
> Sep  1 10:07:17 falcon charon: 06[IKE] received DELETE for ESP CHILD_SA with SPI ca7492c1 
> Sep  1 10:07:17 falcon charon: 06[IKE] closing CHILD_SA servizitalia{14} with SPIs c1478566_i (0 bytes) ca7492c1_o (0 bytes) and TS 10.28.130.32/27 === 192.168.42.0/24 
> Sep  1 10:07:17 falcon charon: 10[NET] received packet: from 156.54.166.66[500] to 205.223.229.254[500] (76 bytes) 
> Sep  1 10:07:17 falcon charon: 10[ENC] parsed INFORMATIONAL_V1 request 3258301735 [ HASH D ] 
> Sep  1 10:07:17 falcon charon: 10[IKE] received DELETE for IKE_SA servizitalia[14] 
> Sep  1 10:07:17 falcon charon: 10[IKE] deleting IKE_SA servizitalia[14] between 205.223.229.254[205.223.229.254]...156.54.166.66[156.54.166.66] 

The problem is caused by the other peer deleting the newly keyed CHILD_SA. You need to review the logs there to find out why it does that.

> at this point, it is not possible anymore to reach the 192.168.42.0/24
> network.
>
> Is this the expected behavior?
> For now, I have bypassed the problem changing the "auto=start" with
> "auto=route" on every connection definition (but packets are lost
> while the ipsec sa is negotiated).
It is. With auto=start, charon does not try to keep the CHILD_SA up, as openswan does. That
is a deliberate decision by the devs. Discussions about it can be found either on the users ML archive or in the issue tracker.

Kind regards

Noel

[1] https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations#LogJam (section titled "LogJam")
[2] https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations#Tunnel-Shunting (section titled "Tunnel Shunting")

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170904/60309be0/attachment.sig>