VPN Connected but No Internet on Windows: Routes and Metrics Checklist

Fast diagnosis playbook

When someone pings you with “VPN connected but no internet,” you don’t want a philosophical discussion about tunneling. You want a decision tree that ends
with a fix or an escalatable root cause. Here’s the fast path.

First: confirm what “no internet” actually means

• Can you ping an IP? If ping 1.1.1.1 works but websites don’t, you have a DNS problem, not an internet problem.
• Can you resolve DNS? If nslookup fails or resolves to internal-only answers, it’s DNS server selection, NRPT, or DNS suffix search.
• Can you reach internal resources? If internal works but external doesn’t, you likely have a forced tunnel / default route over VPN with no egress.
• Does everything fail? If both internal and external fail, suspect route selection, interface metric issues, or firewall/WFP blocks.

Second: check default routes and metrics

Most “connected but dead” Windows VPN incidents come down to: the wrong default route (0.0.0.0/0) won, or it won with a metric that seemed “reasonable”
to a computer and insane to a human.

• Inspect routes: route print or Get-NetRoute.
• Identify which interface owns the default route and what metric it has.
• Decide if you want full tunnel (all traffic via VPN) or split tunnel (only corp subnets via VPN).

Third: validate DNS path and policy

• Which DNS servers are in use? Get-DnsClientServerAddress.
• Is NRPT pushing specific domains to VPN DNS? Get-DnsClientNrptPolicy.
• Is the VPN DNS server reachable over the selected route? If not, name resolution dies first.

Fourth: prove the path with tracert and interface binding

• tracert -d 1.1.1.1 shows which gateway you’re actually using.
• Test-NetConnection tells you whether it’s routing, DNS, or port-specific filtering.

Fifth: decide where to fix

If you’re a user: you can adjust metrics, toggle split tunneling options, or fix DNS. If you’re the VPN operator: you need to ship a sane config that does
not hijack default routes without providing egress and DNS.

Your mental model: routes, metrics, DNS, and “connected”

“Connected” means the tunnel is up, not that the internet is reachable

VPN clients report “connected” when the control plane is happy: authentication succeeded, the tunnel interface exists, keys exchanged, keepalives answered.
That’s not the data plane. The data plane is where your packets go to live or die.

Windows will happily accept a VPN adapter, install routes, and then route your traffic into a black hole if those routes point at a gateway that cannot or
should not forward your packets. This is not Windows being dumb; this is Windows being obedient.

Windows picks a route based on prefix length, then metric

Route selection is mostly deterministic:

1. Longest prefix wins. A /32 beats a /24 beats a /0. If your VPN installs specific routes for corporate networks, those should win over your local default route.
2. Then metric wins. If two routes have the same prefix length, Windows uses the lowest route metric, and it factors in interface metric.
3. Then it gets spicy. Windows can consider “automatic metric,” interface speed, and sometimes updates or rebinds can reorder things unexpectedly.

This is why “internet dies when VPN connects” often means: a new 0.0.0.0/0 route arrived via VPN with a lower metric than your Wi‑Fi default route,
but your VPN headend doesn’t provide general internet egress (or blocks it intentionally). Result: full-tunnel without a working exit.

DNS is a separate failure plane, and it fails louder

Humans experience the internet through names, not IPs. DNS issues show up as “no internet” even when routing is fine. Windows adds complexity here:

• Multiple interfaces can have DNS servers; Windows chooses based on interface metrics and suffix policies.
• VPN clients may push internal DNS servers and search suffixes.
• NRPT (Name Resolution Policy Table) can force certain domains (or all domains) to specific DNS servers.
• DNS over HTTPS can bypass your VPN DNS plan and create confusing split-brain behavior.

Split tunneling is a policy decision, not a debugging technique

People toggle split tunneling like it’s “turn it off and on again.” Sometimes it works, but it’s not magic. It changes your routing table and your threat model.
If your security policy requires full tunnel, then “fix” means making full tunnel functional (including internet egress or explicit blocks with user messaging),
not quietly enabling split tunnel because it feels better.

Joke #1: VPN routing is like office politics: the person with the lowest metric wins, and nobody admits who set it.

Facts and history worth knowing (because Windows did not invent chaos)

• PPP and dial-up legacy still matters. Windows’ VPN behavior inherits assumptions from PPP links where “remote network” often meant “use it as default gateway.”
• Split tunneling debates are old. Enterprises argued about it decades ago for dial-up and early IPSec: security wants full tunnel; operations wants predictable egress.
• Automatic metric was meant to help. Windows introduced automatic interface metrics to prefer “faster” links, but virtual adapters can confuse that heuristic.
• NRPT came from DirectAccess-era needs. Microsoft needed a way to resolve corp domains via corp DNS while leaving public domains alone—policy-based DNS routing.
• IPv6 didn’t “break” VPNs; partial adoption did. Many VPNs are IPv4-only, while Windows prefers IPv6 when available; mismatch creates weird partial connectivity.
• DNS suffix search is older than the web. It was designed for enterprise naming, and it’s still responsible for many “why is this resolving wrong?” incidents.
• WFP made filtering more powerful. Windows Filtering Platform allows VPN clients and endpoint agents to enforce network policy; it can also silently block traffic.
• NCSI is not the internet. Windows’ “No internet access” status is based on probes and heuristics; your packets may be fine while the icon complains, or vice versa.

Practical tasks: commands, what the output means, and what you decide

These are the moves that separate “I rebooted” from “I fixed it.” Each task has:
a command, an example of realistic output, what it means, and the decision you make.

Task 1: Confirm interface inventory and status

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,Name | Format-Table -Auto Name,Status,LinkSpeed,InterfaceDescription"
Name                      Status LinkSpeed  InterfaceDescription
Wi-Fi                     Up     866.7 Mbps Intel(R) Wi-Fi 6 AX201 160MHz
Ethernet                  Down   0 bps      Realtek PCIe GbE Family Controller
Wintun Userspace Tunnel   Up     1 Gbps     WireGuard Tunnel
TAP-Windows Adapter V9    Down   0 bps      TAP-Windows Adapter V9

Meaning: You have at least two “Up” adapters: Wi‑Fi and the VPN tunnel.
That’s normal. What matters is which one owns the default route and DNS.

Decision: If the VPN adapter is Down, stop here: you have a tunnel establishment/auth issue, not “no internet.” If it’s Up, continue to routes.

Task 2: Show the routing table in human terms

cr0x@server:~$ powershell -NoProfile -Command "route print"
===========================================================================
Interface List
 12...18 56 80 1a 2b 3c ......Intel(R) Wi-Fi 6 AX201 160MHz
 34...00 ff 12 34 56 78 ......Wintun Userspace Tunnel
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.8.0.1        10.8.0.2       5
          0.0.0.0          0.0.0.0   192.168.1.1    192.168.1.123    25
        10.8.0.0    255.255.255.0         On-link       10.8.0.2     261
     192.168.1.0    255.255.255.0         On-link   192.168.1.123    281
===========================================================================

Meaning: You have two default routes. The VPN default route has metric 5, so it wins. That’s full tunnel now.
If the VPN server doesn’t NAT/egress to the internet, your internet is effectively gone.

Decision: Decide policy: if full tunnel is intended, verify the VPN gateway provides internet egress and allows it. If split tunnel is intended, remove the VPN default route and add only corp routes.

Task 3: Identify the winning default route precisely (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '0.0.0.0/0' | Sort-Object -Property RouteMetric,InterfaceMetric | Format-Table -Auto ifIndex,InterfaceAlias,NextHop,RouteMetric,InterfaceMetric,PolicyStore"
ifIndex InterfaceAlias           NextHop      RouteMetric InterfaceMetric PolicyStore
34      Wintun Userspace Tunnel  10.8.0.1              5             10 ActiveStore
12      Wi-Fi                    192.168.1.1          25             25 ActiveStore

Meaning: The VPN interface (ifIndex 34) is the preferred default route.
InterfaceMetric matters too; Windows sums/compares in ways that still surprise people.

Decision: If you need local internet while VPN is up, you either raise the VPN metrics, disable “use default gateway on remote network,” or configure split tunneling correctly.

Task 4: Confirm your actual egress IP before/after VPN

cr0x@server:~$ powershell -NoProfile -Command "curl.exe -s ifconfig.me; echo"
203.0.113.44

Meaning: That’s your public egress IP. Run it again after connecting VPN. If it changes to a corporate egress range, full tunnel is active and egress works.
If it hangs, your routing sends traffic into a tunnel with no exit.

Decision: If the command hangs only when VPN is connected, focus on default route and VPN egress/NAT policy.

Task 5: Prove whether the issue is DNS or routing (ping IP vs name)

cr0x@server:~$ powershell -NoProfile -Command "ping -n 2 1.1.1.1"
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=17ms TTL=57
Reply from 1.1.1.1: bytes=32 time=16ms TTL=57

Ping statistics for 1.1.1.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),

cr0x@server:~$ powershell -NoProfile -Command "ping -n 2 www.microsoft.com"
Ping request could not find host www.microsoft.com. Please check the name and try again.

Meaning: IP connectivity exists; DNS resolution fails. That’s not “no internet,” that’s “no resolver you can reach” or “policy sends DNS to the wrong place.”

Decision: Stop touching routes for a minute. Inspect DNS servers, NRPT rules, and whether DNS queries are leaving via the expected interface.

Task 6: Inspect DNS servers per interface

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias           ServerAddresses
Wi-Fi                    {192.168.1.1}
Wintun Userspace Tunnel  {10.8.0.53, 10.8.0.54}

Meaning: Wi‑Fi uses the home router DNS. VPN pushes internal resolvers. Depending on policy, Windows might prefer VPN DNS for everything,
or use smart multi-homing behavior that is not always smart.

Decision: If VPN DNS is internal-only and you’re full-tunneling without egress, public names fail. Either provide egress, or configure DNS split (NRPT) so public names go to public resolvers.

Task 7: Check NRPT policies (domain-based DNS routing)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Select-Object -First 5 | Format-List"
NameSpace : .corp.example
NameServers : 10.8.0.53,10.8.0.54
DirectAccessDnsServers :
DnsSecValidationRequired : False
Comment : VPN policy

NameSpace : .
NameServers : 10.8.0.53

Meaning: If you see a rule for NameSpace : ., that’s “all domains.” It forces all DNS queries to the VPN resolver.
That can be correct for full tunnel; it’s awful for split tunnel if the VPN DNS cannot resolve public domains or is unreachable.

Decision: If split tunnel is intended, remove the catch-all NRPT rule and keep only corp namespaces.

Task 8: Validate DNS resolution explicitly and see which server answers

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName www.microsoft.com -Type A | Select-Object -First 3"
Name                                     Type TTL   Section IPAddress
----                                     ---- ---   ------- ---------
www.microsoft.com                        A    20    Answer  184.25.56.101

cr0x@server:~$ powershell -NoProfile -Command "nslookup www.microsoft.com 10.8.0.53"
Server:  vpn-dns-1
Address:  10.8.0.53

*** vpn-dns-1 can't find www.microsoft.com: Non-existent domain

Meaning: The internal DNS server doesn’t resolve public domains (by design or misconfig). If Windows is sending all DNS there, browsing dies.

Decision: Either configure the VPN DNS to forward public queries, or stop forcing public DNS to go through it.

Task 9: Prove which path your packets take (tracert without DNS)

cr0x@server:~$ powershell -NoProfile -Command "tracert -d 1.1.1.1"
Tracing route to 1.1.1.1 over a maximum of 30 hops

  1    35 ms    34 ms    36 ms  10.8.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.

Trace complete.

Meaning: Hop 1 is the VPN gateway, and then nothing. That’s classic “default route over VPN, but VPN doesn’t forward to the internet”
(or it blocks ICMP beyond the gateway, but you’ll usually see failures for TCP too).

Decision: Confirm whether the VPN is intended to provide internet egress. If not, remove the default route and run split tunnel.

Task 10: Test TCP connectivity to a known endpoint and capture which interface is used

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 8.8.8.8 -Port 53 -InformationLevel Detailed"
ComputerName           : 8.8.8.8
RemoteAddress          : 8.8.8.8
RemotePort             : 53
InterfaceAlias         : Wintun Userspace Tunnel
SourceAddress          : 10.8.0.2
TcpTestSucceeded       : False
PingSucceeded          : True

Meaning: ICMP ping works but TCP/53 fails. That can be policy on the VPN (blocking outbound), a stateful firewall issue, or MTU/fragmentation problems.

Decision: If the interface is the VPN tunnel and outbound ports are blocked, you need a VPN policy change (or split tunnel) rather than client-side fiddling.

Task 11: Check the MTU on the VPN interface (silent killer)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object -Property InterfaceAlias | Format-Table -Auto InterfaceAlias,NlMtu,InterfaceMetric,Dhcp"
InterfaceAlias           NlMtu InterfaceMetric Dhcp
Wi-Fi                    1500              25 Enabled
Wintun Userspace Tunnel  1420              10 Disabled

Meaning: MTU 1420 is common for WireGuard; IPSec and some SSL VPNs go lower. If MTU is wrong, you get “some sites work, some hang,”
especially HTTPS with larger packets.

Decision: If symptoms are partial (small pings work; large transfers hang), test with smaller MTU or clamp MSS on the VPN side.

Task 12: Confirm IPv6 routes and whether IPv6 is stealing traffic

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv6 -DestinationPrefix '::/0' | Format-Table -Auto InterfaceAlias,NextHop,RouteMetric,InterfaceMetric"
InterfaceAlias           NextHop              RouteMetric InterfaceMetric
Wi-Fi                    fe80::1                     10             25
Wintun Userspace Tunnel  ::                          256             10

Meaning: IPv6 default route via Wi‑Fi exists and is preferred. If your “no internet” happens only for some apps, they might be trying IPv6 first.
Meanwhile the VPN is IPv4-only and your corporate DNS might return AAAA records that fail.

Decision: If corporate access breaks because clients prefer IPv6 that doesn’t traverse the VPN, either provide IPv6 over the VPN, or control DNS answers / disable IPv6 on the tunnel design (not as a reflex).

Task 13: Inspect WinHTTP proxy settings (yes, still)

cr0x@server:~$ powershell -NoProfile -Command "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.8.0.20:8080
    Bypass List     : (none)

Meaning: Some corporate VPN post-connect scripts set a proxy. If that proxy is only reachable over VPN and your VPN routing is broken, browsers may fail in confusing ways.
Some apps use WinHTTP; others use WinINET; they can disagree.

Decision: If internet is dead only for certain apps (or only system services), fix proxy reachability or clear WinHTTP proxy if it’s stale.

Task 14: Check the Windows “use default gateway on remote network” setting (RAS/VPN)

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -AllUserConnection | Select-Object Name,SplitTunneling,RememberCredential | Format-Table -Auto"
Name              SplitTunneling RememberCredential
----              -------------- ------------------
Corp-VPN          False          True

Meaning: SplitTunneling False generally implies full tunnel (default route over VPN). That’s fine if your VPN is built for it.
It’s a disaster if the headend is “internal only.”

Decision: Change it only if policy allows. If you’re an operator, fix the VPN profile and distribution method rather than telling users to toggle it manually.

Task 15: Adjust interface metric (surgical, but sometimes necessary)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'Wi-Fi' -InterfaceMetric 10; Set-NetIPInterface -InterfaceAlias 'Wintun Userspace Tunnel' -InterfaceMetric 50"

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Where-Object {$_.InterfaceAlias -in @('Wi-Fi','Wintun Userspace Tunnel')} | Format-Table -Auto InterfaceAlias,InterfaceMetric"
InterfaceAlias           InterfaceMetric
Wi-Fi                                10
Wintun Userspace Tunnel              50

Meaning: You told Windows to prefer Wi‑Fi when routes compete.
This is a blunt tool and can violate full-tunnel policy if you’re not careful.

Decision: Use metrics to fix route priority conflicts, not to “defeat security.” If your enterprise requires full tunnel, do not ship “metric hacks” as a support play.

Task 16: Add a specific split-tunnel route (example for corp subnet)

cr0x@server:~$ powershell -NoProfile -Command "New-NetRoute -DestinationPrefix '10.20.0.0/16' -InterfaceAlias 'Wintun Userspace Tunnel' -NextHop '0.0.0.0' -RouteMetric 5"

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -DestinationPrefix '10.20.0.0/16' | Format-Table -Auto DestinationPrefix,InterfaceAlias,NextHop,RouteMetric"
DestinationPrefix InterfaceAlias           NextHop  RouteMetric
10.20.0.0/16       Wintun Userspace Tunnel  0.0.0.0          5

Meaning: You’re explicitly routing only the corporate subnet into the tunnel.
For many VPN technologies, “on-link” next hop (0.0.0.0) is correct because the tunnel interface itself is the path.

Decision: If the VPN client doesn’t manage routes reliably, you can pin critical routes. But prefer fixing the pushed configuration centrally; drift is how future you gets paged.

Task 17: Check active connections and bound source addresses

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Established | Select-Object -First 5 LocalAddress,LocalPort,RemoteAddress,RemotePort,OwningProcess | Format-Table -Auto"
LocalAddress    LocalPort RemoteAddress   RemotePort OwningProcess
10.8.0.2        50214     10.8.0.53       53         1240
192.168.1.123   50215     93.184.216.34   443        8916
192.168.1.123   50216     142.250.72.14   443        8916

Meaning: You have simultaneous connections sourced from both VPN and Wi‑Fi. That can be normal with split tunnel. It can also break apps that assume a single stable source IP.

Decision: If a specific app fails while others work, it might be sensitive to source IP changes. Route that app’s destinations explicitly, or use full tunnel consistently.

Task 18: Verify Windows firewall profile and whether VPN flipped you into “Public” with strict rules

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table -Auto Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name          InterfaceAlias           NetworkCategory IPv4Connectivity
HomeNetwork   Wi-Fi                    Private         Internet
Corp-VPN      Wintun Userspace Tunnel  Public          LocalNetwork

Meaning: The VPN network category is Public and only shows LocalNetwork connectivity. Some endpoint policies apply harsher firewall rules on Public networks,
and some VPN clients mis-tag the profile.

Decision: If traffic is blocked only when VPN is up and routes look correct, inspect firewall/WFP policies and profile tagging rather than changing routes randomly.

Joke #2: Routing tables are the only place where “lowest number wins” is a policy you can enforce without HR getting involved.

One quote worth keeping on your desk

“Hope is not a strategy.” — James Cameron

It applies uncomfortably well to VPN troubleshooting: don’t hope the packets went where you wanted; prove where they went.

Common mistakes: symptom → root cause → fix

This section is deliberately specific. If your symptom isn’t here, it’s either a rarer issue or a different layer (auth, endpoint security, ISP).

1) “VPN connects, internal sites work, public internet dies”

• Root cause: Full tunnel default route installed via VPN, but VPN egress/NAT to internet is disabled or blocked.
• Fix: Either (a) enable egress on the VPN gateway (NAT + firewall policy + logging), or (b) remove the VPN default route and use split tunneling with explicit corp prefixes.

2) “Public IP ping works, websites don’t load”

• Root cause: DNS queries are sent to an unreachable DNS server or to an internal DNS server that does not forward public domains.
• Fix: Adjust DNS server ordering, remove catch-all NRPT, or configure the internal resolver to forward/resolve public domains; ensure DNS server routes exist.

3) “Some sites load, others hang forever (especially HTTPS)”

• Root cause: MTU/MSS issues across the tunnel (fragmentation blocked, PMTUD blackhole), or selective firewall blocks.
• Fix: Lower tunnel MTU, clamp MSS on VPN gateway, verify ICMP fragmentation-needed behavior, or adjust firewall policy for outbound TCP.

4) “VPN works on Wi‑Fi but not on Ethernet (or vice versa)”

• Root cause: Interface metric differences cause different default route selection; corporate LAN uses different DHCP options or proxy settings; VLAN policies differ.
• Fix: Compare Get-NetRoute outputs per environment; set explicit metrics if needed; ensure VPN routes don’t collide with local subnets.

5) “VPN says connected, but DNS returns weird internal IPs for public names”

• Root cause: Split-brain DNS or internal DNS hijacking (intentional or accidental), sometimes via NRPT “.” rule.
• Fix: Limit NRPT to corporate namespaces; ensure internal DNS does not override public zones unless you really mean it (and have a plan).

6) “Internet dies only for one app (Teams, Outlook, browser, package manager)”

• Root cause: Proxy settings (WinHTTP vs WinINET), app uses IPv6 first, or app pins to a specific interface and doesn’t like source IP changes.
• Fix: Check netsh winhttp show proxy, verify IPv6 routing, and test with Test-NetConnection

7) “VPN connects, but you can’t reach internal or external; route table looks fine”

• Root cause: WFP/firewall blocks, endpoint security interfering, or the tunnel is up but no data plane (wrong keys, wrong allowed IPs, wrong SA selectors).
• Fix: Validate with Test-NetConnection to internal IPs; check firewall profile; for WireGuard verify AllowedIPs; for IPSec verify traffic selectors.

8) “After disconnecting VPN, internet still broken until reboot”

• Root cause: Stale routes, stale DNS server addresses, or stale proxy settings left behind by the VPN client.
• Fix: Remove persistent routes, reset DNS to DHCP, clear WinHTTP proxy, or restart the network stack (less dramatic than a full reboot).

Checklists / step-by-step plan

Checklist A: The 5-minute “is it routing or DNS?” triage

1. Run ping 1.1.1.1. If it fails, you likely have routing/firewall issues.
2. Run ping www.microsoft.com. If IP ping works but name ping fails, focus on DNS.
3. Run route print and identify the winning 0.0.0.0/0 route.
4. Run Get-DnsClientServerAddress and confirm DNS servers are reachable on the selected path.
5. Run tracert -d 1.1.1.1 to see whether traffic exits via VPN gateway or local router.

Checklist B: Full tunnel sanity (for operators and on-call)

If your org requires full tunnel, embrace it and make it work. Half-full tunnel is where incidents breed.

1. Confirm the VPN pushes a default route with the intended metric.
2. Confirm VPN gateway provides internet egress (NAT) and has firewall rules that allow outbound traffic as policy dictates.
3. Confirm DNS servers pushed over VPN can resolve both internal zones and public domains (either directly or via forwarding).
4. Confirm MTU/MSS tuning for the tunnel type to avoid blackholing large packets.
5. Log egress drops at the VPN gateway. If you can’t see drops, you will argue with ghosts.
6. Test IPv6 posture: either support it end-to-end or deliberately constrain it so clients don’t choose a dead path.

Checklist C: Split tunnel sanity (for people who like predictable networks)

1. Do not push 0.0.0.0/0 over VPN. Push only corporate prefixes.
2. Avoid overlapping address space with home networks (192.168.0.0/16 collisions are real). If you can’t avoid it, use NAT on the client or redesign corp subnets.
3. Use NRPT for corporate namespaces only, not for . unless you’re deliberately forcing all DNS.
4. Ensure corporate DNS servers are reachable via the tunnel routes (obvious, but routinely missed).
5. Be consistent about proxy policy: either proxy via VPN for internal apps, or don’t. Mixed signals cause mixed outages.
6. Document which traffic must go through VPN (source control, CI/CD, internal artifact repos) and add those prefixes/routes explicitly.

Checklist D: Client-side “get me unstuck without breaking policy” actions

1. Disconnect and reconnect VPN once (yes, once). If the route table changes each time, that’s a bug to report.
2. Flush DNS cache (ipconfig /flushdns) after DNS policy changes.
3. Reacquire DHCP on the physical interface (ipconfig /renew) if local routing looks wrong.
4. Check and clear stale WinHTTP proxy if it’s obviously wrong (netsh winhttp reset proxy)—but only if your environment doesn’t require it.
5. Gather evidence before escalating: routing table, DNS servers, NRPT policies, and a couple of failing tests with timestamps.

Useful “evidence bundle” command set (copy/paste for escalations)

cr0x@server:~$ powershell -NoProfile -Command "Get-Date; hostname; Get-NetAdapter | ? Status -eq 'Up' | ft -Auto Name,ifIndex,LinkSpeed; Get-NetRoute -DestinationPrefix '0.0.0.0/0' | ft -Auto; Get-DnsClientServerAddress -AddressFamily IPv4 | ft -Auto; Get-DnsClientNrptPolicy | ft -Auto NameSpace,NameServers; Test-NetConnection 1.1.1.1 -InformationLevel Detailed; Resolve-DnsName www.microsoft.com -ErrorAction SilentlyContinue"

Meaning: This captures time, interfaces up, default routes, DNS configuration, NRPT, basic connectivity, and a DNS resolution attempt.
It’s the difference between an escalation and a cry for help.

Decision: If you can’t fix locally, send this bundle to the VPN/network team. They’ll still ask one more question, but at least it won’t be “what’s your routing table?”

Three corporate mini-stories (anonymized, plausible, and technically annoying)

Mini-story 1: The incident caused by a wrong assumption

A mid-size company rolled out a new VPN profile for contractors. The idea was simple: contractors should only reach a couple of internal web apps.
The VPN concentrator was configured for internal routing only—no internet egress, no NAT, tight outbound ACLs. Security signed off. Everyone felt responsible.

The wrong assumption showed up as a helpdesk flood: “VPN connects but no internet.” The helpdesk interpreted it as an ISP issue because it started around the same time
every morning. In reality, it started when people opened their laptops, connected VPN, and then tried to use MFA flows hosted on public domains.
Their browsers couldn’t resolve or reach external identity endpoints because the VPN pushed a default route.

The VPN team insisted they never intended to tunnel internet. The endpoint team insisted they never intended to change default routes. Both were right, and both were
missing the third actor: the profile template they cloned had “send all traffic” enabled by default, because it came from an older full-tunnel deployment.

The fix wasn’t heroic. They removed the default route from the contractor profile, pushed explicit corp prefixes for the two applications, and added an NRPT rule
for the corporate domain only. The next day, the helpdesk queue went quiet. Then someone asked why it took three days. The answer was, painfully, “because nobody looked at route print.”

Mini-story 2: The optimization that backfired

An enterprise IT team wanted faster VPN performance, so they tuned interface metrics to prefer the VPN adapter aggressively. Lower metric, higher priority, less ambiguity.
It worked in their lab and on their corporate Wi‑Fi. The graphs looked better. They shipped the change.

Then remote employees on flaky home networks started reporting intermittent “connected but no internet” and “some sites hang” issues. The VPN adapter now won routing
decisions even when the tunnel was up but degraded. Meanwhile, Wi‑Fi still had a healthy default route that could have carried public traffic during VPN brownouts.
But metrics had been “optimized” to remove that fallback.

The nasty part: the tunnel’s control plane remained stable enough to show “Connected,” while the data plane suffered from MTU blackholing and packet loss.
So users kept their VPN up and blamed “the internet.” In reality, their routing was locked into a subpar path with no graceful fallback.

The rollback improved things immediately. The long-term fix was more grown-up: keep full tunnel for managed devices that need it, but add health checks and better MTU tuning;
and for split-tunnel populations, avoid forcing VPN default routes via metric hacks. Optimizing the metric was a local win that became a global outage.

Mini-story 3: The boring but correct practice that saved the day

A financial services company had a VPN environment that everyone called “old,” which in corporate language means “stable but unfashionable.” Their secret wasn’t magic hardware.
It was operational discipline: every VPN profile change required a before/after capture of routes, DNS servers, NRPT rules, and a scripted set of tests from a clean Windows VM.

One Tuesday, a certificate rotation coincided with a client update. Users started reporting browsing failures after connecting VPN. The VPN gateways looked fine.
Authentication was fine. The tunnel was up. The classic trap.

Because they had the boring practice, the on-call engineer compared the before/after evidence bundles and spotted that the new client update had introduced an NRPT catch-all rule
for ., forcing all DNS to internal resolvers. The internal resolvers were reachable, but they were configured not to forward public domains—again, by policy.

They didn’t “try random stuff.” They removed the catch-all rule in the profile, kept NRPT for internal namespaces, and pushed the corrected configuration.
The incident was contained quickly. Nobody wrote a heroic post. That’s the point: boring practices prevent exciting outages.

FAQ

1) Why does Windows say “Connected” if I can’t load any websites?

Because the VPN client’s control plane is connected. Your routes and DNS settings can still be wrong, and Windows won’t call that “disconnected.”
Think of it as “tunnel established,” not “packets delivered.”

2) What’s the single most common cause of “VPN connected but no internet”?

A default route (0.0.0.0/0) being preferred via the VPN when the VPN gateway does not provide internet egress (or blocks it).
That’s routing + policy mismatch, not a mystery.

3) How do I tell if it’s DNS vs routing?

Ping an IP (like 1.1.1.1) and then ping a name (like www.microsoft.com). If IP works and name fails, it’s DNS.
If both fail, it’s routing/firewall or the tunnel data plane.

4) Should I just enable split tunneling to fix it?

Only if your security policy allows it and your VPN is designed for split tunneling. Otherwise you’re “fixing” by changing the policy.
The right fix for full tunnel is making full tunnel functional: egress, DNS forwarding, MTU tuning, and clear firewall policy.

5) Why do I have two default routes, and why does that matter?

You can have multiple default routes (Wi‑Fi and VPN). Windows chooses based on metrics. The lower metric wins, and your traffic follows it.
If the winner is a dead-end, your internet follows it into the void.

6) What is NRPT and why does it break browsing?

NRPT is Windows’ domain-based DNS routing policy. If a policy forces all domains to VPN DNS (a rule for .),
and that DNS server can’t resolve public domains or isn’t reachable, web browsing fails even if IP routing is fine.

7) Why does disconnecting the VPN sometimes not restore the internet?

Some VPN clients leave behind stale routes, DNS settings, or proxy configuration. Windows will keep using them until they’re removed or overridden.
Check persistent routes and DNS server lists, and reset stale proxy settings if needed.

8) Could IPv6 be the culprit?

Yes. Windows prefers IPv6 when it can. If your VPN doesn’t carry IPv6 but DNS returns AAAA records for internal or external services,
some apps will try IPv6 first and appear broken. Verify IPv6 default routes and whether the VPN design supports IPv6 intentionally.

9) Is changing interface metric a good long-term solution?

It’s a tool, not a strategy. Metrics can resolve route tie-breaks, but using them to override a misdesigned VPN profile creates drift across machines.
Prefer fixing the VPN’s pushed routes and DNS policies centrally.

10) What evidence should I send to the VPN team?

Default routes and metrics, DNS servers, NRPT policies, and a couple of failing tests (Test-NetConnection and Resolve-DnsName).
Include timestamps and whether the issue happens only on certain networks (home Wi‑Fi, tethering, hotel).

Conclusion: next steps that prevent reruns

“Connected but no internet” is rarely random. It’s usually one of three things: the wrong default route won, DNS got forced somewhere unhelpful, or the tunnel is up but the data path is broken
(often MTU/firewall). You don’t fix it by guessing. You fix it by reading the routing table like it’s a log file.

Practical next steps:

1. Run the 5-minute triage: IP ping vs name ping, then default route ownership.
2. Decide full tunnel vs split tunnel and align routes + DNS policy with that decision.
3. If you operate the VPN: stop shipping profiles that install a default route without providing egress and DNS that can resolve what users need.
4. Standardize an “evidence bundle” command set and require it for escalations. Not because you’re mean—because it reduces outage time.

The win isn’t just getting one laptop back online. It’s making the next incident boring enough that nobody remembers it happened.