DEV Community

Bryz︱🦾
Bryz︱🦾

Posted on

🚨 VPN Is Connected… but Internal Apps Still Fail? Check DNS First

#itsupport #windows #networking #beginners

You've heard this ticket all week:

"VPN is green. I still can't open the intranet / file share / internal app."

The instinct is to reinstall the VPN client or blame the app. Pause. A lot of the time the tunnel is up, but name resolution is still pointing at the public internet. 😤

Here's the fast help-desk path that separates DNS problems from real network problems.

🔍 Step 1: Prove the VPN adapter and its DNS servers

Open Command Prompt and run:

ipconfig /all
Enter fullscreen mode Exit fullscreen mode

Find the VPN adapter (names vary: "Ethernet 2", "WAN Miniport", "Cisco AnyConnect", "GlobalProtect", etc.). Check:

  • IPv4 Address — do you have an address on the tunnel?
  • DNS Servers — are they your company's internal resolvers?

If DNS still shows only a public resolver (or nothing useful) while the VPN claims Connected, internal short names and .local / corporate zones often fail. That's your first smoking gun. 💡

🌐 Step 2: Test resolution, then flush the cache

Pick a real internal hostname your user should reach (intranet, file server, app URL host):

nslookup intranet.company.local
Enter fullscreen mode Exit fullscreen mode

What you're looking for:

  • Fails / NXDOMAIN / times out → DNS path is wrong or the VPN isn't feeding corporate DNS.
  • Resolves to an unexpected public IP → classic split-brain / wrong resolver issue.
  • Resolves to the expected internal IP → DNS is fine; move to connectivity.

Clear the local cache and retry once:

ipconfig /flushdns
nslookup intranet.company.local
Enter fullscreen mode Exit fullscreen mode

If it only works after a full VPN disconnect + reconnect, note that in the ticket. Stale DNS on reconnect is a common client quirk.

⚡ Step 3: Separate DNS from "can I reach the port?"

Once the name resolves, prove the path with PowerShell:

Test-NetConnection intranet.company.local -Port 443
Enter fullscreen mode Exit fullscreen mode

Use the real port the app needs (445 for SMB, 3389 for RDP, 443 for most web apps).

How to read it:

Result Likely cause
DNS fails Wrong/missing VPN DNS, cache, or split-tunnel DNS
DNS OK, TcpTestSucceeded : False Firewall, VPN profile, split tunnel, or routing
DNS OK, port OK, app still fails App config, auth, proxy, or cached credentials

That one table keeps you from reinstalling Outlook when the real issue was DNS. 💪

🧰 Bonus checks that close tickets faster

  • Split tunnel: some VPN profiles only send selected routes. Internal DNS may work while a specific subnet does not — capture the destination IP from nslookup and ask whether that range is in the VPN route list.
  • Hosts file leftovers: rare, but C:\Windows\System32\drivers\etc\hosts can pin an old IP. Check before you escalate.
  • Browser vs system DNS: if nslookup works but the browser fails, try InPrivate and another browser before you chase VPN again.
  • Mapped drives / SMB: after DNS is healthy, Test-NetConnection fileserver -Port 445 beats remapping blindly.

🙌 Why this order matters

Help desk wins come from narrowing the layer:

  1. Is the VPN adapter really up?
  2. Is corporate DNS in play?
  3. Does the name resolve?
  4. Does the port answer?

When you follow that order, you stop guessing and start proving. Users get back to work faster, and you escalate with evidence instead of "VPN is weird." 🚀

What's the first thing you check when VPN says Connected but nothing internal loads? Drop your go-to below 👇

Top comments (0)