IKEv2 disconnects after one hour

[hwdsl2]

Reference: hwdsl2/setup-ipsec-vpn#913 (comment)
Similar issue: #362
Libreswan version: 4.1

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.

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.

Libreswan logs around the time of disconnect are below. The macOS client disconnected around 07:17:39, the Windows client disconnected around 07:18:18, and the iOS client disconnected around 07:22:25.

Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X: local ESP/AH proposals (CREATE_CHILD_SA responder matching remote ESP/AH proposals): 
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X:   1:ESP=AES_GCM_C_128+AES_GCM_C_256-NONE-NONE-DISABLED
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X:   2:ESP=AES_CBC_128-HMAC_SHA1_96-NONE-DISABLED
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X:   3:ESP=AES_CBC_256-HMAC_SHA1_96-NONE-DISABLED
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X:   4:ESP=AES_CBC_128-HMAC_SHA2_256_128-NONE-DISABLED
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X:   5:ESP=AES_CBC_256-HMAC_SHA2_256_128-NONE-DISABLED
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #7: proposal 1:ESP=AES_CBC_256-HMAC_SHA1_96-DISABLED SPI=XXXXXXX chosen from remote proposals 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;ESN=DISABLED[first-match] 2:ESP:ENCR=3DES;INTEG=HMAC_SHA1_96;ESN=DISABLED
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #7: negotiated new IPsec SA [0.0.0.0-255.255.255.255:0-65535 0] -> [192.168.43.11-192.168.43.11:0-65535 0]
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #7: negotiated connection [0.0.0.0-255.255.255.255:0-65535 0] -> [192.168.43.11-192.168.43.11:0-65535 0]
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #7: IPsec SA established tunnel mode {ESPinUDP=>0xXXXXXXX <0xXXXXXXX xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA=none NATD=X.X.X.X:1043 DPD=active}
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #3: received Delete SA payload: expire IPsec State #4 now
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #3: established IKE SA
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #4: deleting state (STATE_V2_ESTABLISHED_CHILD_SA) aged 3526.751672s and NOT sending notification
Jan 20 07:17:05 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #4: ESP traffic information: in=9MB out=23MB
Jan 20 07:17:39 localhost pluto[XXX]: "ikev2-cp"[2] X.X.X.X #1: IKE SA expired (--dontrekey)
Jan 20 07:17:39 localhost pluto[XXX]: "ikev2-cp"[2] X.X.X.X #2: deleting other state #2 (STATE_V2_ESTABLISHED_CHILD_SA) aged 3600.002924s and NOT sending notification
Jan 20 07:17:39 localhost pluto[XXX]: "ikev2-cp"[2] X.X.X.X #2: ESP traffic information: in=784KB out=1MB
Jan 20 07:17:39 localhost pluto[XXX]: "ikev2-cp"[2] X.X.X.X #1: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 3600.321609s and sending notification
Jan 20 07:17:39 localhost pluto[XXX]: "ikev2-cp"[2] X.X.X.X: deleting connection instance with peer X.X.X.X {isakmp=#0/ipsec=#0}
Jan 20 07:17:39 localhost pluto[XXX]: packet from X.X.X.X:4500: INFORMATIONAL message response has no corresponding IKE SA
Jan 20 07:17:56 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #5: releasing whack
Jan 20 07:18:18 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #3: IKE SA expired (--dontrekey)
Jan 20 07:18:18 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #7: deleting other state #7 (STATE_V2_ESTABLISHED_CHILD_SA) aged 73.28672s and NOT sending notification
Jan 20 07:18:18 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #7: ESP traffic information: in=18KB out=16KB
Jan 20 07:18:18 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X #3: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 3600.369572s and sending notification
Jan 20 07:18:18 localhost pluto[XXX]: "ikev2-cp"[3] X.X.X.X: deleting connection instance with peer X.X.X.X {isakmp=#0/ipsec=#0}
Jan 20 07:18:19 localhost pluto[XXX]: packet from X.X.X.X:1043: INFORMATIONAL message response has no corresponding IKE SA
Jan 20 07:18:56 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #5: releasing whack
Jan 20 07:19:56 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #5: releasing whack
Jan 20 07:20:56 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #5: releasing whack
Jan 20 07:21:56 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #5: releasing whack
Jan 20 07:22:25 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #5: IKE SA expired (--dontrekey)
Jan 20 07:22:25 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #6: deleting other state #6 (STATE_V2_ESTABLISHED_CHILD_SA) aged 3600.011536s and NOT sending notification
Jan 20 07:22:25 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #6: ESP traffic information: in=283KB out=23MB
Jan 20 07:22:25 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X #5: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 3600.214901s and sending notification
Jan 20 07:22:25 localhost pluto[XXX]: "ikev2-cp"[4] X.X.X.X: deleting connection instance with peer X.X.X.X {isakmp=#0/ipsec=#0}
Jan 20 07:22:25 localhost pluto[XXX]: packet from X.X.X.X:1044: INFORMATIONAL message response has no corresponding IKE SA

Here's the IKEv2 configuration:

conn ikev2-cp
  left=%defaultroute
  leftcert=test.example.com
  leftid=@test.example.com
  leftsendcert=always
  leftsubnet=0.0.0.0/0
  leftrsasigkey=%cert
  right=%any
  rightid=%fromcert
  rightaddresspool=192.168.43.10-192.168.43.250
  rightca=%same
  rightrsasigkey=%cert
  narrowing=yes
  dpddelay=30
  dpdtimeout=120
  dpdaction=clear
  auto=add
  ikev2=insist
  rekey=no
  pfs=no
  fragmentation=yes
  ike=aes256-sha2,aes128-sha2,aes256-sha1,aes128-sha1,aes256-sha2;modp1024,aes128-sha1;modp1024
  phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2
  modecfgdns="8.8.8.8 8.8.4.4"
  encapsulation=yes
  mobike=no

[1] https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2
[2] https://wiki.strongswan.org/issues/3400

[letoams]

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

[hwdsl2]

Thanks for the answers @letoams! I understand it better now. Consistent with what you said above, I did observed in my tests that IKEv1 tunnels can stay up until salifetime, and seem not affected by the ikelifetime.