VPN DNS Priority in Split-Brain Scenario

Hi, Ryan, and welcome to the UTM Community!

Have you configured 'Remote Access >> Advanced'?

Cheers - Bob

Hi Bob,

Yes I have.

vpn_gateway has access to a subnet containing a Windows DNS server. I've set that DNS server's IP as DNS Server #1 and left the rest of the fields blank.

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

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.

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

Hi Bob,

That absolutely did the trick.

Much appreciated!

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

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

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?

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