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

Lets wrap this up.

I would like to ask you guys to test the Sophos Connect Client 2.0 for this.

https://community.sophos.com/products/xg-firewall/sfos-eap/sophos-connect-eap/b/announcements/posts/sophos-connect-2-0-early-access

A rekey in the current state (SSL & IPsec) is a new Session for the authentication session. Therefore it needs another OTP Token.

In IPsec, it is 4 Hours until rekey. In SSLVPN it seems to be 8 hours (Needs to be tested). 

Session limited within the User in XG means, the Access_server allows a maximum of X Sessions concurrent. So Login via SSLVPN, Login via User Portal, Login via IPsec = 3 Sessions at the same time. 

Provide your findings on SSLVPN in SC2.0 in the new EAP Forum. 

I have tested 3 cases as below. 

Scenario 1:

Session timeout: 15

Key lifetime: 10

SSL VPN user disconnected after exactly 10 mins.

Scenario 2:

Session timeout: 5

Key lifetime: 10

SSL VPN user disconnected after exactly 10 mins.

Scenario 3:

Session timeout: Unlimit

Key lifetime: 15

SSL VPN user disconnected after exactly 15 mins.

I think it not related to the session timeout. It depends on the key lifetime. Something went wrong between key lifetime with OTP. 

I Hope Sophos Technical looks into this issue asap.

Thank you.

Session timeout is kinda a tricky part of VPN in gerneral. What it means it, if the Client is idle, it starts counting and disconnect after some time, idle. But to estimate, a client is idle, you need to figure out what a IDLE Client means. 

A Key Lifetime is a fix value: From session establishment to 15 mins. Afterwards rekey the connection. 

In real world, i never recommend using session timeout for ipsec or sslvpn. The quality of life feature for this is not the best. I better work with the Work hour feature of the firewall rules or the user time. 

That is my feedback about this part. 

Hey Lucar,

I have the same issue. How can I set the generell session timeout on Sophos SG 430?

Best regards

SG or XG? 

Key Negation or User Session timeout? 

Hey,

User Session Timeout. SG 430.

Best regards

You should ask this Question in the UTM section.

Thats a nice answer by a staff of sophos...

This thread is 3 Pages with content in different direction. Discuss UTM matters in this thread those not help to have a overview. 

Especially i do not know:

Do you use Sophos Connect or OpenVPN or the Sophos OpenVPN Client? 

Do you use AD, Local AD or Radius as a Backend Authentication?

Do you mean by Session Timeout the Key Lifetime or the User Session by Data with IDLE? 

This questions should be handled by the UTM Section, because the admins there can actually answer all of those questions in a proper manner. I am not having a UTM to interact and verify my answer for UTM. (PS: i could give you a guess, but that is not helpful at all). 

Hi LuCar Toni,

My Product is: XG 310, FW 17.5.MR8

I use Sophos SSL VPN Client. Authentication via AD. SSL VPN users are using the AD account and combine it with OTP to authentication. 

In the VPN global setting, the default value of Key lifetime is 28800 mean 8 hours.

Recently, Users report me that their VPN connection always drops the connection exactly 8 hours later. So I think there is something went wrong between key lifetime and OTP.

Seem this issue only affects when using OTP :) 

Below is my testing after increasing the Key lifetime to 16hrs :), as you can see that the start time and end time exactly 16hrs. Another note, I still keep the "Maximum session timeout" as default. 

Hi LuCar Toni,

My Product is: XG 310, FW 17.5.MR8

I use Sophos SSL VPN Client. Authentication via AD. SSL VPN users are using the AD account and combine it with OTP to authentication. 

In the VPN global setting, the default value of Key lifetime is 28800 mean 8 hours.

Recently, Users report me that their VPN connection always drops the connection exactly 8 hours later. So I think there is something went wrong between key lifetime and OTP.

Seem this issue only affects when using OTP :) 

Below is my testing after increasing the Key lifetime to 16hrs :), as you can see that the start time and end time exactly 16hrs. Another note, I still keep the "Maximum session timeout" as default. 

XG will actually reauth the user after rekey. That is the current design, which is currently under revisit to change. 

IPsec will rekey after 4 hours. (Coded)

SSLVPN will rekey after 8 hours. (Adjustable)

That leads to 1-3 OTP Auths per Day in a common scenario, which is annoying but "maybe ok". 

Assuming you will get the same numbers in Sophos Connect 2.0 ? Could you give this a try? 

https://community.sophos.com/products/xg-firewall/sfos-eap/sophos-connect-eap/b/announcements/posts/sophos-connect-2-0-early-access

LuCar Toni said:

 

That leads to 1-3 OTP Auths per Day in a common scenario, which is annoying but "maybe ok". 

 Assuming you will get the same numbers in Sophos Connect 2.0 ? Could you give this a try? 

https://community.sophos.com/products/xg-firewall/sfos-eap/sophos-connect-eap/b/announcements/posts/sophos-connect-2-0-early-access

 

That is a bad joke, isn't it? You can't explain you colleagues or even your CEO that he have to reauthenticate just a few times a day, because it's hard coded at the firewall? 

In times of corona where everyone is reliant to have a stable internet connection. What about Online Meetings, phone calls, file uploads etc. ? "uhm sorry, I have to reauthenticate my vpn client b'cause sophos can't offer an option to adjust the rekey / auth time.  

Yes we could use Sophos Connect 2.0 but only because its was released a few days ago and is still in beta? 

Anyway what about MacOS Users? 

I asked the same questions in the Sophos Connect Group, but the only answer is " yeah is at the roadmap". 

Sorry, I really appreciate your support. But this almost the same useless answer which I was get from the regular sophos support as I described before. 

Sophos should really fix this basic issues! 

I could not agree more. Sophos Support is getting more and more worrying. Statments like that are totally not acceptable.
How can it be that its August and still no solution on a simple issue like this?