When a Windows PC reaches the internet but cannot reach one work service, inspect its routing table before changing gateways or disconnecting security software. The read-only route print command shows local routing entries and interface identifiers. It helps explain where Windows can send traffic; it does not prove that the next router, VPN server or application will accept it.
Capture the destination and a baseline
Start with the actual destination IP address used by the failing connection, not just the application name. A hostname can resolve to different addresses, and IPv4 and IPv6 need separate consideration. Ask the application owner for the intended address if it is unclear. Note whether the VPN is connected, which network adapters are active, and when the failure occurs.
Open Command Prompt and run this inspection command. It does not add, delete or change routes:
route printKeep the full output for private troubleshooting. It can expose internal addresses and adapter details, so redact it before posting publicly. The interface list maps index numbers to adapters; the routing sections show destinations, masks, gateways and interfaces. Record a baseline before an approved VPN connection change, then capture another afterwards if your support procedure permits it. Never disconnect a managed VPN merely to bypass an access restriction.
Read the matching network before comparing metrics
A route describes a destination network using its network address and subnet mask. A default IPv4 route uses destination 0.0.0.0 with mask 0.0.0.0. It is a fallback, not evidence that every connection should leave through that gateway.
Consider a fictional worksheet: the service address is 10.42.8.25, one route covers 10.42.0.0 with mask 255.255.0.0, and another is the default route. The service belongs to the more specific network. Do not conclude that a low metric on the default route overrides that more specific match. Microsoft describes metric selection among routes that most closely match the destination.
If two candidate routes cover the same destination with the same specificity, compare their metrics and associated interfaces. Do not assume that a large number means a broken route: automatic interface metrics can contribute to the displayed costs. Leave metric changes to the person responsible for the intended routing design.
Match the gateway to the actual adapter
Read the gateway and interface fields together. The gateway is the forwarding next hop for a remote route. The interface identifies the local path used to reach it. A local or on-link destination is different from a remote network reached through a router; avoid interpreting every entry as an internet gateway.
Use the interface list to distinguish the physical adapter, virtual VPN adapter and disconnected remnants. A persistent-route section records configured entries, but its presence alone is not a successful connectivity test. Compare the active entries with the expected network design and ask whether the VPN is intended to route only work networks or all traffic.
For a shorter supporting view, Microsoft documents destination wildcards:
route print 10.*This prints destinations beginning with 10. It is not a full calculation of the route selected for a specific host: it can omit a default route or other useful context. Keep the complete capture as your primary evidence.
Separate route evidence from service evidence
An expected route does not establish that DNS returned the right endpoint, that a firewall permits access, or that the application is listening. Record the service port and test only the endpoint you are authorised to use. Our Windows TCP-versus-ping interpretation tutorial explains why an unanswered ping is not enough to declare an application unreachable.
If the expected work-network route is absent after the VPN connects, give support the before-and-after captures, destination address and VPN connection time. If it exists but access still fails, report the matching route and the application test separately. This avoids replacing a routing question with an unsupported firewall diagnosis.
Checklist and common questions
- Identify the destination address and address family.
- Save the complete route table and interface list.
- Find the most specific matching network before comparing metrics.
- Record the gateway, local interface and intended VPN behaviour.
- Escalate evidence rather than experimenting with route deletion.
Should I clear the table? No. Route-clearing options modify live networking and can break remote access. This workflow uses print commands only, so there are no configuration changes to roll back.
Does a normal table prove the network is healthy? No. It is local forwarding evidence, not an end-to-end availability or security assessment.
Source: Microsoft Learn route command reference, including print syntax, interface identifiers, metrics and persistent routes.
Safety: This tutorial is for educational purposes. Test carefully before using any steps in production. The site owner is not responsible for misuse, damage, data loss or production issues. Follow organisational access policies and do not change managed routing without approval.
