[strongSwan] IPSEC IKEv2 disconnecting after ~8 hours - Windows 10 Client

Fri Jan 14 22:00:21 CET 2022

Hello Chris,

Thanks for getting back. I did change ikelifetime to 360m (6 hrs) but i am still having issues. Could that still be the cipher?

These are the logs after modifying ikelifetime so thst the strongswan server initiates the rekey before windows ->

charon: 06[IKE] initiator did not reauthenticate as requested
charon: 06[IKE] IKE_SA VPN_x_xxxx[71277] will timeout in 3 minutes

charon: 14[IKE] deleting IKE_SA VPN_x_xxxx[71277] between yyy.yyy.yyy.yyy[C=XX, ST=xxxx, L=xxxx, O=xxxxxxxxxxxx, OU=xx, CN=xxx.xxx.xxx,E=xx at xx.com<mailto:E=xx at xx.com>]..
.xxx.xxx.xxx.xxx[192.168.0.49]
charon: 14[IKE] sending DELETE for IKE_SA VPN_x_xxxx[71277]
charon: 14[ENC] generating INFORMATIONAL request 27 [ D ]
charon: 14[NET] sending packet: from yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500] (76 bytes)
charon: 04[NET] received packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (76 bytes)
charon: 04[ENC] parsed INFORMATIONAL response 27 [ ]
charon: 04[IKE] IKE_SA deleted
charon: 04[CFG] lease 172.26.232.7 by 'DOMAIN\user1' went offline

On 14 Jan 2022, at 22:07, Chris Sherry <smilinjoe at gmail.com> wrote:

Ed,

I had this issue awhile back. Using the native Windows client to connect Fortigate firewalls. We found that with the default Windows proposal, the client was re-keying with different ciphers than the original. We found two ways around this, change the phase1 keylifetime to 7 hours, or update the proposal sent by the client. I am hunting for that command line to share.

On Fri, Jan 14, 2022 at 8:49 AM Ed Hunter <edhunterr at outlook.com<mailto:edhunterr at outlook.com>> wrote:
Hello everyone,

I’m having trouble with my roadwarrior VPNs. They are Windows 10 devices on the other end, using the native windows VPN client and i have figured out that Windows issues a rekey automatically around the 8th hour mark.That for some reason, is something strongswan does not like and the VPN is dropped so the client needs to reconnect manually.

I don’t have the logs for that but i can get them tomorrow most likely but i think i know what might be wrong here. As i understand, Windows does issue a re-authentication for Phase1 at the 8th hour mark. Maybe my algorithms at my strongswan side do not match what windows is trying with? How could I change that if that is the case?

Now, i tried to issue the rekey from the server side, by lowering ikelifetime to 360m from 1440m. See full config below

conn VPN_x_xxxx
      keyexchange=ikev2
      ike=aes256-sha1-modp1024,aes256-sha256-modp2048!
      esp=aes256-sha1,aes256-sha256-modp2048!
      left=yyy.yyy.yyy.yyy
      leftsubnet=0.0.0.0/0<http://0.0.0.0/0>
      leftauth=pubkey
      leftcert=service-VPN-ldgateway.pem.rsa
      leftid="C=XX, ST=xxxx, L=xxxx, O=xxxxxxxxxxxx, OU=xx, CN=xxx.xxx.xxx, E=xx at xx.com<mailto:E=xx at xx.com>"
      right=%any
      rightdns=192.168.0.1,192.168.0.2,192.168.111.254
      rightsourceip=172.26.232.0/24<http://172.26.232.0/24>
      rightgroups=xxxx at xx.com<mailto:xxxx at xx.com>
      rightauth=eap-radius
      eap_identity=%identity
      auto=add
      ikelifetime=360m
      lifetime=1h
      rekey=yes
      margintime=3m
      keyingtries=5
      rekeyfuzz=100%
      inactivity=2h
      dpddelay=20s
      dpdtimeout=120s
      dpdaction=clear

But this does not work either, i get the following at the 6 hour mark, on reauth attempt ->

charon: 06[IKE] initiator did not reauthenticate as requested
charon: 06[IKE] IKE_SA VPN_x_xxxx[71277] will timeout in 3 minutes

charon: 14[IKE] deleting IKE_SA VPN_x_xxxx[71277] between yyy.yyy.yyy.yyy[C=XX, ST=xxxx, L=xxxx, O=xxxxxxxxxxxx, OU=xx, CN=xxx.xxx.xxx, E=xx at xx.com<mailto:E=xx at xx.com>]..
.xxx.xxx.xxx.xxx[192.168.0.49]
charon: 14[IKE] sending DELETE for IKE_SA VPN_x_xxxx[71277]
charon: 14[ENC] generating INFORMATIONAL request 27 [ D ]
charon: 14[NET] sending packet: from yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500] (76 bytes)
charon: 04[NET] received packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (76 bytes)
charon: 04[ENC] parsed INFORMATIONAL response 27 [ ]
charon: 04[IKE] IKE_SA deleted
charon: 04[CFG] lease 172.26.232.7 by 'DOMAIN\user1' went offline

Now, if i issue ipsec stroke rekey, i think, reauth goes through. What is the difference? See below after manually issuing a stroke rekey ->

charon: 14[CFG] received stroke: rekey 'VPN_x_xxxx[71705]'
charon: 08[IKE] initiating IKE_SA VPN_x_xxxx[71709] to xxx.xxx.xxx.xxx
charon: 08[ENC] generating CREATE_CHILD_SA request 0 [ SA No KE ]
charon: 08[NET] sending packet: from yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500] (348 bytes)
charon: 15[NET] received packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (316 bytes)
charon: 15[ENC] parsed CREATE_CHILD_SA response 0 [ SA KE No ]
charon: 15[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
charon: 15[IKE] scheduling reauthentication in 21275s
charon: 15[IKE] maximum IKE_SA lifetime 21455s
charon: 15[IKE] IKE_SA VPN_x_xxxx[71709] rekeyed between yyy.yyy.yyy.yyy[C=XX, ST=xxxx, L=xxxx, O=xxxxxxxxxxxx, OU=xx, CN=xxx.xxx.xxx, E=xx at xx.com]...xxx.xxx.xxx.xxx[192.168.0.50<mailto:E=xx at xx.com]...xxx.xxx.xxx.xxx[192.168.0.50>]
charon: 15[IKE] rescheduling reauthentication in 15789s after rekeying, lifetime reduced to 15969s
charon: 15[IKE] deleting IKE_SA VPN_x_xxxx[71705] between yyy.yyy.yyy.yyy[C=XX, ST=xxxx, L=xxxx, O=xxxxxxxxxxxx, OU=xx, CN=xxx.xxx.xxx, E=xx at xx.com]...xxx.xxx.xxx.xxx[192.168.0.50<mailto:E=xx at xx.com]...xxx.xxx.xxx.xxx[192.168.0.50>]
charon: 15[IKE] sending DELETE for IKE_SA VPN_x_xxxx[71705]
charon: 15[ENC] generating INFORMATIONAL request 1 [ D ]
charon: 15[NET] sending packet: from yyy.yyy.yyy.yyy[4500] to xxx.xxx.xxx.xxx[4500] (76 bytes)
charon: 13[NET] received packet: from xxx.xxx.xxx.xxx[4500] to yyy.yyy.yyy.yyy[4500] (76 bytes)
charon: 13[ENC] parsed INFORMATIONAL response 1 [ ]
charon: 13[IKE] IKE_SA deleted

Thank you.

Spyro

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220114/8fc0e314/attachment-0001.html>