Related
Recommended
AlanT
Sophos Connect 2.0 is now GA

Hi Everyone,

thank you to the many thousands of users who used Sophos Connect 2.0 during EAP! I'm pleased to announce that  testing is complete, and we are now ready to launch Sophos Connect 2.0:

The client can be downloaded below, and it ill also be released via pattern update to XG firewalls, later today. 

Major new features

The main focus of this release is adding support for SSL VPN, while making it possible to bulk-deploy SSL VPN as easily as you can Sophos Connect v1.

  1. SSL VPN support for Windows
  2. Bulk Deployment of SSL VPN config via new provisioning file
  3. The same convenience features you expect in Sophos Connect for IPsec
    • OTP prompt support
    • Improved DUO MFA support (when connecting to XGv18)
    • Auto-Connect
    • Logon script execution on connect
    • Remote gateway availability probing
  4. Automatic re-fetch latest user policy if SSL policy updated on firewall (when using provisioning file to deploy)
  5. Manual re-fetch latest policy
  6. Automatic failover to next firewall WAN link when one link fails
  7. File extension association for policy files - Import a policy file into Sophos Connect just by double-clicking it in Windows Explorer, or opening the file attached in an email

 Client Download

bc691e14719314d1275a118fea7a45ba  SophosConnect_WindowsInstaller_2.0.34_IPsec_and_SSLVPN.zip

Provisioning File

The key to a number of the features is the new provisioning file format. It allows a single file to be distributed to all users, exactly as you can for IPsec today. Currently, this file must be manually created, but it's very easy. Just take an example from the supplied documentation, and change the values you want.
 
The provisioning file works by pointing the client to the XG user portal address and port. When the provisioning file is pushed to a client, the user sees the connection listed, just like any other, and when they click connect, they will be prompted for credentials, just like any other connection. The client will then login to the XG user portal using the supplied credentials, fetch the latest SSL VPN policy for that user, and connect the VPN using the same credentials just entered. This is all invisible to the user, and only adds a few seconds to the connection time. Then later, if the connection fails, the client will automatically fetch an updated VPN profile from the user portal, in case any of the policy settings have been changed. 
 
Bulk deployment works seamlessly when the user portal is accessible to clients where they are connecting from. If you are concerned about exposing the user portal to the internet on default ports, you may want to consider move it to a less commonly used port, that will lower its exposure to drive-by port 443 scans.  You can of course only expose the user portal to internal networks, though this will limit the effectiveness of the bulk deployment. 

Sophos Connect EAP Forum is now closed

With the recent GA launch of Sophos Connect v2.0, the Sophos Connect EAP forums will now be closed.

Please continue to raise your related Sophos Connect questions or issues on the main Sophos XG Community forum using the tag "Sophos Connect" to help the team easily find your post.

Known Limitations

  • Sophos Connect 2.0 is not expected to work on Windows 7

  • Has the ability to customize the OTP re-prompt timer on the IPSec client been added?

  • in reply to Ajay Madhvraj

    auto-connect_host is how the client can determine if it is home or away.  It will first compare the auto_connect_host value to the dhcp dns suffix. if that matches, then it is home, and won't try to connect. otherwise, if it can ping the hostname or IP, then it will also consider itself to be local, and not attempt to connect. Otherwise, if it can't ping it, and it doesn't match the dns suffix supplied by dhcp, then it will attempt to connect. 

    check_remote_availability checks all IP addresses and hostnames supplied in the ovpn configuration, and removes those that cannot be reached from its connection profiling. so if some are private internal IPs, then this option can in some cases speed up the connection process. 

    run_logon_script works only in AD environments, and on connect, will attempt to trigger configured AD logon scripts to be run. Without this option, AD logon scripts typically will not run on connect.  

  • in reply to Ajay Madhvraj

    Hi Ajay, IPsec can only connect to one gateway. That's an XG limit in the way the feature is implemented. SSL VPN will attempt to connect to any connection available. You can specify order in the provisioning file. the gateway_order parameter has three options."distributed" will choose a gateway at random, then connect to that gateway address as long as it is available. If it is no longer available, then it will randomly select another gateway. "latency" will measure the connection time to each gateway, and prefer the closest gateway.The latency is measured by a connection attempt, and not a simple ping. Assuming that many connections to a single gateway will result in higher latency, then this might be the best option for you to try.

  • I am going through https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/concepts/SConProvisioningFile.html

    • Not clear on "auto_connect_host" description, explanation is confusing. Who is considered as Tartget Host? I had to discuss with local SE team to understand what it meant. Explanation through a network diagram will be always good.
    • Same above statement for "check_remote_availability"
    • Same above statement for "run_logon_script" & enabling this button will it trigger non-responsive logon script after connection? For ex: Fetch new AV policy is logon script, script writer might have already written to keep running this script until successful, enabling this feature on VPN agent how does it make any difference? Please explain with some use cases.

  • Having single agent for both VPN is very good option, thank you for that. Challenge what we are facing is: We have 1000+ users connecting some on SConnect and some on SSLVPN. Some times we notice many on 1 ISP and that ISP will be completely chocked and secondary ISP is free but not used efficiently. Here what we are doing is playing around with config file OR order of ISP OR config file having only specific ISP for 500 users and different for others. ISP failover challenge comes in. SConnect supports only 1 ISP. Our customer has 450 Mbps, 200 Mbps, 155 Mbps, 100 Mbps ILL lines. There are lot of manual work involved.

    • Agent must get information from FW to select an ISP based on availability & stability of BW.
    • ISP availability indicator, best ISP to connect.
    • TLS 1.3 support.
    • Diagnostic tools like ping, trace route, dns resolution, route table.
    • Specific device authorization.
    • AD to choose while logging in.
    • BW after connecting to VPN drops drastically.

    Some are cosmetic requirements, some on technology. Hope your team comes up quickly and take Sophos to next level.

Unfiltered HTML