No WebAdmin access over VPN using public hostname

I can't access the WebAdmin despite being connected via VPN (SSL).

Here's the basic configuration:

The UTM has a publicly accessible hostname (with matching certificate) - COMPANY.COM -> our public IP
On our internal DNS it also has a local DNS entry - UTM.LOCAL.NET -> UTM local IP
The WebAdmin has been configured to allow all connected from our internal network, as well as the IP pools for SSL.

After I connect via VPN (SSL), I can't connect via the COMPANY.COM address, but I CAN connect using the UTM.LOCAL.NET address. That said, any machines which are physically in our LAN can indeed connect to the WebAdmin using the public DNS name.

When checking the logs, it logs a blocked WebAdmin access attempt coming not from the assigned VPN IP, but from my home IP. On one hand, this is understandable, but on the other... how do I make this work?

My only idea thus far is to add a local DNS entry overriding the COMPANY.COM public DNS, so it points to the internal LAN IP of our UTM, rather than the public IP... but there's a minor issue with that (unrelated to this question) and feels like a workaround rather than an actual solution to the problem.

So... what could I do?

  • Hi

    By default, Remote access SSL VPN pool does not use the firewall as the Default Gateway and goes out directly through the ISP when going out to the Internet (i.e. accessing the public IP of your WebAdmin). That is why you see your home’s public IP on the logs vs. the assigned VPN pool IP.

    Therefore your 2 other options are:

    1. Make the UTM the default gateway of the Remote Access SSL VPN by adding "" to 'Allowed Networks' on your VPN configuration.

    2. Change the 'Allowed Networks' on your WebAdmin settings to “Any” so it is accessible to outside users, but of course, this compromises security.  

    Hope that helps.



  • In reply to Karlos:


    OR instead of typing in "" try just the public IP of your UTM on the "Allowed Networks" of your VPN configuration

  • In reply to Karlos:

    Incorrect about internet default gateway

  • 1) what happen if you ping a local computer by name, from VPN? Example ping ecxhange.LOCAL.NET

    2) Is your VPN Pool (L2TP) allowed to use your UTM DNS

    3) Is your VPN Pool (L2TP) under Masquerading like this VPN Pool (L2TP) -- >External (WAN)?

    If the configuration is correct in webadmin settings to allow VPN Pool (L2TP), If Masquerading is Correct, and if DNS is correct you should reach the external name by internal ip



    I did the test with successful result
    And yes VPN users reach the internet from UTM once connected

  • In reply to Karlos:

    The first suggestion doesn't work and everything behaves as it did before. The second option is, of course, unacceptable.

    That said, it appears that the UTM still isn't the default gateway for my VPN connection after making these changes.

    EDIT: After opening the SSL VPN I did a quick "tracert" from my machine, and it appears I AM using the UTM as the gateway. Unfortunately, accessing the public DNS name still doesn't work, as mentioned above. Also, when you mentioned adding to the "Allowed Networks" you mean the "Local networks" section of an SSL VPN configuration? There's nothing else that would fit the bill...

  • In reply to oldeda:

    Local DNS works fine and I can ping machines by using the internal DNS. As stated, I CAN access the WebAdmin using the internal name. This, while a workaround, is a bit annoying as it throws certificate errors.

    I didn't have a DNS masquerading rule for the VPN pool... That said, adding it didn't change anything. :(

  • In reply to Mateusz Bender:

    You are able to connect by public name, but that gives you a certificate error? 

  • In reply to oldeda:

    What? No.

    From INSIDE the LAN, I can connect using the public DNS name without any issues.

    From OUTSIDE the LAN (using VPN) I CANNOT connect using the public DNS. I CAN connect using the internal DNS name, but then I get certificate errors, because the internal DNS uses internal domain names, not the public ones (COMPANY.COM vs LOCAL.NET).

  • In reply to Mateusz Bender:

    With internal DNS what you mean, UTM Dns or internal server dns? Try to use UTM dns  instead.

    And in UTM system settings, what you provided for hostname? Try to put there the public name

  • In reply to Mateusz Bender:

    Anyway I never use windows or linux servers for DNS. If it needed for Active directory or internal purposes, in UTM "DNS Service" there is "Request Routing"

    Try this way

  • In reply to oldeda:

    The internal DNS being our internal DNS server. The UTM already has the public name as the host name.

    I can try the request routing. I did follow the guidelines on the DNS config section, where it says that if there are internal DNS servers then the UTM DNS should be left blank.

  • In reply to Mateusz Bender:

    this are the simple steps to configure it correct
    And dont forget, flush your dns cache

  • In reply to oldeda:

    This sounds like a good idea, in general, and I'll see about implementing it. I do, however, need to be on-site for this, so this'll have to wait till Monday... Till then I'm left accessing the WebAdmin via the internal DNS name as before.

  • In reply to oldeda:

    One extra question... while I definitely plan to use the UTM as the DNS server, I fail to see how that will resolve the issue with the WebAdmin access over VPN.

    So, OK, the UTM will be the DNS, but it'll still resolve the public DNS name as the public IP and internal name as the internal IP... which means that I'll be getting the same errors I am getting right now (access over public DNS name is blocked while access over local DNS name is permitted, but doesn't match certificate).

    About the only thing I can think of is to add a static DNS entry for the WebAdmin to always use the internal IP (overriding the public DNS name), so if the UTM DNS is used after someone connects via SSL, then it'll work. That's assuming the VPN client does, in fact, use the VPN DNS and not the primary DNS of the machine...

    So, to summarize, how will that help solve the WebAdmin access problem?

  • In reply to Mateusz Bender:

    You are right about certificate error, but i think static dns for External IP should work