JUMP TO SECTIONChoose a lesson section
Learn to reason across the whole path.
Instead of memorizing “VPN fixes,” build an accurate mental model of what the client is actually doing. By the end of this guide, you should be able to:
Distinguish the public underlay from the encrypted VPN tunnel and the private network behind it.
Explain how VPN authentication, encryption, routing, DNS and authorization solve different problems.
Predict whether a packet uses the VPN or local network under split and full tunneling.
Investigate why an established VPN tunnel might still leave an internal application unreachable.
One network carries another.
Your laptop starts with a normal physical network connection—home Wi-Fi, a hotel Ethernet link, or mobile data. That's the underlay. A VPN client establishes a protected session to a gateway across that network. The logical tunnel is the overlay; protected traffic is encapsulated for transport across the underlay.
The gateway's public address is reached through the ordinary internet route—the VPN doesn't magically bypass your ISP. After the tunnel is established, selected destination traffic is carried through it. The VPN may assign a virtual IP, but that does not guarantee permission to reach every internal subnet.
Encryption protects traffic in transit. Identity checks establish who is connecting. Firewall and application rules still decide which resources that identity may reach. A VPN isn't a replacement for least privilege.
Not every VPN builds its tunnel the same way.
One device → Organization
A client authenticates to a VPN service and receives routes, name-resolution settings and access policy. It may use a TLS-based or IPsec-based solution, depending on the platform.
Network → Network
Gateways establish a protected path between sites, often using IPsec. Individual endpoints may not run VPN clients; the edge devices handle encapsulation and routing.
Network-layer protection
IKEv2 negotiates/authenticates security associations and keys; ESP carries protected IP traffic. Common NAT traversal uses UDP 4500, and IKE typically starts on UDP 500.
Transport-oriented remote access
Many products establish secure remote access over TLS, sometimes with separate data transport and vendor-specific behavior. “SSL VPN” is a common product label; obsolete SSL versions aren't a recommendation.
Modern products also use protocols such as WireGuard, which has its own handshake and cryptographic design. Don't assume every VPN uses TCP 443, UDP 500/4500, or the same kind of tunnel. Confirm the actual deployed product and approved profile.
Where should this packet go?
Selected traffic enters VPN
Specific private destinations (for example, 10.20.0.0/16) use the tunnel. Ordinary internet traffic keeps its local default route.
Default path enters VPN
The VPN supplies a default route so traffic not covered by more-specific routes follows the tunnel. Local on-link and explicitly excluded destinations can still use other interfaces, depending on policy.
Longest-prefix match matters: a route to 10.20.0.0/16 wins over the 0.0.0.0/0 default route for a packet to 10.20.14.30. If two otherwise comparable routes have the same prefix, metrics and platform policy help choose between them.
Split tunneling isn't automatically insecure and full tunneling isn't automatically perfect. Each design has tradeoffs in inspection, performance, internet egress, endpoint security and policy enforcement. Organizations sometimes use application-specific exclusions or more nuanced routing than these simple diagrams.
A route to an IP is not a route to a name.
VPN clients often need internal DNS servers and rules for internal namespaces such as corp.example. Windows may use a Name Resolution Policy Table (NRPT), DNS suffixes, adapter preferences and other system policies to choose the resolver. The behavior varies by client and configuration.
Can I resolve files.corp.example to the intended internal address? And does the resulting packet have a permitted path to that address? Successful DNS alone doesn't prove routing, and successful IP access doesn't prove name resolution.
If a public resolver answers “name not found” for a private-only hostname, changing the global DNS settings at random could disrupt other workloads. Compare the approved VPN DNS policy, internal DNS server reachability, suffix/NRPT behavior and the actual query response before changing anything.
Trace the route before you diagnose the failure.
Connect or disconnect the simulated VPN, change its routing mode, and toggle the corporate route or internal DNS. Select a destination to see the chosen egress and what might still block the application.
| Destination | Egress | State |
|---|---|---|
192.168.1.0/24 | Wi-Fi | Active |
10.20.0.0/16 | VPN tunnel | Active |
0.0.0.0/0 | Wi-Fi | Active |
Egress: VPN tunnel. The specific corporate /16 wins over a /0 default route.
DNS: Internal name resolves to 10.20.14.30 (simulated).
This model has a plausible route and name-resolution path. Actual service access still depends on gateway rules, return routes, host firewall, authentication and application health.
Training model: no packets are sent. An actual VPN client can install more-specific exceptions, routes with competing metrics, traffic filters, NRPT rules and IPv6 routes. Example addresses and names are fictional or reserved for documentation.
A VPN failure is not one single failure.
Can the client reach the internet?
Validate Wi-Fi/Ethernet, the local gateway and ordinary connectivity before blaming the VPN.
Can it find and reach the VPN gateway?
Verify the approved hostname, DNS answer, protocol and listener. A timeout before authentication is not evidence of a bad password.
Did the user or device satisfy the policy?
Check certificates, credentials, MFA, device posture and gateway logs without weakening access requirements.
Did the security association/session come up?
Look at the client status and assigned virtual address. A CONNECTED indicator isn't an end-to-end application test.
Where does the client send application traffic?
Compare routes and interface metrics, then internal DNS and name-resolution policy separately.
Can the actual service respond?
Check host firewalls, VPN access rules, return routes, application ports and service health; verify the original workflow.
If a user's home LAN is 192.168.1.0/24 and the office network also uses 192.168.1.0/24, a local on-link route can keep packets from reaching the corporate site over VPN. Diagnose route preference and coordinate an approved network/VPN design change; don't assume a tunnel problem.
MTU and path-MTU: encapsulation adds overhead. Some networks may pass small packets but struggle with larger packets, particularly when PMTU discovery is blocked. Diagnose size-dependent symptoms and use approved product-specific changes rather than changing MTU indiscriminately.
Gather evidence in layers.
These commands are illustrative and read-only. Some apply specifically to the built-in Windows VPN client, while third-party VPNs use their own diagnostic tools and logs.
Get-NetIPConfigurationInspect interfaces, addresses, gateways and DNS settings. Third-party VPN adapters may appear differently.
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefixInspect destination prefixes, interface indices and route metrics. Compare changes after connecting.
route print -4Cross-check the effective IPv4 route table including on-link routes and VPN entries.
Get-DnsClientServerAddress -AddressFamily IPv4Inspect which DNS servers are configured on each interface.
Get-DnsClientNrptPolicyFor Windows environments using NRPT, inspect namespace-specific name-resolution rules.
Resolve-DnsName files.corp.exampleTest the private hostname (replace this illustrative name with an authorized real target).
Test-NetConnection 10.20.14.30 -Port 445Check TCP reachability to an authorized internal file server; it does not prove SMB authentication.
Get-VpnConnectionFor supported built-in Windows VPN profiles, inspect the configured endpoint and split-tunneling setting.
# Illustrative: use only authorized internal targets route print -4 Resolve-DnsName files.corp.example Test-NetConnection 10.20.14.30 -Port 445 # Inspect VPN client and gateway logs as appropriate
For a remote file share, a successful TCP test proves connectivity to the specific port—not share permissions, SMB negotiation, application authorization, or the user's final workflow. Always verify at the layer where the original symptom occurred.
Explain why, not just what.
01The VPN says CONNECTED, but files.corp.example fails to resolve. Is the tunnel broken?
Not necessarily. An authenticated tunnel can be healthy while the client uses a public resolver or lacks an internal DNS policy. Check the DNS query path, response and VPN name-resolution rules independently of the data route.
02A split-tunnel user can reach 10.20.14.30 by IP but not by hostname. What's the first likely distinction?
Routing to the private IP works, but DNS or name-resolution policy may be wrong. Compare Resolve-DnsName and the actual DNS servers/policy; do not replace the entire route table.
03Will a full-tunnel default route override a local 192.168.1.0/24 route?
Usually not. Longest-prefix matching prefers a specific /24 over a /0 default. VPN client traffic filters and routes can change the result. Examine the actual client route table rather than assuming.
04Why might IPsec work from one network but not another?
Possible causes include an inaccessible gateway, blocked UDP 500/4500 (for common IKEv2/NAT-T deployments), NAT/firewall behavior, authentication differences, MTU/path-MTU problems, or differing client policies. Use protocol-specific logs.
05Does a successful Test-NetConnection to port 443 prove a VPN is authenticated?
No. It tests TCP reachability to the specified endpoint and port. TLS validation, MFA, tunnel establishment, routing and application authorization require separate evidence.
06Should a technician disable MFA or broaden firewall rules to fix a VPN timeout?
No. Establish where the failure occurs first. Validate the approved endpoint and listener, compare logs and client configuration, and make the smallest authorized correction.
Check the implementation details.
This guide is vendor-neutral education. Examples use private and documentation-only addresses and do not operate a real VPN. Product defaults, firewall policy, authentication and DNS behavior vary by deployment.