VPN timeout/key negotion after 8 hours

Hey Jacob Jensen1 

I'll attach a screenshot below, but have you tried changing the key lifetime configured in your SSL VPN settings?

Best,

Hi FloSupport,

I have not tried that. could i double that without it causing other issues? 57600? an even higher number?

Regards

Jacob

Hey Jacob Jensen1 

Apologies for the delay in response!

You could configure this with a higher number, but please keep in mind this will decrease your level of network security. For reference from our XG admin guide (p.236-237), "Key generation and key rotation are important because the longer the life of the key, the larger the amount of data at risk, and the easier it becomes to intercept more ciphered text for analysis."

I would also advise looking online for more information to help you make an informed decision about choosing the key lifetime for your network.

Best,

OK thank you.

Before switching to XG we were using an openvpn appliance (https://openvpn.net/) Back then we never had this problem. Should the XG not be able to renegotiate the keys without disconnecting the client even though we are working with 2 factor authentication?

Im trying to figure out if this is a bug in XG or why this was not happening on the old openvpn appliance?

Regards

Jacob

Hey Jacob Jensen1 

The client shouldn't be disconnected as a result of the key renegotiation process. Are you able to perform a test to verify by decreasing your Key Lifetime to a shorter duration (60 seconds) and confirming the result?

This issue could be caused by the 2 factor authentication when rekeying is performed.

Please keep me updated.

Best,

Hi Flo,

I already have a log of the failing attempt. As you can see the VPN is initialized at 08:02:18 and keys renegotiated at around 16:00.

Wed Apr 18 08:02:18 2018 /sbin/ip link set dev tun0 up mtu 1500 Wed Apr 18 08:02:18 2018 /sbin/ip addr add dev tun0 192.168.200.7/24 broadcast 192.168.200.255 Wed Apr 18 08:02:22 2018 /sbin/ip route add xx.xx.xx.xx/32 via 192.168.24.1 Wed Apr 18 08:02:22 2018 /sbin/ip route add 192.168.100.0/24 via
192.168.200.5
Wed Apr 18 08:02:22 2018 /sbin/ip route add 192.168.101.0/24 via
192.168.200.5
Wed Apr 18 08:02:22 2018 /sbin/ip route add xx.xx.xx.xx/32 via
192.168.200.5
Wed Apr 18 08:02:22 2018 /sbin/ip route add xx.xx.xx.xx/32 via
192.168.200.5
Wed Apr 18 08:02:22 2018 /sbin/ip route add xx.xx.xx.xx/32 via
192.168.200.5
Wed Apr 18 08:02:22 2018 Initialization Sequence Completed Wed Apr 18 16:02:11 2018 VERIFY OK: depth=1, C=xx, ST=xxxxxxxx, L=xxxxxxx, O=xxxxxxxxxxxxx, OU=IT, CN=Sophos_CA_C0100xxxxxxxHE5, emailAddress=xxxxxxxxxx Wed Apr 18 16:02:11 2018 VERIFY X509NAME OK: C=DK, ST=xxxxxx, L=xxxxxx, O=xxxxxxx A, CN=SophosApplianceCertificate_C0100xxxxxxHE5, emailAddress=xxxxxxxxxx Wed Apr 18 16:02:11 2018 VERIFY OK: depth=0, C=DK, ST=xxxxxxx, L=xxxxx, O=xxxxxxx, CN=SophosApplianceCertificate_C01001xxxxHHE5, emailAddress=xxxxxxxx Wed Apr 18 16:02:12 2018 Data Channel Encrypt: Cipher 'AES-128-CBC'
initialized with 128 bit key
Wed Apr 18 16:02:12 2018 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Apr 18 16:02:12 2018 Data Channel Decrypt: Cipher 'AES-128-CBC'
initialized with 128 bit key
Wed Apr 18 16:02:12 2018 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Apr 18 16:02:12 2018 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Wed Apr 18 16:09:09 2018 Connection reset, restarting [0] Wed Apr 18 16:09:09 2018 SIGUSR1[soft,connection-reset] received, process restarting Wed Apr 18 16:09:09 2018 Restart pause, 5 second(s) Wed Apr 18 16:09:14 2018 Socket Buffers: R=[87380->87380] S=[16384->16384] Wed Apr 18 16:09:14 2018 Attempting to establish TCP connection with
[AF_INET]xx.xx.xx.xx:8443 [nonblock]
Wed Apr 18 16:09:15 2018 TCP connection established with
[AF_INET]xx.xx.xx.xx:8443
Wed Apr 18 16:09:15 2018 TCPv4_CLIENT link local: [undef] Wed Apr 18 16:09:15 2018 TCPv4_CLIENT link remote: [AF_INET]xx.xx.xx.xx:8443 Wed Apr 18 16:09:15 2018 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:8443, sid=da45xxx 4ca57334 Wed Apr 18 16:09:15 2018 VERIFY OK: depth=1, C=DK, ST=xxxxxxxxx, L=xxxxxxx, O=xxxxxxxxx, OU=IT, CN=Sophos_CA_C010xxxxDFHHHE5, emailAddress=xxxxxxx Wed Apr 18 16:09:15 2018 VERIFY X509NAME OK: C=DK, ST=xxxxxx, L=xxxxxx, O=xxxxxxxx, CN=SophosApplianceCertificate_C0xxxxxxFHHHE5, emailAddress=xxxxxxxxxx Wed Apr 18 16:09:15 2018 VERIFY OK: depth=0, C=DK, ST=xxxxxx, L=xxxxxx, O=xxxxxxx, CN=SophosApplianceCertificate_C010017QDFHHHE5, emailAddress=xxxxxxx Wed Apr 18 16:09:16 2018 Data Channel Encrypt: Cipher 'AES-128-CBC'
initialized with 128 bit key
Wed Apr 18 16:09:16 2018 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Apr 18 16:09:16 2018 Data Channel Decrypt: Cipher 'AES-128-CBC'
initialized with 128 bit key
Wed Apr 18 16:09:16 2018 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Wed Apr 18 16:09:16 2018 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Wed Apr 18 16:09:16 2018 [SophosApplianceCertificate_C0100xxxxxxxHHE5]
Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:8443 Wed Apr 18 16:09:18 2018 SENT CONTROL
[SophosApplianceCertificate_C010xxxxxFHHHE5]: 'PUSH_REQUEST' (status=1) Wed Apr 18 16:09:18 2018 AUTH: Received control message: AUTH_FAILED Wed Apr 18 16:09:18 2018 /sbin/ip route del xx.xx.xx.xx/32 Wed Apr 18 16:09:18 2018 /sbin/ip route del xx.xx.xx.xx/32 Wed Apr 18 16:09:18 2018 /sbin/ip route del xx.xx.xx.xx/32 Wed Apr 18 16:09:18 2018 /sbin/ip route del 192.168.101.0/24 Wed Apr 18 16:09:18 2018 /sbin/ip route del 192.168.100.0/24 Wed Apr 18 16:09:18 2018 /sbin/ip route del xx.xx.xx.xx/32 Wed Apr 18 16:09:18 2018 Closing TUN/TAP interface Wed Apr 18 16:09:18 2018 /sbin/ip addr del dev tun0 192.168.200.7/24 Wed Apr 18 16:09:18 2018 SIGTERM[soft,auth-failure] received, process exiting

It does say AUTH_FAILED and that would make says if it tries to reuse the password from 08:00 because that ofcourse has changed due to the use of 2 factor auth. This was however not an issue with the old solution based on openvpn ALSO using 2 factor auth.

Regards

Jacob

Could you please verify if you experience the same issue when you decrease the Key Lifetime to 60 seconds?

Also what method of 2 factor authentication are you using?

Thanks,

Could you please verify if you experience the same issue when you decrease the Key Lifetime to 60 seconds?

Also what method of 2 factor authentication are you using?

Thanks,

Hello, i have more or less the same problem. Key lifetime is 8 hours and with 2factor auth the connection goes down after 8 hours.

I would not like to change much in that session cause i am not sure about the effect ? The setting of key lifetime is firewall side only or

do i have to send the users a new certificate after that change ?  Or can i change it also to 9 hours without any outage of the users 

connection ? 

BR

Marco

Hi marco_47d 

See what I mentioned above regarding the risks of increasing the key lifetime. Generally, changing the settings on that SSL VPN configuration window will require users to re-download their SSL VPN configuration from the user portal.

Regards,

Thank you very much. I will tell the  user to reconnect after lunchbreak. Its not a good idea to tell the user to download a new certificate 

there will be to much problems in that process. I am happy to have 150 user working with vpn and not want to run in problems. 

BR

Marco

I've verified that the Key lifetime value is a timeout option pushed to the client during client/server negotiations. Clients will not need to re-download their VPN profile if the Key lifetime value is change. However, applying this change does disconnect connected VPN clients and may require them to authenticate if OTP is enabled.

Hey, 

Sorry that I dig out this old question, but I've the same problem with our users.

I changed key lifetime to 10 hours and also downloaded the ssl config once again, even Jacob reported that it's not necessary. 

But my users still get disconnected after 8 hours. 

Any further Ideas? FloSupport We're actual on 17 MR10

Regards, 

Jonny

Any updates on this?  We are also having users disconnected after the 8 hour mark.  This is causing a lot of confusion and frustration for our remote users (which in today's world is most users).

Hi Jonnie 

With the key lifetime value 10 hours users should not get disconnected after 8 hours, key life time value defines that the keys will expire after configured time and disconnects the user to reset the keys. There are no other settings on the firewall that would cause this disconnects after 8 hours, I think it is possible that user got disconnected for some other reason. 

Could you please provide client logs around the time that user got disconnected? 

Thanks,

Hey H_Patel, 

Thanks for your reply. I've have installed the OpenVPN GUI, because I can't run Sophos SSL VPN Client as a service or? Without the use of a windows service, the log will be lost with the next restart of the Sophos VPN client. 

I will monitor this behaviour and post the log maybe next week after the public holidays.

Worth adding that we've just added 100 users to our Sophos XG using SSL VPN. Users getting disconnected after 8 hours. Changed the key lifetime in VPN settings to give 12 hours. Clients were disconnected and had to reconnect but the sessions now last 12 hours. SSL Client or config, as others say, doesn't need to be downloaded again.

Hey, 

Today I could verify the issue by myself. I've started the VPN at 9:10 am and get "disconnected" at 17:10 pm, exact 8 hours later. 

The curious thing is, that my active RDP Connection has been disconnected but my vpn is still active? 

Checked internet access --> ok , checked my public ip --> From the xg and not from my homeoffice, checked ICMP to recently connected server --> FAIL

I remembered that I have a similar issue months ago, where our ssl vpn users has been kicked off after exactly 15 mins. 

The VPN client still says connected, but no connection to our internal servers. I've discussed this issue several times with the support hotline, but they don't understand the problem, even with a Support Session in the same moment where the disconnect happens. I was angry as hell! 

So I checked all possible "time" fields at the XG and noticed that I have set the "Maximum Session Timeout" at the Global Settings under Services to 15min. My thought was, that this settings only apply to the user portal and not to the ssl vpn itself. But after I set this to 8 hours, the issue was resolved. 

Am I right assuming that the "Maximum Session Timout" could affect the ssl vpn with the otp token? 

Because I already set the Key Lifetime to 10 hours and downloaded the ssl config once again. This is the only settings which make sense to me, after my story as described above. 

I will try it tomorrow once again but I would appreciate a confirmation from the forum support. :)