split tunnel vs full tunnel: which to troubleshoot first

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.

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

Run the three-way test: problem with VPN on home Wi-Fi, then VPN off on home Wi-Fi, then VPN on phone hotspot. If it works on the hotspot, the home network is the problem. If it fails everywhere with VPN on but works with VPN off, the VPN is the problem.

The error

(Triage; no error. "Everything is slow/broken at home.")

Steps

1. Baseline: disconnect VPN on home Wi-Fi and test the failing thing (or a public site). Expected: result noted. If it fails with VPN off too, it is the home network or the service, not the VPN.
2. VPN on, home Wi-Fi: test again. Expected: result noted. Compare with step 1; a VPN-only failure points at the tunnel.
3. VPN on, phone hotspot: test again. Expected: result noted. Works on hotspot but not home Wi-Fi means the home router or ISP.
4. Measure: run a speed test in each state and note latency to the gateway. Expected: numbers, not adjectives. "Slow" needs a baseline to be actionable.
5. Based on the matrix, route the ticket: home network issue goes to user guidance (reboot router, move closer, check ISP), VPN issue goes to the VPN playbooks. Expected: correct queue.

When to use

• Any remote user connectivity complaint
• "VPN is slow" reports

When not to use

• Office network issues
• Single-app failures unrelated to connectivity

Compatibility

• Any VPN client; the method is universal

Variants

User has no hotspot

Use a neighbor's Wi-Fi or a public network as the alternate path, or skip to the VPN-off baseline.

Everything fails everywhere

Service outage or account issue, not network. Check service status.

Why it happens

Remote users conflate "the internet", "Wi-Fi", and "VPN" into one experience. The three-way test separates the layers so the ticket goes to the right team the first time.

Edge cases

• USB tethering counts as a hotspot test and is more stable than Wi-Fi hotspot.
• Record the matrix in the ticket; the next agent should not re-run it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstkDT8-JIuwkGd-hqrudNHQ

Resolved from the public thread: https://vectle.com/posts/pstkDT8-JIuwkGd-hqrudNHQ

Thread query: how to test if the issue is vpn or the user's home wifi

TL;DR: Run the three-way test: problem with VPN on home Wi-Fi, then VPN off on home Wi-Fi, then VPN on phone hotspot. If it works on the hotspot, the home network is the problem. If it fails everywhere with VPN on but works with VPN off, the VPN is the problem.