Sophos Connect v2.3 and SFOS v20 MR1 - SSL VPN - Delayed disconnection

Hi, Jaroslav Faldik Thank you for reaching out to the Sophos community team. I have tried to check a similar kind of re-production with SF OS and Connect client version details mentioned by you but unfortunately, the issue is not getting re-produced for me in my setup.

i.e. If I click on "Disconnect" on the Sophos Connect client side, the same user is removed from live users immediately. 

If the client is disconnected due to "Dead peer detection" then the firewall will close the connection after 180 seconds (3 min - default time) with an unresponsive client or whatever time has been set by the admin in  SSL VPN global settings.



For more info: Sophos Firewall: Understanding the Idle timeout and the dead peer detection for remote access SSL VPN
support.sophos.com/.../KB-000038126

Hi  Vishal_R 

I still don't want to terminate the OpenVPN connection on the server side when using the Sophos Connect client. OpenVPN Connect v3.4.4 and OpenVPN commnutity client v2.6.10 does not behave this way and the server side connection is terminated within seconds on the client side.

Should I open a standard support ticket for this?

Hi Jaroslav Faldik Thank you for this latest update, yes please open a support case, so this can be checked and validated further and please share the case ID with me via DM or here, so I can overlook the progress of the case and if any internal notes are needed from my end I may add over the case, thanks.

Hi Vishal_R 

I now believe that this is error NC-120615. However, I have not encountered this error before because I am using the OpenVPN community client which does not have this problem. Only I'm not allowed to use the reconnect function with it, which doesn't close the original connection each time, but creates a new one. Other users using Sophos Connect mi have not encountered this error, as they usually do not make multiple connections/disconnections in a short period of time when the maximum number of simultaneous connections could be exhausted. Globally we have 3 simultaneous connections set up.  

Hi Jaroslav Faldik Thank you for sharing this information, if your existing SSL VPN is configured on UDP protocol then yes there may be a chance it is related to NC-120615.

Currently, Sophos connects clients with UDP-based SSL VPN configuration, with no feature there to send the SIGTERM to the server while for TCP-based connection, TCP RESET packets notify the server for the same.

If you are using UDP-based SSLVPN RA then the workaround would be to set a TCP-based SSLVPN RA connection, which will immediately disconnect the user from the live user list.

In my LAB SSL VPN is set to TCP and that is the reason the issue was not observed for me when I tried to check/re-produced.

Hi Jaroslav Faldik Thank you for sharing this information, if your existing SSL VPN is configured on UDP protocol then yes there may be a chance it is related to NC-120615.

Currently, Sophos connects clients with UDP-based SSL VPN configuration, with no feature there to send the SIGTERM to the server while for TCP-based connection, TCP RESET packets notify the server for the same.

If you are using UDP-based SSLVPN RA then the workaround would be to set a TCP-based SSLVPN RA connection, which will immediately disconnect the user from the live user list.

In my LAB SSL VPN is set to TCP and that is the reason the issue was not observed for me when I tried to check/re-produced.

Hi Vishal_R 

Yes, we intentionally use UDP for SSL VPN because we also transmit video streams (usually in unicast UDP) from PTZ (Pan - Tilt - Zoom) cameras over VPN, where UDP protocol has lower latency.

I have verified on a test appliance (XG210) that after switching the VPN to TCP, the problem no longer occurs with the Sophos Connect client.

Hi Jaroslav Faldik Thank you for sharing the details of the quick test results on the test appliance. Appreciate your quick work on this for validation.