Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 11 replies
  • Subscribers 4 subscribers
  • Views 19679 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

VPN DNS Priority in Split-Brain Scenario

Ryan Swin

Hi There,

This is my first post here, so apologies if I've categorized this question incorrectly...

We have a DNS zone on our LAN for example.com, for which we have a handful of records. We also have example.com registered publicly, with a lot of overlap in the records (but not one-to-one).

My question is: How does Sophos VPN decide which DNS server to use in a scenario when the record exists both internally and publicly?

As per the .ovpn configuration used by the VPN client, I'll define:

vpn_gateway = gateway for traffic traversing the VPN

net_gateway = the normal gateway for the LAN in which my computer resides (i.e. home router)

My experience so far has been that traffic will be sent via vpn_gateway only if a usable route to the destination using net_gateway does not exist (i.e. DNS resolution fails at net_gateway). I like this from a security/bandwidth perspective (I believe the term for this is split-tunnel)...

This leads to my last question, which is: In the default "split-tunnel" configuration, is adding a static route to the client-side config The only way to force traffic to route via vpn_gateway instead of net_gateway? (In a scenario where there is a usable route to the destination via net_gateway)

Config I am referring to: C:\Program Files (x86)\Sophos\Sophos SSL VPN Client\config\user@domain.ovpn

Any advice appreciated.

 

Edit: It just occurred to me that I might be able to force all traffic to go through vpn_gateway by default, but then create a firewall rule restricting SSL VPN clients to the LAN.

This way, when a client connected to the VPN attempts to hit www.google.ca, for example... DNS resolution would fail on vpn_gateway, and they would be redirected to use net_gateway (as desired).

Might be an option?



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to Ryan Swin

    I normally include the IP of "Internal (Address)' as the first or second forwarder there.  Also, you might be interested in DNS best practice.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob,

    Sorry for the delayed response. I walked away from this issue, as it doesn't have a much impact on our daily operations. I've come up with another relevant example that I can't seem to get around:

    The destination address I cannot seem to reach by name whilst connected to SSL VPN is server.domain.com

    Internal DNS server:

    - Has a forward lookup zone for domain.com

    - Has a host record for server.domain.com -> 192.168.10.10 (the internal IP of the server)

    External (public) DNS server:

    - Has a forward lookup zone for domain.com

    - Has a host record for server.domain.com -> 1.1.1.1 (1.1.1.1 is the public IP of our company router, which contains NAT forwarding rules to reach 192.168.10.10).

    With the my current SSL VPN settings I have on the UTM, the client behavior is as follows:

    When Connected to the VPN:

    - Pinging server.domain.com results the IP address resolved by the public DNS server: 1.1.1.1 (this is unexpected - I would expect this to resolve to the internal address, because the VPN has been configured to use an internal DNS server with a host record for this FQDN)

    When Not Connected to the VPN:

    - Pinging server.domain.com returns the IP address resolved by the public DNS server:1.1.1.1 (this is expected)

     

    I have read over your DNS best practices, and bolded the ones that I feel are most relevant:

    1. The 'Global' tab of 'Network Services >> DNS' lists "Internal (Network)" (also other internal networks, like "DMZ (Network)" if applicable) as 'Allowed networks'

    - This matches my configuration

    2. On the 'Forwarders' tab, use an Availability Group containing the OpenDNS or Google (8.8.4.4 first, for speed) name servers in 'DNS Forwarders'. 'Use forwarders assigned by ISP' is not checked.*

    - I'm using "Use forwarders assigned by ISP", which as far as I know should behave the same as if I specified Google or OpenDNS.

    3. In 'Request Routing', the internal DNS is used for reverse DNS of internal IPs (for example if your internal subnet is 172.16.20.0/24, you would have "20.16.172.in-addr.arpa" in the 'Domain' field and your internal DNS server(s) in 'Target Servers'. With that, the UTM can list machine names instead of internal IP addresses in the reports.

    4. Also, in 'Request Routing', so the UTM can resolve internal FQDNs, add, for example 'yourdomain.loc -> {internal DNS server}'. Do the same for other domains for which you have Forward Lookup Zones in your internal DNS server.

    - I have added a request route for domain.com -> (internal DNS server IP)

    5. Configure Windows Server (or other) DHCP server for internal devices to point at your internal name server for DNS, then the UTM, then the OpenDNS or Google servers

    - I am using Sophos UTM as a DHCP server. When running ipconfig on a client connected to VPN, I can see the internal DNS server listed (along with no other servers)

    6. The internal DNS server's first forwarder is to the UTM's DNS Proxy, then to the OpenDNS or Google servers.

    - My internal DNS server has one forwarder configured - the IP address of the UTM.

    7. If you consistently have "connection to server timed out" issues and ECN is not selected ('Advanced' tab of 'QoS'), empty 'Allowed networks' in #1, configure the internal DNS server to bypass the UTM in #6. I suspect this is caused by a problem at the ISP.

    Lastly, as I mentioned in my original post... I have attempted to use one of two configurations in my .ovpn settings (C:\Program Files (x86)\Sophos\Sophos SSL VPN Client\config\user@domain.ovpn):

    Line 7: route remote_host 255.255.255.255 net_gateway

    and

    Line 7: route remote_host 255.255.255.255 vpn_gateway

    Both with no luck. I think the issue has to do with the IP being resolved before the packet reaches the Sophos router. Any help is appreciated.

  • +1 in reply to Ryan Swin

    Sometimes, one needs to run ipconfig /flushdns on the PC.  If that didn't solve the problem, add "VPN Pool (SSL)" to 'Allowed Networks' for 'DNS' and, on the 'Advanced' tab of 'Remote Access', make the IP of "Internal (Address)" your DNS server #2.  Any better luck with that?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob,

    That absolutely did the trick.

    Much appreciated!

  • 0 in reply to BAlfson

    "Internal (Address)" = is that the UTM internal address, or the Internal DNS Server address?

  • 0 in reply to Benjamin Whitehouse

    Hallo Benjamin - first we've seen you here - welcome to the UTM Community!

    Good question.  I'm fairly obsessive-compulsive when it comes to technical documentation...

    Whenever you see something in quotes ("), it's either a direct quote from someone or it's the formal name of some object in WebAdmin or a selection in a drop-down box.  In this case, "Internal (Address)" is the object created automatically by WebAdmin and the configuration daemon when you define an interface named "Internal."

    When I use single quotes ('), it's either quoting something that contains a quote of something from someone else or it's a heading in WebAdmin.  You would define an interface in WebAdmin on the 'Interfaces' tab in 'Interfaces & Routing >> Interfaces'.  When making the definition of the "Internal" interface, the UTM culture is to select "eth0" for 'Hardware'.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thanks Bob! That makes perfect sense.

    I am having a similar issue described in this thread, except I don't have an internal DNS Server - only the Sophos UTM9, which is our client's default gateway.

    On 'Remote Access' > 'Advanced', our Client Options look like this:

    DNS Server #1: [UTM IP Address 10.x.x.1]

    DNS Server #2: 1.1.1.1

    Domain Name: example.com

    Sometimes, our remote clients cannot resolve our internal address intranet.example.com - presumably because at this moment the client is using DNS Server #2 (1.1.1.1) and returning a public error page from our external webhost.

    The issue is intermittent. This morning, I performed a test on a new machine, new browser, new VPN client install, and the resolution was perfect every time. 

    When this issue occurs, I flush dns cache and clear browsing history, but the issue remains. 

    I am looking into installing an internal DNS server on our network, but would prefer not to.

    Would it be a solution to remove the DNS Server #2 address, to force all VPN clients to use the UTM?

  • 0 in reply to Benjamin Whitehouse

    I'd be curious to know if deleting the entry for the second DNS server solved your issue.  Is "VPN Pool (SSL)" in 'Allowed Networks' in 'DNS'?

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hey Bob!

    I decided not to risk changing it, as I cannot yet determine a suitable time to try it. We have many offsite staff relying on VPN, often in stressful situations.

    Incidentally, new High Sierra Macbook's deployed, with fresh Safari browser, connected via Tunnelblick to the Sophos, can find the internal wiki via DNS hostname, no problem. Finger's crossed...

    I also noticed our firewall needs new firmware upgrades. Included in the update package 9.601005 is a Bugfix in the Changelog: "Delay in accessing internal services after users connect to the remote access SSL VPN". 

    Perhaps this will further improve things.

    Greetings from Berlin, DE!

Unfiltered HTML