## 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
```text
(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