Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 5 replies
  • Subscribers 38 subscribers
  • Views 647 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

Best way to handle error pages to VPN clients

Wayne Folta

Error messages and interaction pages from the XG have to refer to a specific address (XG's first configured IP, hostname lookup, etc), which works fine for hosts behind the firewall, but for VPN clients it causes problems.

For example, let's say your firewall's first configured interface is 192.168.1.1. So any IPS warnings that appear come from 192.168.1.1 which works fine from within the firewall: you are able to retrieve the warning page. (You may have certificate trust issues, but that's a different matter.)

BUT if you're on the VPN, you may actually have a 192.168.1.1 as your LOCAL (i.e. local at the remote end where you are) gateway/firewall  which your client machine can't differentiate from the far end's (internal) 192.168.1.1, so the warning will always fail since the local 192.168.1.1 (to the remote VPN client) of course will not serve up the warning HTML. You can't fix this from the remote (VPN SSL Client) end, since it will actually need to communicate with that LOCAL (at the remote end) 192.168.1.1 to get anywhere. At least I think that's the case.

So what's the proper way to handle this? I'm imagining a NAT rule that covers traffic from 192.168.1.1 (XG) to the VPN zone and does a MASQ? I'm afraid to try it right now, since I'm remote and using the VPN and can't afford to screw it up. At the same time, it's very difficult to test when you're onsite since 192.168.1.1 goes to the correct place.

In particular, I'm afraid that a close-but-no-cigar NAT rule would NAT all traffic to the VPN. Or maybe I've got it backwards. And does the warning HTML come from 192.168.1.1 or does it just use that IP as some kind of referral address?

I guess another way around it is to pick a LAN IP range that you think no one else will ever have at the remote end. (Probably avoiding 192.168.1.0 and 192.168.0.0 are a good idea for most consumer "routers", but you can't anticipate everyone else in the world's LAN addresses.)



This thread was automatically locked due to age.
  • 0

    Hi Wayne,

    You may refer to this recommended read for Overlapping network for SSL VPN as a reference.

    https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/128612/ssl-vpn-access-for-overlapping-home-networks

    To test it you may only set a test FW rule and one single user is allowed. so that it would not affect the whole network set up

    Erick Jan
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Erick Jan

    Wow, that's mind-bending... and I'll accept it but I'm not sure that this solution will work for the remote (VPN) clients and also the local (inside the firewall) clients as well. I'll give it a shot and if it works internally it should also work for VPN clients as well. The IP address I'd be DNAT'ing to is the XG itself, not something behind the XG. So I think this means that the Original Source would need to be essentially all private addresses (to include the VPN and all internal subnets. (The idea being that there's only one IP address that shows up in the captive/warning URLs and that would have to be the fake address for everyone.)

    Better would be to have XG be able to use multiple addresses as appropriate for the client.

  • 0 in reply to Wayne Folta

    Looking less promising. Here's my attempt at the rule. Is this looking correct for my use case? (Note the difference in the Original Source field that's required I think to include all "inside the firewall" clients (including the VPN) and exclude the WAN at large:

  • 0 in reply to Wayne Folta

    And here's the change I'd make in Administration > Admin & User Settings. (Note that if I switch to Use a Different Hostname and put in the Fake IP, and then do Check Settings, I get two flags. Doesn't mean I can't do it, but does give me pause that this may not work as in the more general case of a separate server that I'm trying to access from someone's home network. I'm also wondering if this setting only sets up the URL for the web page or if it also sets the XG's web server's expectations such that if the DNAT maps to the first internal interface the web server won't accept the traffic because it's supposed to be accepting URLS for the Fake Address.

  • 0 in reply to Erick Jan

    I've had to un-accept the answer as it seemingly does not work. The document you linked to has an outline that works for a server other than the XG itself, but unfortunately this does not appear to work in the use case of trying to DNAT the Fake Address to be the XG itself. Of course, I'm trying to do it for HTTPS in order to reach the warning webpages that the XG can present to the user, but also testing it with Ping, I get a "Destination Port Unreachable" error.

    I also tried adding an ACL exception (Accept) for the Fake Address, just in case checking was done before DNAT, but that didn't fix the problem.

    So it appears that if a VPN remote client does something that is supposed to show them a warning/captive page, it will not work if the remote subnet from which they are VPN'ing conflicts with the XG's internal IP addresses. (And since you must have a single IP address in Admin Console and End-User Interaction, this DNAT must work for in-house IP subnets, not just VPN, but that's a second matter.)

    Again, the solution to this is for the XG to use the IP address of the port (or VPN)  on which it sends the URL.

Unfiltered HTML