SSL VPN change precedence order of network ports

Hi Stuart James: Thank you for sharing this information or working details with community users and definitely this will be helpful to get the clarity in terms of SSL VPN WAN precedence. 

We may define the "Override Hostname" which will fix the connection on that defined (WAN Port) ISP IP only.

Override Hostname: This sets the SSL VPN client configuration file to use this public IP when establishing the connection.

Also, another way around for this one is DNS override hostname which resolves to the IP address of one's choice.

However, for defining priority order-based settings, such requirements are already under review (possibly may integrate in future with Sophos connect client) by the PM team, and meantime I would also suggest you to upvote any existing matching thread or raise a new thread on Ideas Portal.

Actually this is a user experiences feature. It even picks up, if you have DDNS enabled on the firewall. So if you have internal interfaces like this, it would pick up, if you create DDNS for each interface and replace the value of internal IP in the OVPN file. 

So the quickest workaround would be simply by do the override hostname part, or by configuring a DDNS interface per interface. 

Personally, i did not notice the order issue, as i moved my DDNS to google and they have some good features to do this via one FQDN. But as far as i can remember, there are feature requests to be able to have more options in global settings in the future. 

I would have thought an enterprise firewall would be smart enough to know that 192.168.xx.xx is not a public IP subnet. It should use the NAT'd public IP address, just as you can do in other areas of the firewall.

Telling end users to log on to the portal, download an OVPN file, open it up in notepad and edit the configuration just so they can connect is not an option.

Depending on the use case, i guess? If you start to "not write the IP of private IPs" into the OVPN will lead to other factors. What about my proposed change? Use a FQDN as DDNS and it should resolve your issue. 

BTW: Why are you downloading the client files anyway and not using Sophos connect? (It will follow the same root cause issue, which you could resolve with a DDNS tho). 

The problem is not that it was using a LAN IP (although it's astounding that Sophos is not clever enough to see this and use the natted IP instead), the problem is that there is no way to change the order of precedence on which interface an SSL VPN uses.

I'm not going to waste my time logging a feature request. Sophos never delivers on these. There are requests with thousands of votes not done. There are even requests from 2015 where Sophos has said this is a good idea, we'll add it for release in 2018. It's still not done. Sophos do not listen to their customers, they just do whatever they think is best.

Here's a good example - to add a new terminal server to STAC, I have to give my customer full unrestricted admin console access because you can't add it through the GUI. Such a simple, basic, fundamental thing that is critical to maintaining security of the firewall but instead I've had to give nearly every customer full admin console access so that they can manage their business properly.

Using DDNS doesn't fix anything because the DDNS address is not written in to the OVPN file. Nevertheless, the problem is that I don't want it to use Port 2, I want it to use Port 4.

I am downloading the client files because that's what the Sophos documentation says to do, under "Install and configure Sophos Connect client on endpoints"

Use this process: https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/VPN/RemoteAccessVPN/VPNSConProvisioningFile/index.html 

Your process is more likely for the smaller deployments. This process can automate the installation of new files etc. 

About the DDNS part. Are you sure?

OVPN: 

And as the DDNS is written in OVPN, you could use a GoogleDNS or other DNS service, which actually have load balancing and other technologies build in. So you could easily write the same value into this field and let google do a health monitoring and failover etc. 

Most of the 200+ Sophos XG firewalls we have out there are for small deployments - 20 users or less, so creating 200+ provisioning files is a lot of effort. It's disappointing that Sophos doesn't care about the functionality for smaller deployments.

The override hostname will work though. I can just put the IP address of Port 4 in to that field and that'll force it to use that IP address for connections.

Shame there's no way to have the other WAN ports enabled in a preference order without going off and creating third party accounts and resources. Having redundant links should be core business for a firewall.

WAN ports in preference order wouldn't really add value for you, since you're evidently using fixed IP addresses and have a fixed ISP preference -- and want to specify IP addresses rather than FQDNs for your VPN server. Working with IP addresses rather than FQDNs is going to cause issues one way or the other, anyhow.

DDNS is important for us truly small folks -- who don't have fixed IP addresses -- and it handles this situation perfectly: override the host with the DDNS-managed FQDN and the have DDNS point clients to the appropriate IP -- which may not change for months at a time, or may change much more often.

The deeper shortcoming of the current solution is that Sophos DDNS is tied to gateway port and so doesn't account for failover from one gateway to another. (The DDNS should be associated with the primary gateway's IP, so that a failover would change DDNS to the secondary gateway's IP.)

Working with IP addresses with never cause issues. Public IPs are transferable. DDNS is now third party since Sophos removed its own services. I shouldn’t need to sign up to a third party and have them provide services in order to make my firewall to work properly.  Nearly every business in the country I live in have a static IP, most ISPs provide them for free. The ISPs that do charge only charge $10 a month.

If you think the Sophos trying to connect to a WAN IP address of 192.168.1.32 isn’t a problem and is acceptable, then I’m lost for words. How a firewall device can’t see that an IP address belongs to an IANA declared private IP address blocks that have been industry standard for 30+ years, I’ll never know.

But hey, if we take your approach (and that of Sophos staff in this thread who’s approach is always they are right and everyone else is wrong - refer feature requests), then your issue regarding DDNS is easy to fix using the third party methods you seem to think are acceptable. Simply spin up three VMs, route each one out through a different link and then have an agent on each VM updating DDNS. Then use Google to cycle through the DDNS records for failover and redundancy.