Thread Info
  • State Suggested Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 41 subscribers
  • Views 6197 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN change precedence order of network ports

Stuart James

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



This thread was automatically locked due to age.
  • 0 in reply to Stuart James

    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.

  • 0 in reply to Stuart James

    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. 

    __________________________________________________________________________________________________________________

Unfiltered HTML