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