When This Error Hits
You're on Windows 10 or 11. You connect to the office VPN, everything works. You disconnect from VPN to go back to your local network. Suddenly, typing \fileserver.company.local in Explorer throws a DNS error. Ping returns Ping request could not find host. Nslookup fails with DNS request timed out. The domain is your internal Active Directory domain, and it worked fine before the VPN session.
I've seen this on Windows 10 20H2 through 22H2, and on Windows 11 21H2 and 22H2. It happens with Cisco AnyConnect, OpenVPN, and the built-in Windows VPN client. The trigger is the VPN client messing with your DNS suffix list.
Root Cause
Your network adapter has a DNS suffix order. When you're on the corporate LAN, the adapter gets the internal DNS suffix (like company.local) from DHCP. The VPN client adds its own DNS suffix. When you disconnect from VPN, the VPN client doesn't clean up properly. It leaves a junk DNS suffix entry at the top of the list, or it removes the internal suffix entirely. Windows then tries to resolve the domain using the wrong DNS server or no suffix at all.
The culprit here is almost always the DNS suffix for this connection setting under the adapter's IPv4 properties. The VPN client either appends a garbage suffix or clears the internal one. Don't bother restarting the DNS service — that's a waste of time. The fix is in the adapter settings.
Step-by-Step Fix
- Open Network Connections
PressWin + R, typencpa.cpl, hit Enter. This opens the Network Connections window. - Identify the Active Adapter
Look for the adapter you're using right now — it's usually the one with the green signal bars or the one that's Connected. If you're on Wi-Fi, it's your Wi-Fi adapter. If you're on Ethernet, it's your Ethernet adapter. Ignore Bluetooth or VPN adapters. - Open IPv4 Properties
Right-click the adapter, select Properties. Find Internet Protocol Version 4 (TCP/IPv4), select it, then click Properties. - Check DNS Suffix
In the IPv4 properties, click the Advanced button. Go to the DNS tab. Look at the DNS suffix for this connection field. If it's empty or shows something weird likevpn.company.localoropenvpn.local, that's the problem. - Set the Correct Suffix
Type your internal domain suffix. For example, if your domain iscompany.local, typecompany.local(without quotes). Make sure it matches exactly — case doesn't matter. - Order the DNS Servers
Below the suffix field, you'll see a list of DNS server addresses. Make sure your internal DNS server (like192.168.1.10) is at the top. If a public DNS like8.8.8.8is above it, move your internal one up using the arrows on the right. Windows tries DNS servers in order — if public DNS answers first, it won't find the internal domain. - Apply and Close
Click OK on all dialog boxes. Watch the system tray — the network should reconnect without losing connection.
What to Check If It Still Fails
- Flush DNS cache
Open Command Prompt as admin, runipconfig /flushdns. Thenipconfig /registerdns. This forces Windows to re-register with DNS. - Check VPN client settings
In your VPN client (like AnyConnect), look for a setting that says Append client suffix or Use adapter DNS. Uncheck the box that forces its own suffix. Some clients add a second DNS suffix under the adapter's advanced settings. Remove them manually. - Verify DHCP option 015
If your internal DNS suffix comes from DHCP (which it should for non-VPN connections), check that your DHCP server has Option 015 (DNS Domain Name) set tocompany.local. If it's missing, your adapter won't get the suffix automatically, and you'll have to set it manually every time. - Test with nslookup
Runnslookup server.company.local. If it works, try justnslookup server. If that fails, Windows lost the suffix. Re-check steps 4-5. - Reset the adapter
Last resort: go to Settings > Network & Internet > Status > Network reset. This reinstalls network drivers and clears all custom settings. You'll lose saved Wi-Fi passwords and VPN profiles, so only do this if everything else failed.
I've fixed this for about 30 users in the last year. Nine times out of ten, it's the DNS suffix being wrong or missing. The VPN client is the usual suspect — it doesn't clean up after itself. Set the suffix manually once, and it stays until the next VPN session. If you're still stuck, check the event log for Event ID 1014 from DNS Client Events. That'll tell you which DNS server is failing.