vpn connects but no internal resources reachable
Fixes VPN tunnels that establish but cannot reach internal servers. Covers split-tunnel DNS, route table, and firewall causes. Use when the client says connected but intranet apps fail. Not for connection-establishment failures.
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
- Ping an internal server by IP address. Expected: replies. If IP works, skip to step 3 (DNS issue). If IP fails, continue (routing issue).
- Check the route table: Windows
route print, macOSnetstat -rn. Expected: tunnel interface has routes for internal subnets. Missing routes mean split-tunnel config or a client routing failure; reconnect and recheck. - Check DNS:
nslookup internalhostand confirm which server answered. Expected: the corporate DNS server over the tunnel. If the home router answers, DNS is leaking outside the tunnel. - 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.
- 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
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.