Computer suddenly stopping using the remote DNS servers via VPN
Posted by Fit-Strain5146@reddit | sysadmin | View on Reddit | 53 comments
Hi,
We are experiencing a very weird problem. In the past year (approx), 5 computers got this problem after a reboot. No specific update, nothing special, and there was at least a few months between the first and last one, but recently got 2 in the same week so I thought I would give it a shot here.
Exact problem: Initial situation: everything is working correctly. After a reboot, the person opens a VPN connexion (Windows client), but nothing works for anything that requires VPN. Error is always something like "host not found". After some packet capturing, we found (on the first one, haven't checked all of them), we discovered that the main DNS servers are used all the time, even when connected via VPN (the remote DNS servers should be used).
Workaround: Since there isn't many services that are at the other end of the VPN tunnel, we create entries in "C:\Windows\System32\drivers\etc\hosts" and it works. However we never found a permanent solution, except resetting the computer. Any ideas/questions welcome.
We did a lot of things to try to fix the issue:
- Lower the metric of the VPN tunnel network interface
- All these commands, then reboot:
- netsh winsock reset
- netsh int ip reset
- ipconfig /release
- ipconfig /renew
- ipconfig /flushdns
- nslookup works OK, and apps don't
Thanks in advance.
frosty3140@reddit
is IPv6 in play on the affected clients? I've occasionally seen similar (but not the same) issues with some of my remote clients, where the IPv4 DNS lookups to the Internal DNS servers won't work until I disable IPv6 on that client.
Fit-Strain5146@reddit (OP)
I'll check once the computers are online tomorrow. But does it stop working suddenly or just never works?
frosty3140@reddit
Not 100% sure TBH. We only happened upon the issue by chance. I had noticed some clients unable to check in on our management system (clients run an agent). Investigating eventually tracked this down to a DNS lookup failure, subsequently IPv6. Long shot, but worth a try if you're running out of options for things to check.
Fit-Strain5146@reddit (OP)
Which one is the relevant NIC - the actual NIC or the VPN network interface?
Dracozirion@reddit
When Windows has bot IPv6 and IPv4 DNS servers, it will send a lookup to both of them simultaneously and accept an answer from the first response. Usually, that's the ISP's DNS server. Even if the answer is NXDOMAIN.
You can fix this without disabling IPv6: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
DisableParallelAandAAAA : 1
Holefully this helps.
battmain@reddit
We have this problem every few weeks. Done everything you have. Rebooting the firewall usually resolves. We have a PO in to replace firewall with a different brand.
Fit-Strain5146@reddit (OP)
The firewall is not the VPN endpoint, in our case.
battmain@reddit
I see another comment that mentions resetting network on the problem device. I've also done that to fix strange problems. It only costs re-entering WiFi passwords in most cases although I have had to reset IPs in the ethernet properties when required.
MightBeDownstairs@reddit
This could be something simple as driver stack corruption. Reset the network adapter via windows advance network setting or reinstall the drivers.
Fit-Strain5146@reddit (OP)
Will try that. Thanks,
FastFredNL@reddit
I dunno if this is the exact same case but we had issues with VPN's when ipv6 was active on the active network adapter. The computer would try to resolve a fileserver (for a networkmapping for example) on the ISP's router.
We could test this by adding the networkmapping manually with an IP-address instead of the hostname of the server.
Fit-Strain5146@reddit (OP)
IP connectivity that doesn't require DNS works.
FastFredNL@reddit
Then it's likely trying to resolve the servername (or whatever you're trying to reach behind the VPN) at the ISP's router or at the ISP itself.
Fit-Strain5146@reddit (OP)
Yes, that is exactly what is happening. From the original post: "After some packet capturing, we found (on the first one, haven't checked all of them), we discovered that the main DNS servers are used all the time, even when connected via VPN (the remote DNS servers should be used)."
FastFredNL@reddit
Did you try unchecking ipv6 in the active network adapter setting? That fixed it for us.
You don't happen to use Fortinet's VPN client are you?
Fit-Strain5146@reddit (OP)
What do you consider the "active" network adapter? The real NIC or the VPN adapter?
No, the built-in Windows VPN client
purplemonkeymad@reddit
When I see this it's almost always that the VPN server has stopped sending the DNS servers as part of the connection. When you do an ipconfig /all while connected, there should be DNS servers in the tunnel's section. If not that is your issue.
Fit-Strain5146@reddit (OP)
The 2 DNS servers are shown in the output of ipconfig /all
alphaxion@reddit
What is the VPN used for?
Have you checked your VPN client settings defined on firewall or whatever the VPN endpoint is? Are those DNS servers on the other end still valid?
Connect to the VPN and then try in a cmd prompt:
nslookup
server [IP address of remote DNS server]
[remote.fqdn.address]
Does it resolve? Does it say server unreachable? Does it say there's no record?
Who manages the VPN portal that your systems are connecting to? If it's not you, have you asked them?
Fit-Strain5146@reddit (OP)
The VPN is used to reach the on-prem PBX and file server, mostly.
My team manages the VPN and works perfectly for dozens of computer. Don't forget that this problem starts suddenly on a computer that has been working fine for months.
nslookup works perfectly even without explicitly setting the resolver. It also works when setting the server. No DNS request is sent to our DNS servers, they are sent to the user's DNS servers (their ISP or their router, etc).
alphaxion@reddit
You're wanting to specifically test that the remote DNS is working via nslookup by manually setting it as the server before looking up one of the addresses that is failing while connected.
That way you can see if that DNS traffic is being captured and sent down the tunnel or it's just dying before even hitting the tunnel interface.
What do the VPN client logs say and what does event viewer say on the PC exhibiting the problem? Usually there will be a hint as to what it is doing in there (PanGPS.log if this is Globalprotect, for example).
You need to info gather if basic troubleshooting steps aren't revealing what is going on.
Fit-Strain5146@reddit (OP)
It's the built-in Windows VPN client. I'll look at the event log.
Remote DNS server already tested. It does work using nslookup, even without setting the resolver using 'server'. In the packet capture, we saw absolutely no packets sent to the remote DNS servers, they were only sent to the "regular" DNS resolvers.
alphaxion@reddit
What you said there confuses me a bit.
Remote DNS already tested on an affected system but without actually setting it to use the remote DNS server in nslookup?
Did you mean when you typed in nslookup and entered that app, it was already using the remote DNS server?
What I'm suggesting is to enter nslookup (not just type it in a run box) while in a cmd prompt so you end up with something that looks like the following
Microsoft Windows [Version ]
(c) Microsoft Corporation. All rights reserved.
C:\Users\user>nslookup
Default Server: currentdns.domain.name
Address: 10.10.10.1
>
change the server address to your remote DNS server address using the server command while in nslookup if it's not already using that address in that initial stage, then try resolving an address record on the remote DNS server to make sure that the traffic is going across your tunnel.
In that scenario, there should be zero use of their local DNS server to resolve the server address because you've manually told nslookup to use a specific server.
As an aside, what address are you using to access the resources over your VPN tunnel? Are people just using \\servername or are they using the FQDN of \\servername.domain.name?
If they're using just the shorter netBIOS name, have you tried using the FQDN, as it could be some weird search domain related issue?
Fit-Strain5146@reddit (OP)
nslookup hostname.domain works and uses the remote DNS server
nslookup hostname.domain ip.ad.rr.es (IP of the remote DNS server) works as well.
For both remote DNS servers.
ping hostneme.domain doesn't work
countsachot@reddit
It's only happening on one pc?
Fit-Strain5146@reddit (OP)
We currently have 2 laptops that have this problem. It started last week. The previous one was a few months ago.
countsachot@reddit
Windows or driver updates?
Fit-Strain5146@reddit (OP)
That is a valid hypothesis. The 2 computers are part of a test group for updates and received updates the day before. But the test group contains 18 computers and only 2 broke.
countsachot@reddit
Are they all the same model?
Fit-Strain5146@reddit (OP)
Yes
countsachot@reddit
Hmm, odd I would look for differences between the models that failed and the ones that passed. Are there software or hardware deviations? NIC revisions or firnware versions, installed software, etc.
Fit-Strain5146@reddit (OP)
They are the exact same model number from Lenovo. The only difference we discovered is that they use 3 different webcam models in the same laptop model.
fiberstrings@reddit
Just wanted to chime in here… you say you’re using nslookup, but in modern Windows that doesn’t cover all the resolving cases. It’s recommended to use PowerShell’s “Resolve-DnsName” as that command makes use of zone-specific DNS servers. I remember that when using Tailscale and trying to resolve names using nalookup, that that is a problem.
Fit-Strain5146@reddit (OP)
I'll keep that in mind. Thanks.
Sunsparc@reddit
I've had a similar issue. IKEv2 VPN with SSTP fallback.
Randomly, when a VPN connection is initiated, all internal URLs do not resolve. If I ping app.mydomain.com, it should point to a 192 address but it instead points to one of our external VIPs. If I do a tracert, it acts like it's trying to egress out of the firewall and then ingress back in via the VIP, instead of making the single hop from the VPN server to the server that's hosting the application for which app.mydomain.com is tied to.
I've gone round and round with searching and prompting ChatGPT/Claude. Both seem to think that inserting an NRPT rule is the final fix-all but the rule doesn't have an effect.
It appears to be a DNS leak. DNS is trying to use the Ethernet/Wifi interface DNS servers instead of the VPN interface DNS servers, which is why the external VIP shows up. My current band-aid fix is to have the person connect to a completely different network. Hotspot, guest wifi at a coffee shop, neighbor's wifi, whatever "other" network. Then once they come back to their network, the problem goes away. DNS is resolving properly for internal resources afterward.
Horror-Squirrel4142@reddit
The tell is that nslookup works but normal resolution doesn't. nslookup queries the server you point it at directly and ignores Windows resolver policy, so it proving the DNS server is fine isn't surprising, the failing path is the stub resolver picking the wrong adapter.
On a split-tunnel setup both the VPN adapter and the physical NIC have DNS servers. After a reboot the VPN adapter sometimes comes up with a higher interface metric than the LAN/WiFi NIC, so Windows smart-multihomes the query out the physical adapter, the public resolver returns NXDOMAIN for your internal names, and that negative answer gets cached (hence flushdns sometimes helping briefly).
Durable fix is NRPT: push a rule for your internal DNS suffix(es) that forces those namespaces down the tunnel's DNS regardless of metric. Failing that, set the VPN adapter's interface metric lower than the physical one. Metric/binding-order tweaks work but NRPT is the one that survives reboots cleanly.
jubilant_dentist@reddit
sounds like a dns caching issue or the vpn client not properly pushing the dns settings on reconnect, have you tried disabling dns caching on those machines or checking event viewer for dns client errors right after reboot?
Fit-Strain5146@reddit (OP)
ipconfig /all shows the right DNS servers configuration. Tested after a /flush dns - no change
jubilant_dentist@reddit
then the config is right but something's overriding it at runtime, check if theres a group policy or third party security software forcing dns queries before the vpn tunnel fully establishes.
Fit-Strain5146@reddit (OP)
My team manages everything from GPOs to Intune, security software to RMM and VPN service. No such policies are applied. Especially not on 2 computers out of the blue. And one computer a few months ago.
jubilant_dentist@reddit
if its random machines and nothing in policy then its probably something client-side like a stuck dns cache at the winsock level or the vpn client service not reloading properly, try stopping and restarting the dns client service after vpn connects on the next affected machine instead of rebooting.
deebeecom@reddit
Do these laptops belong to users who use Comcast / xfinity.
They have been changing the WiFi routers (which they provide) dhcp to be 10.x range.
And they are doing it randomly in any region.
Most corporate networks user 10.x.
Check if there is a network overlap,
Check netstat -nr to see where the dns lookup packets really go.
Fit-Strain5146@reddit (OP)
I see where you're going. Had this issue in the past with our file server, but in this case, the packet captures show that the DNS queries go to the ISP's DNS server or their router. And the IP address of the two affected computers are not in the subnet where our corporate DNS servers are.
Adam_Kearn@reddit
Under the VPN properties you should be able to enter the FQDN suffix to be used. This needs to be your domain name such as domain.local or company.com etc….
Disconnect and reconnect and test the VPN again.
If you are still having issues under the IPv4 settings of the VPN you can also manually set the DNS servers that get used (only within the VPN adapter)
———
If you are still having issues after then then I’ve had to manually add the routes into the network adapter using command prompt before for a client once.
You basically just define the network range and tell it what route to use when connecting out on split tunnel connections
Agitated-Fly3564@reddit
Nice detailed advice
Fit-Strain5146@reddit (OP)
Thanks, but the domain suffix is already set. Before the problem, we could do a "ping server1" and it would work. We could also do a "ping server1.fulldomain.tld and it would work.
I didn't think about setting the IPv4 setting on the VPN interface. That would be better than using the host file. Thanks.
The routes are not the problem, we already have all the routes that we need, as nslookup works 100%, it does use the right server without specifying it, and gets a response. However, I will try to do a tracert to the remote DNS server out of curiosity.
Adam_Kearn@reddit
Okay. Try manually defining the DNS servers within the VPNs interface and see what happens.
I’ve had the same problem before and it just seems to be random.
Sometimes I just reimage the user’s computer when I get weird issues like this. as it’s often they have not had a reimage since they was originally handed their computer.
Fit-Strain5146@reddit (OP)
That's the only permanent solution we found. Images are at most 18 months old.
Exact_Juggernaut_533@reddit
Hi mate,
I created an account for this as I ran into this once and found it was due to the VPN having "Use default gateway on remote network" unticked. When unticked, Windows treats the connection similar to a split tunnel.
It can be found by going to your VPN in settings and opening More VPN Properties > Networking Tab > IPv4 Properties > Advanced.
See attached image and hopefully it helps!
https://imgur.com/a/6TQTDlA
If this doesn't work...best of luck
Agitated-Fly3564@reddit
Hope it does man
Fit-Strain5146@reddit (OP)
Thanks for your answer. I forgot to mention that it is a split-tunnel configuration. I just updated my post.
deebeecom@reddit
What’s the vpn server
Fit-Strain5146@reddit (OP)
Windows RRAS