Routing, Default Gateway, Route Table, and NAT Issues
Key Takeaways
- Routing faults are read from which destinations work, which fail, and where the path stops.
- A missing or wrong default gateway breaks off-subnet traffic while same-subnet communication still succeeds.
- Route-table issues include missing routes, wrong next hops, prefix-length errors, administrative-distance preference, and asymmetric paths.
- NAT/PAT failures block Internet access, inbound publishing, or VPN traffic; NAT is not a firewall policy by itself.
- Traceroute, ping, route lookup, ARP, firewall logs, and packet captures supply complementary evidence.
Routing, Gateways, Route Tables, and NAT
Routing decides where a packet goes next. A user reports "the Internet is down," but the real cause might be a missing default gateway, a stale static route, a failed dynamic route, a firewall policy, or a Network Address Translation (NAT) failure. Strong troubleshooting compares a working path against a failing one and finds where they diverge. On the N10-009 exam, a performance-based question may hand you a route table and ask which next hop a destination uses, so reading a routing table fluently is a tested skill.
Default Gateway Issues
The default gateway (0.0.0.0/0) is the next hop for anything outside the local subnet. If it is wrong or missing, a host still reaches same-subnet neighbors but cannot leave the subnet.
| Symptom | Likely issue |
|---|---|
| Pings same-subnet host but not a remote subnet | Missing or wrong default gateway |
| Pings the gateway but not the Internet | Upstream route, firewall, NAT, DNS, or ISP issue |
| Only one VLAN affected | Gateway SVI, ACL, DHCP option, or that VLAN's route |
| New static-IP host fails off-subnet | Mask or gateway typed in wrong manually |
Confirm the gateway is on the same subnet as the host's IP and mask. A host at 10.1.1.50/24 pointed at gateway 10.1.2.1 has an off-subnet gateway it can never ARP for, so all remote traffic black-holes while same-subnet pings still work. On a router or Layer 3 switch the per-VLAN gateway is a Switched Virtual Interface (SVI); if that SVI is shut down or in the wrong VLAN, only that one VLAN loses off-subnet reachability while the rest of the site is unaffected.
Route Table Problems
Routers and Layer 3 switches choose the path with the longest prefix match; when two protocols offer the same prefix, the lower administrative distance (AD) wins (connected 0, static 1, eBGP 20, OSPF 110, RIP 120). Problems appear when the needed route is absent, points to a wrong next hop, has an unexpected preference, or returns by a different path through a stateful firewall.
| Route issue | Troubleshooting clue |
|---|---|
| Missing route | No path to that destination network |
| Wrong next hop | Sent to a device that cannot forward it |
| Incorrect prefix length | Matches more or fewer addresses than intended |
| AD or metric problem | A less desirable route is chosen |
| Asymmetric routing | Forward and return paths differ; stateful inspection breaks |
| Summarization error | A summary hides a needed, more-specific route |
Do the route lookup on the device making the forwarding decision (show ip route, traceroute). A route on your laptop does not prove the core router or firewall has it. Asymmetric routing is a frequent gotcha: traffic leaving via firewall A but returning via firewall B has no matching session state on B and gets dropped, even though both routes look valid.
NAT and PAT Issues
NAT rewrites addresses crossing a boundary; Port Address Translation (PAT), also called NAT overload, lets many inside hosts share one public IP by tracking source ports. NAT fails when the rule is missing, ordered wrong, matched to the wrong source, lacks a public pool, or collides with a VPN.
| NAT scenario | Common issue |
|---|---|
| Inside users cannot browse by IP | Source NAT/PAT missing, upstream route gone, or deny rule |
| Published server unreachable from outside | Destination NAT, firewall policy, public DNS, or ISP path |
| VPN traffic translated unexpectedly | Missing NAT exemption or wrong rule order |
| Overlapping private networks | NAT design / address-plan conflict |
| Some clients fail at high load | PAT port pool or session-table exhaustion |
NAT is not a security policy by itself; the firewall still needs explicit permit/deny rules alongside it.
Path Isolation Tools
Each tool answers a different question, and combining them localizes the break point quickly.
| Tool / evidence | What it answers |
|---|---|
ping | Is the target reachable and answering ICMP? |
traceroute / tracert | Where does the path stop or change hops? |
Route table (show ip route) | Which next hop should be used? |
| ARP / neighbor table | Is local next-hop resolution working? |
| Firewall logs | Was traffic denied, allowed, or translated? |
| Packet capture | Did the packet leave, return, or change as expected? |
Worked scenario: a client cannot reach a server two subnets away. Ping to the gateway succeeds; traceroute dies at the second hop. On that hop the route table has no entry for the destination network, so it falls to a default that loops. Adding the specific route fixes it. Had ping succeeded but the app failed, an ACL, NAT, or the return path would be the next suspect.
Exam Focus
For N10-009: local works, remote fails points to a gateway or route. Route exists but traffic still fails implicates an ACL, firewall state, the return path, or NAT. Internet-by-IP fails for many clients right after a firewall change suggests NAT or policy before you ever blame DNS. Always run the route lookup from the forwarding device, not the endpoint.
A host can reach other hosts in its own subnet but cannot reach any remote subnet. Which client setting should be checked first?
From the firewall, an admin can ping a public IP, but clients behind the firewall cannot browse the Internet by IP after a recent rule change. DNS is confirmed not involved. What should be checked?
Match each routing or NAT clue to the likely issue.
Match each item on the left with the correct item on the right