A Windows 11 VPN connects but work resources fail: test routing safely

A Connected badge on a VPN means the client established a session, not that every work file share and internal name is reachable. Work VPNs can use split tunneling, organization DNS and access policy. Installing another VPN or changing the route table by guess can break security controls. A good test compares one approved internal resource, one public site and the state before and after connection, then hands useful evidence to IT.

Before you start​

Record the VPN provider, profile name, error and target resource without sharing credentials. Keep an offline way to contact support. If the machine is managed, follow its support instructions and do not disable required endpoint security or corporate proxy settings. Confirm the target app works for colleagues before assuming your PC is the cause.

Do it step by step​

1. Verify ordinary internet connectivity before connecting the VPN. Open two public sites and note whether the local network itself is stable.
2. Connect through Windows Settings > Network & internet > VPN or the organization's approved client. Record connection time, displayed profile and any authentication prompt.
3. Test a specific approved internal hostname and resource, then a public site. Note whether the internal name resolves, whether the app reaches its server, and whether both fail only after connection.
4. Use `ipconfig /all` and `nslookup` to record the active DNS servers and response for the internal hostname. Do not paste private addresses or hostnames into public forums. Compare with the organization's documented expected state.
5. Check whether the VPN profile requires a proxy or certificate; Microsoft notes a VPN-specific proxy is configured separately. Ask IT before changing split-tunnel, firewall or route settings.
6. Disconnect, test the public site again and reconnect once. Send IT the timestamps, VPN profile, exact error and comparison results. Keep the security policy intact while they diagnose.

Check the result​

The approved internal resource works through the VPN while ordinary internet behavior matches the organization's design. The test identifies whether the tunnel, DNS or individual service was the failure point.

If something goes wrong​

If public sites fail only while the VPN is on, that may be intentional full-tunnel policy, not a bug. If the internal target fails for all users, the server may be down. A personal VPN service is not a substitute for the employer's access profile.

Know the limit​

VPN configuration varies by organization and Windows 11 SE lacks the built-in feature. Do not publish internal network details or bypass enterprise controls to satisfy a generic guide. Microsoft VPN setup Proxy settings

Decision checkpoint​

Ask IT whether the VPN is designed to carry all traffic or only internal routes. A public website continuing to use the local connection may be expected split-tunnel behavior; a public website losing access can be an intended full-tunnel control. The exact route and policy matter more than a generic 'VPN connected' label. Include a fresh sign-in test, because an expired account token can imitate a routing failure.