I have just experienced the most bizarre situation. Customer has two backup internet connections on Port 2 and Port 3 that run through another router. Port 4 is the main internet connection. When downloading SSL configuration, the Sophos had local LAN IP addresses of Port 2 and Port 3 higher in the priority list. There was no way to change this and of course SSL VPN is never going to connect to a 192.168.xx.xx address.
There is nowhere anywhere in the Sophos unit to specify what WAN ports to use for SSL VPN and no way to change priority order.
Here is the stupid thing. I created a new zone "WAN2" and moved Port2 and Port3 to "WAN2". I then moved them back to "WAN". Now the WAN IP addresses in the SSL VPN configuration have changed order.
So, it looks like the order of WAN IP addresses in the SSL VPN configuration that a user downloads are the order in which the ports are assigned to the WAN zone. If you want to set the order for SSL VPN connections, set all your ports to some random zone and then assign them back to the WAN zone in the order you want the Sophos SSL VPN to use them.
Dumb - and needs to be fixed, but I'm still waiting for issues from 2012 to be fixed so I won't hold my breathe.
Hopefully this helps someone
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…
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).
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.
I never said improper behavior is proper, sorry. You are correct that the firewall should be smart enough to not offer a non-routable IP for VPN. That said, ranking has its own downsides and doesn't benefit your static use case at all.
I do think using IP addresses in any configuration is archaic and asking for problems. I remember when email addresses did not have the "@" symbol -- we used "!" and had to know how to route the emails ourselves. Ridiculous. DNS, too, was a great invention and sticking with numbers is error-prone on a number of levels.
As a trivial example, six months ago, a new ISP came along and offered incredibly more and better service for significantly less than the incumbent. (The incumbent had neglected its users for years, overcharging and under-delivering.) We switched. New IP. It's not officially fixes, but it's never changed so is essentially fixed. Next month, the old ISP will be upgrading to fiber-to-our-door, at a competitive price. So we might switch again. Or we might go with a primary and secondary. Using naked IP addresses would require changes and pushes/pulls and problems that DNS handles automatically. (In our case, DDNS since the IP is technically not fixed.)
As I mentioned, Sophos does actually have a DDNS problem where the only current solution would be to do something like you suggest and spin up a 24x7 server -- which we do not currently have for any purpose -- inhouse to do the actual DDNS update. We'd take advantage of the fact that Google DDNS can be updated without providing an actual IP -- it will take the IP of the incoming request. Which would work perfectly for a request coming from within our walls and hence routed through the current default gateway.
But let's be honest, this is in no way comparable to your situation. I pay a small fee for DDNS and Google handles it for me with zero involvement on my part. I pay a small fee to my ISP, who connects me to the internet with zero work on my part. Setting up and maintaining an in-house server for 24x7 service is a lot deeper in the weeds. Not really comparable.
Did you already create a support case for your issue?
Because from what i could see, most customers are using DDNS (any kind of vendors), which resolves such use cases in general.
If you experience an issue, which it actually could cause, then it should follow the support workflow to get to Development. The only issue, i can think of, if you are on the road and the network, you are joining, actually uses the same kind of private IP, you have in your OVPN file.
If the IP in your OVPN is not existing, it will simply not connect to this host (check before connect, takes milliseconds).
BTW: My workaround is: Start DDNS from Google on your firewall. You can specify per interface one Hostname. Lets say: XG1.domain.com, XG2.domain.com. So you have two different FQDNs in your OVPN. Both will be resolved by the firewall and send to Google. On the Google DNS interface, you can specify a health check of both DNS records. So you can say, XG1.domain.com is your WAN IP of your fiber interface. And XG2.domain.com points to XG1.domain.com, until XG1.domain.com IP is offline, then failover to XG2.domain.com.