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

Rajiv Kulkarni rajivkulkarni69 at gmail.com
Mon Jan 17 12:33:58 CET 2022


Hi

Looks like the windows-native clients are behind nat-routers. And also
somewhere its documented (in strongswan-wiki) windows-ikev2-clients
especially behind nat-routers (meaning tunnel with NAT-T) do not respond or
misbehave when the vpn-server initiates a rekey

Ofcourse as you have already mentioned, the windows-ikeve clients have
their fixed lifetime of 8hrs, etc at which they initiate the rekeys

Now to avoid the problems associated with rekeying by windows-ikev2
clients, i am generally configuring the strongswan-vpn-server as below:


For Split-Tunnel:
---------------------
conn WindowsAndroidClients_wEAP
        left=<your-public-internet-ipaddr-here>
        right=%any
        leftsubnet=
192.168.1.0/24,192.168.2.0/24,192.168.3.0/24,192.168.50.0/24
        rightsourceip=10.181.12.101-10.181.12.120
        ikelifetime=28800s
        lifetime=3600s
        rekey=no
        reauth=no
        dpddelay=40
        dpdtimeout=120
        dpdaction=clear
        modeconfig=pull
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        keyexchange=ikev2
        leftauth=pubkey
        rightauth=eap-radius
        eap_identity=%any
        leftsendcert=always
        rightsendcert=never
        leftid=vpnserver.dyndns.org
        rightid=%any
        leftcert=/etc/ssl/certs/vpnserverCert.pem
        auto=add

Or for FULL-Tunnel
-------------------

conn WindowsAndroidClients_wEAP
        left=<your-public-internet-ipaddr-here>
        right=%any
        leftsubnet=0.0.0.0/0
        rightsourceip=10.181.12.101-10.181.12.120
        ikelifetime=86400s
        lifetime=43200s
        rekey=no
        reauth=no
        dpddelay=40
        dpdtimeout=120
        dpdaction=clear
        modeconfig=pull
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        keyexchange=ikev2
        leftauth=pubkey
        rightauth=eap-radius
        eap_identity=%any
        leftsendcert=always
        rightsendcert=never
        leftid=vpnserver.dyndns.org
        rightid=%any
        leftcert=/etc/ssl/certs/vpnserverCert.pem
        auto=add

-------------------------------------------------------

The key points to note in the config above is:
1. The IKE-SA and Child-SA lifetimes on the VPN-Server only is set to High

2. And to avoid the server from initiating the rekeying  altogether, iam
using the option "rekey=no". This does not prevent the server from
responding to rekey-requests from the remote-clients and goes thru the
rekeying process without any issues (when initiated from the clients
themselves...who are generally behind nat-routers invariably)

3. And lastly to avoid proposal-mismatches, iam setting the algorithms on
the vpn-server as given above, and will accept ONLY these proposal for
IKEv2 and ESP


Try the above, and hopefully it should solve your issue. Also try to visit
the strongswan-wiki site and read thru the info on
issues/caveats/config-info for Windows-Native-IKEv2 clients with
Strongswan-server, There are a number of points that are important to know.
There is one section for MacOS/iOS-IKEv2 clients too...

hope this helps

thanks & regards
Rajiv







On Sat, Jan 15, 2022 at 1:37 AM 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> 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
>>
>>       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"
>>
>>       right=%any
>>
>>       rightdns=192.168.0.1,192.168.0.2,192.168.111.254
>>
>>       rightsourceip=172.26.232.0/24
>>
>>       rightgroups=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]..
>>
>> .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]
>>
>> 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]
>>
>> 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/20220117/fc7d7e11/attachment.html>


More information about the Users mailing list