DNS Unresponsive on Essentials VPN

On my new-ish Server 2016 with the Essentials role, I set up the Anywhere Access VPN with a static address pool (described here). When I connected via VPN from a Windows 10 Home machine, everything worked great:  I could see the Shared Folders, Internet browsing was fine, etc. But when I connected from a Windows 10 Pro machine, the VPN was almost non-functional:  I could not browse shared folders (unless I first connected via an IP address) and Internet browsing slowed to a crawl as each site spent 8 seconds “looking for host”.

DNS Issue

I saw confirmation that DNS was the issue when I used NSLookup. In these (obfuscated) examples, 192.168.77.2 is the IP address of my Essentials server.

Good Machine

Here we see DNS responding as expected:

C:\>nslookup
2.77.168.192.in-addr.arpa
        primary name server = localhost
        responsible mail addr = nobody.invalid
        serial  = 1
        refresh = 600 (10 mins)
        retry   = 1200 (20 mins)
        expire  = 604800 (7 days)
        default TTL = 10800 (3 hours)
Default Server:  UnKnown
Address:  192.168.77.2

Bad Machine

Here, though, DNS is completely unresponsive, even before issuing a query for google.com.:

C:\>nslookup
DNS request timed out.
    timeout was 2 seconds.
Default Server:  UnKnown
Address:  192.168.77.2

> google.com.
Server:  UnKnown
Address:  192.168.77.2
DNS request timed out.
    timeout was 2 seconds.
timeout (2 secs)
SendRequest failed

What Didn’t Help

1. One suggestion was to change adapter priority. That’s no longer possible under Windows 10 as explained in this article. Now, priority is controlled by metrics. I reviewed interface metrics using netstat –rn and netsh interface ipv4 show interfaces, but could not find significant differences between the “good” and “bad” machines.

2. Another suggestion was to open the VPN connection properties on the client, go into the Networking tab, IPv4 Properties, Advanced button, then check Use default gateway on remote network. The idea behind this is to avoid split DNS, where some queries are handled by the local connection and some by the remote. Unfortunately, this didn’t solve the problem. On reflection, I don’t think that the DNS is split:  on the bad machine, it’s trying to use the remote server as the DNS server; it’ just not getting a response.

3. Turning off the firewall on the server and client didn’t help either.

4. I tried using Wireshark to trace DNS events, but WinPcap can’t see into PPP VPN packets. Running Wireshark on the server didn’t get me too far either.

However, by enabling DNS analytic events on the server (setup described here), I was able to confirm that the DNS server was in fact receiving and responding to the queries from the bad computer. I just couldn’t figure out why the computer never received them.

QUERY_RECEIVED: TCP=0; InterfaceIP=192.168.77.2; Source=192.168.77.248; RD=1; QNAME=google.com.; QTYPE=28; XID=3; Port=57609; Flags=256; PacketData=0x00030100000100000000000006676F6F676C6503636F6D00001C0001; AdditionalInfo = VirtualizationInstanceOptionValue: .

RESPONSE_SUCCESS: TCP=0; InterfaceIP=192.168.77.2; Destination=192.168.77.248; AA=0; AD=0; QNAME=google.com.; QTYPE=1; XID=2; DNSSEC=0; RCODE=0; Port=57607; Flags=33152; Scope=Default; Zone=..Cache; PolicyName=NULL; PacketData=0x00028180000100010000000006676F6F676C6503636F6D0000010001C00C00010001000000660004D83ADB2E; AdditionalInfo= VirtualizationInstance:.

The Fix

I happened to be looking at the DNS server setup for another reason. I was reminded that the server gets a second IP when you set up the VPN. In my case, I set the static IP address pool to 192.168.77.240 – .254, so the second IP was 192.168.77.240. By default, the DNS server listens on all IP addresses. Hmm… what would happen if I told it to not listen on .240? Bingo! Once I unchecked the .240 address and restarted the DNS server service, the “bad” computer immediately began behaving properly, resolving DNS against 192.168.77.2, showing me Shared Folders, and letting me browse the Internet without delay.

Still scratching my head at why this makes a difference, but I’m glad I can once again use the VPN from this machine.