[Swan-dev] [libreswan/libreswan] IKEv2 disconnects after one hour (#405)

[Paul Wouters]

On Wed, 20 Jan 2021, Lin Song wrote:

[ CC:ing swan-dev ]

> I tested with iOS, macOS and Windows clients, and found that when the server has setting rekey=no, Libreswan disconnects
> the IKEv2 VPN connection after about 60 minutes, which is the default ikelifetime. The client will then show "Not
> connected". Is this behavior normal? It looks like rekey=no is the suggested setting [1], and setting rekey=yes might not
> work as intended if the client is behind NAT [2]. The disconnect issue is fixed after I set ikelifetime and salifetime to
> 24h on the server.

With recent versions of libreswan you can have rekey=yes on the server.
This would resolve your issue. But I recommend setting the ikelifetime=
to at least 8h so let (most?) clients initiate the rekey before the
server expires the connection.

It is still a good idea to let the client do the rekeying.  And with
setting the IKE and IPsec lifetimes to 24h, you basically end up not
rekeying before the client, and so the client will rekey for you.

With IKEv1, the IKE SA could not rekey and vanish while keeping the
IPsec SA up, so with default values of ikelifetime=1h and salifetime=8h,
the VPN tunnel would stay up for 8h. But I guess now with IKEv2,
which does not allow orphaned IPsec SA's, it means with rekey=no
that the tunnel goes down at ikelifetime= of 1h. That is indeed
not the best solution. I will look at changing the default value.

> You can reproduce this issue using any of iOS, macOS and/or Windows VPN client and IKEv2. This might be a bug in
> Libreswan. On the other hand, IKEv1 L2TP and XAuth connections both tested OK, the client would request to re-connect when
> the IPsec SA expires.

See above for why with IKEv1, you would end up with an 8h lifetime,
and presumably your clients rekey before the 8h timer is up. With
IKEv2, this accidentally became 1h.

Paul