[IKEv2] Deleting connection instance with peer after 1 hour #913

qwrty-ftw · 2021-01-19T18:51:16Z

Hello,

I'm running libreswan 4.1 on Debian Buster (updated) with 4.9 kernel , everything works great, but I have one user who is connected with Windows 10 (updated) and after 1 hour he is disconnected.
He is my only one user so I can't test with other client.

Last log before disconnection:

Jan 19 19:22:50  pluto[23531]: "ikev2-cp"[5]  #1022: proposal 1:ESP=AES_CBC_256-HMAC_SHA1_96-DISABLED SPI=018edf78 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 19 19:22:50  pluto[23531]: "ikev2-cp"[5]  #1022: 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 19 19:22:50  pluto[23531]: "ikev2-cp"[5]  #1022: 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 19 19:22:50  pluto[23531]: "ikev2-cp"[5]  #1022: IPsec SA established tunnel mode {ESPinUDP=>0x018edf78 <0x642ac48b xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA=none NATD=:4500 DPD=active}
Jan 19 19:22:50  pluto[23531]: "ikev2-cp"[5]  #21: received Delete SA payload: expire IPsec State #1021 now
Jan 19 19:22:50  pluto[23531]: "ikev2-cp"[5]  #21: established IKE SA
Jan 19 19:22:50  pluto[23531]: "ikev2-cp"[5]  #1021: deleting state (STATE_V2_ESTABLISHED_CHILD_SA) aged 3.457043s and NOT sending notification
Jan 19 19:22:50 pluto[23531]: "ikev2-cp"[5]  #1021: ESP traffic information: in=1MB out=120MB
Jan 19 19:22:52  pluto[23531]: "ikev2-cp"[5]  #21: IKE SA expired (--dontrekey)
Jan 19 19:22:52  pluto[23531]: "ikev2-cp"[5]  #1022: deleting other state #1022 (STATE_V2_ESTABLISHED_CHILD_SA) aged 1.849041s and NOT sending notification
Jan 19 19:22:52  pluto[23531]: "ikev2-cp"[5]  #1022: ESP traffic information: in=973KB out=65MB
Jan 19 19:22:52 pluto[23531]: "ikev2-cp"[5]  #21: deleting state (STATE_V2_ESTABLISHED_IKE_SA) aged 3600.094224s and sending notification
Jan 19 19:22:52  pluto[23531]: "ikev2-cp"[5] : deleting connection instance with peer {isakmp=#0/ipsec=#0}

IKEv2 conf:

conn ikev2-cp
  left=%defaultroute
  leftcert=domain.tld
  leftid=@domain.tld
  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,aes256-sha2_512,aes128-sha2,aes256-sha2
  modecfgdns="xxxxxxxxxxx"
  encapsulation=yes
  mobike=no

Is this normal behavior?
Any ideas ?

Thank you very much.

The text was updated successfully, but these errors were encountered:

letoams · 2021-01-19T18:53:54Z

On Tue, 19 Jan 2021, ochbob wrote: Subject: [hwdsl2/setup-ipsec-vpn] [IKEv2] Deleting connection instance with peer after 1 hour (#913) Jan 19 19:22:50 pluto[23531]: "ikev2-cp"[5] #1022: IPsec SA established tunnel mode {ESPinUDP=>0x018edf78 <0x642ac48b xfrm=AES_CBC_256-HMAC_SHA1_96 NATOA =none NATD=:4500 DPD=active} Jan 19 19:22:50 pluto[23531]: "ikev2-cp"[5] #21: received Delete SA payload: expire IPsec State #1021 now is this normal behavior?

Yes. Windows has decided there is no more reason to keep the tunnel up, and brings it down. Nothing libreswan can do.

qwrty-ftw · 2021-01-19T18:55:52Z

Thank you.

But there is trafic on VPN when Windows brings it down...

Any workaround ? Maybe a specific settings ?

letoams · 2021-01-19T18:58:15Z

On Tue, 19 Jan 2021, ochbob wrote: But there is trafic on VPN when Windows brings it down... Any workaround ? Maybe a specific settings ?

that would be a windows bug then :/ lifetimes are not negotiated, so it's all up to windows. Paul

qwrty-ftw · 2021-01-19T18:59:52Z

:(

I will search on Windows side then, thank you for fast answer anyway :D

hwdsl2 · 2021-01-20T00:04:05Z

Thanks for the answers @letoams!
@ochbob This does look like an issue on the Windows client side. However, if you see any logs indicating possible re-key problems, you can try setting a longer ikelifetime (default 1h, max 24h) [1] and/or add ms-dh-fallback=yes [2] in ikev2.conf.

[1] https://libreswan.org/man/ipsec.conf.5.html
[2] https://libreswan.org/wiki/FAQ#Microsoft_Windows_connection_attempts_fail_with_NO_POROPOSAL_CHOSEN

- Fix an issue with IKEv2 disconnecting after one hour due to IKE SA expiration, by setting ikelifetime and salifetime to 24h. Ref: #913 #844 https://libreswan.org/man/ipsec.conf.5.html

hwdsl2 · 2021-01-20T15:05:48Z

Tested and confirmed that this issue (IKEv2 disconnect after one hour) is fixed with 7d9f2c6.
To fix on your server, please append the following lines to /etc/ipsec.d/ikev2.conf, indented by two spaces, then run sudo service ipsec restart.

  ikelifetime=24h
  salifetime=24h

Question for @letoams: 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.

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

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

qwrty-ftw · 2021-01-21T15:28:08Z

I have found a workaround with this tool which work really great (Auto-reconnect) : http://vpnlifeguard.blogspot.com/p/english.html

Will definitevely uprgade my server conf, but I do not have this configuration file ?
Should I created it ? @hwdsl2

Edit: OK nevermind, I changed it in my configuration file => /etc/ipsec.conf

Thank you !

letoams · 2021-01-22T04:20:05Z

On Wed, 20 Jan 2021, Lin Song wrote: Tested and confirmed that this issue (IKEv2 disconnect after one hour) is fixed with 7d9f2c6. To fix on your server, please append the following lines to /etc/ipsec.d/ikev2.conf, indented by two spaces, then run sudo service ipsec restart. ikelifetime=24h salifetime=24h Question for @letoams: 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.

See my answer to the other bug report #405 With libreswan 4.1 you _can_ also use rekey=yes on the server side. But some clients don't like the server rekeying instead of them rekeying, so your fix to set lifetimes to 24h is the best fix. Paul

With IKEv1, the IKE SA could expire while retaining the IPsec SA. Which meant an IKE SA of 1h would not affect an IPsec SA of 8h. With IKEv2, if the IKE SA expires, it takes down all IPsec SA's as well. As a result, the same default for ikelifetime= causes very different behaviour between IKEv1 and IKEv2 when rekey=no is set. While it is possible with libreswan 4.x to set rekey=yes on the server side, to ensure the connection stays up, often clients (eg Windows) do not like it when the server initiates a rekey to them. This was reported at various places. Some examples: Resolves: #405 Resolves: hwdsl2/setup-ipsec-vpn#913 Resolves: #362

- Fix an issue with IKEv2 disconnecting after one hour due to IKE SA expiration, by setting ikelifetime and salifetime to 24h. Ref: hwdsl2#913 hwdsl2#844 https://libreswan.org/man/ipsec.conf.5.html

hwdsl2 closed this as completed Jan 20, 2021

hwdsl2 added a commit that referenced this issue Jan 20, 2021

Fix IKEv2

7d9f2c6

- Fix an issue with IKEv2 disconnecting after one hour due to IKE SA expiration, by setting ikelifetime and salifetime to 24h. Ref: #913 #844 https://libreswan.org/man/ipsec.conf.5.html

hwdsl2 mentioned this issue Jan 20, 2021

IKEv2 disconnects after one hour libreswan/libreswan#405

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[IKEv2] Deleting connection instance with peer after 1 hour #913

[IKEv2] Deleting connection instance with peer after 1 hour #913

qwrty-ftw commented Jan 19, 2021 •

edited

letoams commented Jan 19, 2021 via email

qwrty-ftw commented Jan 19, 2021 •

edited

letoams commented Jan 19, 2021 via email

qwrty-ftw commented Jan 19, 2021

hwdsl2 commented Jan 20, 2021

hwdsl2 commented Jan 20, 2021

qwrty-ftw commented Jan 21, 2021 •

edited

letoams commented Jan 22, 2021 via email

[IKEv2] Deleting connection instance with peer after 1 hour #913

[IKEv2] Deleting connection instance with peer after 1 hour #913

Comments

qwrty-ftw commented Jan 19, 2021 • edited

letoams commented Jan 19, 2021 via email

qwrty-ftw commented Jan 19, 2021 • edited

letoams commented Jan 19, 2021 via email

qwrty-ftw commented Jan 19, 2021

hwdsl2 commented Jan 20, 2021

hwdsl2 commented Jan 20, 2021

qwrty-ftw commented Jan 21, 2021 • edited

letoams commented Jan 22, 2021 via email

qwrty-ftw commented Jan 19, 2021 •

edited

qwrty-ftw commented Jan 19, 2021 •

edited

qwrty-ftw commented Jan 21, 2021 •

edited