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
Parents
  • 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.

Comment
  • 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.

Children
  • 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.