vpn kill switch blocking non-vpn traffic: how to explain and fix

Not specified by the original author.

TL;DR

The kill switch is doing its job: it blocks traffic when the tunnel drops so nothing leaks outside the VPN. If the user needs local network access (printer, LAN), enable the client's split-tunnel or local-LAN exception. If they just need the internet back, reconnect the VPN or disable the kill switch per policy.

The error

(No internet at all after the VPN disconnected. Client shows kill switch active.)

Steps

1. Explain in one sentence: "The kill switch blocks your internet when the VPN drops so your traffic never goes unprotected." Expected: user understands it is a feature, not a bug.
2. First try: reconnect the VPN. Expected: traffic flows. Most kill-switch blocks clear the moment the tunnel is back.
3. If the user needs a local printer or LAN device: enable the client's "allow local network access" / LAN exception setting. Expected: LAN works while the tunnel protects internet traffic.
4. If policy allows, show the user how to temporarily disable the kill switch for trusted networks. Expected: user can self-serve next time. If policy forbids it, say so plainly and offer the reconnect path.
5. Check why the tunnel dropped in the first place (see the drops playbook). Expected: root cause addressed. The kill switch is the symptom; the drop is the disease.

When to use

• Total connectivity loss after VPN drop
• Users confused by kill switch behavior

When not to use

• VPN will not connect at all
• Partial connectivity (some sites work)

Compatibility

• VPN clients with kill switch features (most enterprise clients)

Variants

Kill switch blocks the captive portal

Use the client's portal-bypass if available; otherwise briefly disable per the travel playbook.

User wants it off permanently

That is a policy decision, not a helpdesk call. Escalate the request; do not disable silently.

Why it happens

A kill switch is a firewall rule that only allows tunnel traffic. When the tunnel dies, the rule stays, so everything is blocked. It is working as designed; the design just surprises users.

Edge cases

• Some kill switches persist across reboots; the user must open the client to clear them.
• Document the expected behavior in the VPN FAQ to cut these tickets.

Provenance

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

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

Thread query: vpn kill switch blocking non-vpn traffic: how to explain and fix

TL;DR: The kill switch is doing its job: it blocks traffic when the tunnel drops so nothing leaks outside the VPN. If the user needs local network access (printer, LAN), enable the client's split-tunnel or local-LAN exception. If they just need the internet back, reconnect the VPN or disable the kill switch per policy.

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.