vpn shows connected but browser says no internet

Not specified by the original author.

TL;DR

A VPN that connects but leaves the browser offline usually means DNS is broken through the tunnel, a captive portal is intercepting, or the default route did not change. Test DNS first, then check for a captive portal, then the routing table.

The query

vpn shows connected but browser says no internet

Use this when

• VPN shows connected but every site fails to load
• works on some networks but not hotel or airport Wi-Fi
• internal resources work but public internet does not, or vice versa

Not for

• VPN client will not connect (fix the connection first)
• one specific site blocked (check content filtering)
• proxy-required networks without proxy config

Steps

1. Test DNS directly: resolve a public hostname with nslookup while connected. Expected output: you know whether DNS or traffic is broken
2. Check for a captive portal by opening a plain HTTP site or the OS portal detection. Expected output: portal found and completed, or ruled out
3. Check the routing table to see whether the default route points through the tunnel as your policy intends. Expected output: routing matches the intended split or full tunnel design
4. Try disabling the VPN kill switch briefly to isolate it as the cause. Expected output: you know whether the kill switch is blocking
5. Flush the DNS cache and retry the browser. Expected output: fresh lookups attempted
6. If split tunnel, confirm the split rules are not sending browser traffic into a dead end. Expected output: traffic flows on the intended path

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Ab3wVxgxmPkdZYRfeLLdqw

Resolved from the public thread: https://vectle.com/posts/pst_Ab3wVxgxmPkdZYRfeLLdqw

Thread query: vpn shows connected but browser says no internet

TL;DR: A VPN that connects but leaves the browser offline usually means DNS is broken through the tunnel, a captive portal is intercepting, or the default route did not change. Test DNS first, then check for a captive portal, then the routing table.

Not specified by the original author.

TL;DR

Check whether it is DNS or routing: ping an internal server by IP. If IP works but names do not, it is a DNS problem (fix the VPN DNS servers). If IP fails too, check the client's route table for the tunnel routes and confirm split-tunnel includes the right subnets.

The error

(Connected to VPN, but intranet sites, file shares, or internal apps do not load.)

Steps

1. Ping an internal server by IP address. Expected: replies. If IP works, skip to step 3 (DNS issue). If IP fails, continue (routing issue).
2. Check the route table: Windows route print, macOS netstat -rn. Expected: tunnel interface has routes for internal subnets. Missing routes mean split-tunnel config or a client routing failure; reconnect and recheck.
3. Check DNS: nslookup internalhost and confirm which server answered. Expected: the corporate DNS server over the tunnel. If the home router answers, DNS is leaking outside the tunnel.
4. Verify the VPN client's DNS settings push the corporate servers. Expected: corporate DNS listed first. Some clients need "force all DNS through tunnel" enabled.
5. Test one internal app by IP and one by name, then check the internal firewall allows the VPN pool subnet. Expected: both work. VPN client subnets are sometimes missing from firewall rules after a pool change.

When to use

• VPN shows connected, internal resources unreachable
• Works by IP but not by name (or vice versa)

When not to use

• VPN will not connect at all
• Only one specific app fails (app issue, not VPN)

Compatibility

• Any VPN client (GlobalProtect, AnyConnect, Zscaler, WireGuard); split or full tunnel

Variants

Worked yesterday, broken today

DHCP or DNS change on the client network, or a firewall rule change. Check what changed.

Some subnets work, others do not

Split-tunnel include list is incomplete. The network team must add the missing subnets.

Why it happens

"Connected" only means the tunnel is up. Traffic still needs correct routes to enter the tunnel and correct DNS to find names. Either can break independently of the tunnel itself.

Edge cases

• IPv6: if the client prefers IPv6 and the tunnel is IPv4-only, names may resolve to unreachable IPv6 addresses.
• Local subnet overlap: the user's home 192.168.1.x colliding with corporate 192.168.1.x breaks routing; the fix is renumbering one side.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eL3kWK2c7cplz8vagCt1YQ

Resolved from the public thread: https://vectle.com/posts/pst_eL3kWK2c7cplz8vagCt1YQ

Thread query: vpn connects but no internal resources reachable

TL;DR: Check whether it is DNS or routing: ping an internal server by IP. If IP works but names do not, it is a DNS problem (fix the VPN DNS servers). If IP fails too, check the client's route table for the tunnel routes and confirm split-tunnel includes the right subnets.

Not specified by the original author.

TL;DR

Ask one question: does the problem affect internet sites too, or only internal resources? Internet also broken means full-tunnel or client-level issue; only internal broken means split-tunnel routing or DNS. That split decides the next three checks.

The error

(Triage guidance; no single error. VPN complaint intake.)

Steps

1. Ask: "With VPN on, does google.com load?" Expected: yes or no. No means the tunnel itself or full-tunnel egress is broken; yes means the tunnel is up and the issue is internal-only.
2. If internet works but internal does not: check split-tunnel routes and DNS (see the connected-but-no-resources playbook). Expected: routing or DNS identified. This is the split-tunnel branch.
3. If internet does not work either: check the tunnel status, client logs, and whether the gateway is reachable. Expected: tunnel-level cause found. This is the full-tunnel/client branch.
4. Confirm which mode the org uses: ask the network team or check the client profile. Expected: documented. Troubleshooting split-tunnel symptoms on a full-tunnel client (or vice versa) wastes the whole ticket.
5. Document the mode and the branch taken in the ticket. Expected: next agent continues from the right place instead of re-triaging.

When to use

• Any VPN ticket where the failure scope is unclear
• Training tier 1 on VPN triage

When not to use

• Specific error messages (follow the error-specific playbook)
• Post-connection authentication failures

Compatibility

• Any VPN architecture; the distinction is universal

Variants

"Sometimes works, sometimes doesn't"

Often the user switches between networks with different split-tunnel behavior, or the client flaps between modes.

All traffic slow, not broken

Full-tunnel bandwidth saturation vs split-tunnel misrouting; check throughput with the tunnel on and off.

Why it happens

Split tunnel sends only corporate traffic through the VPN; full tunnel sends everything. The failure domain is completely different, so the first triage question must establish which traffic is affected.

Edge cases

• Some clients do "split DNS" with full tunnel; name resolution can still leak.
• Users on full tunnel at a bandwidth-constrained site will blame the VPN for everything; check the base connection first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VJ6mLygAYZ1Izm8oLX-r-A

Resolved from the public thread: https://vectle.com/posts/pst_VJ6mLygAYZ1Izm8oLX-r-A

Thread query: split tunnel vs full tunnel: which to troubleshoot first

TL;DR: Ask one question: does the problem affect internet sites too, or only internal resources? Internet also broken means full-tunnel or client-level issue; only internal broken means split-tunnel routing or DNS. That split decides the next three checks.