Remote reachability is a chain of forwarding decisions, not one routing-table lookup
A source host first decides whether the destination is local or remote. If remote, it chooses a gateway. Every router then selects a route for the destination, resolves or reaches the selected next hop, and forwards the packet. The destination must also have a usable return path. Filtering or stateful devices can interrupt either direction.
Evidence-first route sequence
Source IP/Prefix → Local-or-Remote Decision → Host Route → Gateway → Longest-Prefix Match → Next Hop → Forwarding Progress → Destination Network → Return Route → Policy/State → Verification.
The best next test is the one that identifies the first unresolved forwarding dependency while preserving everything already proven to work.
The first routing decision happens on the source host
The host compares the destination with its own configured prefixes and route table. If it considers the destination on-link, it attempts local delivery; if remote, it sends toward an appropriate gateway. A wrong prefix length can therefore break remote access before the default gateway is ever used.
A default route is only used when no more-specific matching route wins
Do not ask only whether a default gateway exists. List the routes that match the destination and select the longest prefix. A VPN, stale static route, or more-specific route can override the default even when the default is perfectly correct.
Route selection is destination-specific. “Internet works” does not prove the route to a private remote prefix is correct.
Route specificity explains why a bad static route can defeat a healthy default
Routers prefer the matching route with the longest prefix. A /24 match is more specific than a /16, and both are more specific than /0. This makes route-table analysis a comparison problem rather than a search for the first route that looks relevant.
For more route-table practice, use Routing for AP Networking and Network CLI Output Practice.
If the source cannot reach its selected gateway, remote routing has not really begun
Confirm that the chosen gateway is reachable through the expected local interface. An unreachable gateway can result from wrong local addressing, VLAN placement, interface state, neighbor resolution, or local link problems. Testing a distant server first adds little information when the first hop is unresolved.
| Checkpoint | If it succeeds | If it fails |
|---|---|---|
| Source config/route choice | Host selected intended path | Fix host prefix/route decision |
| Gateway reachability | Local path to first router works | Stay local |
| Remote router hop | Forwarding progressed upstream | Inspect previous/next route boundary |
| Destination network reached | Forward path progressed far | Inspect destination-side delivery |
Swipe horizontally to see the full table.
At each router, separate route existence from route usability
A routing table entry can exist while the path is unusable. After identifying the winning route, ask what it points to: a directly connected exit, a next-hop address, a tunnel, or another logical interface. Then verify that the required adjacency or interface is actually usable.
A selected next hop creates another dependency: can the router actually reach that neighbor?
Inspect the outgoing interface and the local mechanism needed to deliver to the next hop. On an Ethernet segment, neighbor resolution and link/VLAN state matter. A correct destination route with a failed next-hop adjacency can still produce a blackhole.
Keep the layers separate: the route answers where forwarding should go; local adjacency evidence answers whether the router can hand the packet to that next step.
Traceroute shows forwarding progress, but silence is not automatically the failure point
Traceroute can reveal responding Layer 3 hops as TTL/Hop Limit expires along a path. A sequence that advances through several routers proves the packet progressed at least that far. But asterisks can occur when devices do not return the expected diagnostic response even while forwarding traffic.
This is why traceroute should be correlated with route tables, destination tests, and policy evidence rather than interpreted as a perfect map.
One unreachable prefix with other remote networks working points toward selective routing or policy
If 172.20.0.0/16 fails while unrelated remote networks succeed, the default path may be functioning. Compare the routes and policies that are unique to the failed destination. A more-specific route, VPN prefix, ACL, missing return route, or destination-side condition becomes more plausible.
Forward-path success does not guarantee the reply can return
The remote host or its gateway must know how to reach the source network. This is especially important after adding a new subnet: outbound packets may reach an established remote network while the remote side has no route back to the new source prefix.
A packet capture showing requests arriving at the server with no replies leaving can indicate a server/service issue. Requests arriving and replies leaving the server but never returning to the client moves the boundary toward the return path or intervening policy.
Different forward and return paths are not automatically wrong—but stateful devices can make asymmetry matter
IP routing does not require the reply to follow the exact same routers. However, firewalls, NAT devices, and other stateful systems may expect both directions to traverse compatible state. A topology change that sends replies around the device that observed the original flow can therefore break connectivity even though both route tables contain plausible routes.
Do not diagnose “asymmetry” from a different-looking trace alone. Demonstrate the path difference and connect it to a stateful dependency that requires compatible flow state.
An explicit ICMP unreachable is stronger evidence than a timeout because a device reported a failure condition
Read who generated the message and its context. A router reporting that it cannot deliver toward a network gives a different boundary than a destination host reporting a delivery problem. Diagnostic messages can also be filtered or rate-limited, so absence of ICMP does not prove that no routing or policy failure exists.
A timeout can be caused by a missing route, failed next hop, silent filter, or nonresponsive destination
This is a classic differential-diagnosis problem. Route evidence can show that a path should exist; it cannot by itself prove a firewall permits the flow. Conversely, a firewall rule that permits a flow cannot compensate for a router with no usable route.
| Evidence | Supports | Still unresolved |
|---|---|---|
| No matching route | Routing failure at that device | What route should exist |
| Winning route + dead next hop | Forwarding adjacency failure | Why next hop is unreachable |
| Route/path evidence healthy + explicit policy deny | Filtering boundary | Whether deny is intended |
| Only timeout | Failure somewhere before reply | Routing, filtering, return, destination |
Swipe horizontally to see the full table.
Repeated routers in a path are a different signature from a simple blackhole
If two or more routers repeatedly forward the destination toward each other, TTL/Hop Limit eventually expires. That is a routing loop, not merely an absent route. Inspect the exact prefix decision on each repeating router and determine why their next-hop choices are reciprocal.
See Routing Loop Symptoms for the deeper loop workflow.
The source can choose an unexpected interface even when both networks individually work
A host with Ethernet, Wi-Fi, virtual adapters, or a VPN can have overlapping routes. The most specific matching route—and then other route-selection rules where needed—can steer one destination through a different interface than ordinary Internet traffic.
Use what still works to choose the routing table worth inspecting
| Observed scope | What it suggests | High-information comparison |
|---|---|---|
| One host only | Host route, prefix, VPN, local state | Peer on same subnet |
| One destination prefix | Specific route/policy/return path | Neighboring remote prefix |
| All remote networks fail | Gateway/default/upstream dependency | Gateway vs first remote hop |
| One site/VLAN fails to remote prefix | Source-specific route/policy/return route | Different source subnet |
| Requests arrive remotely, replies disappear | Return route/stateful path | Remote capture + return route |
Swipe horizontally to see the full table.
Prefer artifacts that expose the actual forwarding decision
- Source address/prefix and exact route selected for the destination.
- Reachability of the selected first gateway.
- Winning route on the router using longest-prefix matching.
- Outgoing interface and next-hop/adjacency state.
- Traceroute as forwarding-progress evidence, not absolute proof from silence.
- Packet capture when directionality or return-path behavior is uncertain.
- Firewall/NAT state when route evidence is healthy but policy remains plausible.
- Destination-side route back to the source prefix.
Walk from the source decision outward and stop at the first unresolved dependency
- Write the exact source and destination IP addresses and prefixes.
- Determine whether the source should classify the destination as local or remote.
- Inspect the route selected for that exact destination.
- Verify the selected gateway or next hop is locally reachable.
- At each router, identify the longest matching prefix and outgoing next step.
- Use traceroute or captures to identify how far forwarding demonstrably progresses.
- Inspect destination-side delivery and the route back to the source.
- Evaluate firewall/NAT/state evidence if routing appears usable.
- Make the smallest route, adjacency, or policy change justified by evidence.
- Repeat the original test and an unaffected control prefix.
Four facts that prevent common routing overclaims
“The default route is correct.”
A more-specific bad route can still win for the failed destination.
“Traceroute has an asterisk.”
Later responding hops prove that silent hop may still forward transit traffic.
“The route exists.”
The selected next hop or outgoing adjacency can still be unusable.
“The server received it.”
The return route or stateful reverse path can still prevent the reply from reaching the source.
Verify the repaired prefix without accidentally changing neighboring routes
Repeat the exact source-to-destination test that failed. Confirm the intended route now wins and that forwarding progresses through the corrected next hop. Then test an unaffected remote prefix that should retain its prior path.
For a new return route, verify both directions. For a policy change, test the intended permitted flow and an intentionally disallowed flow when appropriate. For a VPN/host-route correction, verify the affected prefix uses the intended interface while ordinary traffic still follows its designed path.
Build the answer as observation → exact route decision → mechanism → next evidence → verification
24 interactive remote-routing flashcards
Practice subnet decisions, longest-prefix matching, gateway evidence, next-hop usability, traceroute, return paths, filtering, scope, and verification.