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,

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,

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).