Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Sophos Connect won't function without VPN Portal enabled.

We have a Sophos XGS 6500 and our users utilize Sophos Connect as our off campus VPN client.  Recently we ended up with some malicious user or users trying to login to our VPN web portal and locking out many accounts.  We turned off the VPN portal, but we found that broke the use of the connect client.  It works for existing users, but new users can't resolve the FQDN of the VPN interface.  Even when it knows the interface it seems to need the portal web interface to resolve.  

Is there a way to fix this so that it works but is protected from outside denial of service lock outs?  Or make Sophos Connect function without the vpn portal enabled on the WAN? 

I appreciate any insight or recommendations the community may have.  Thanks! 



Edited TAGs
[edited by: Erick Jan at 7:49 AM (GMT -7) on 25 Sep 2024]
Parents
  • Can you try to disable this option in your Sophos Connect deployment:  RE: Disabling VPN portal breaks SSLVPN connections 

    __________________________________________________________________________________________________________________

  • I checked our .pro file, and we already have the "check_remove_availability" set to "false".  Still having the issue.  This even happens to previously working connect clients.  Seems like it just sometimes stops working and requires download of the info from the portal intermittently.   If I stop using the .pro file and just use a modified .ovpn file can I just keep the VPN portal disabled?  

  • Seems all normal "by design"... The easy-2-understand version:

    User with .pro file -> Connect App is logging in the VPN portal with the user credentials entered (has to be enabled of course) -> downloading config file and importing it in the Connect App. So privisioning is nothing else than a weblogin in the VPN portal (just without user interaction).
    Once the privisioning done, the user has the config and can connect (without enabled VPN portal). If you change general VPN settings the Connect App tries to update the config again (VPN portal has to be enabled). So in short, just let the VPN portal enabled with .pro

    check_remove_availability does nothing more than check VPN address in .pro file and even not tries to connect when the VPN address not available or offline.



    Don't use MFA user authentication with .pro (buggy as hell and Sophos is still fixing nothing like a connection error after provisioning).

Reply
  • Seems all normal "by design"... The easy-2-understand version:

    User with .pro file -> Connect App is logging in the VPN portal with the user credentials entered (has to be enabled of course) -> downloading config file and importing it in the Connect App. So privisioning is nothing else than a weblogin in the VPN portal (just without user interaction).
    Once the privisioning done, the user has the config and can connect (without enabled VPN portal). If you change general VPN settings the Connect App tries to update the config again (VPN portal has to be enabled). So in short, just let the VPN portal enabled with .pro

    check_remove_availability does nothing more than check VPN address in .pro file and even not tries to connect when the VPN address not available or offline.



    Don't use MFA user authentication with .pro (buggy as hell and Sophos is still fixing nothing like a connection error after provisioning).

Children
No Data