Routing, Default Gateway, Route Table, and NAT Issues
Key Takeaways
- Routing problems are often identified by which destinations work, which fail, and where the path stops.
- A missing or wrong default gateway affects off-subnet traffic while local subnet communication may still work.
- Route table issues include missing routes, wrong next hops, route preference problems, and asymmetric paths.
- NAT issues can block Internet access, inbound publishing, VPN overlap handling, or return traffic.
- Traceroute, ping, route lookup, ARP, firewall logs, and packet captures provide complementary evidence.
Routing, Gateways, Route Tables, and NAT
Routing determines where packets go next. A user may say "the Internet is down," but the real issue could be a missing default gateway, a stale static route, a failed dynamic route, a firewall policy, or NAT translation failure. Good troubleshooting compares working and failing paths.
Default Gateway Issues
The default gateway is the next hop for destinations outside the local subnet. If it is wrong or missing, a host may still reach neighbors in the same subnet but fail to reach remote networks.
| Symptom | Likely issue |
|---|---|
| Can ping same-subnet host but not remote subnet | Missing or wrong default gateway |
| Can ping gateway but not Internet | Upstream route, firewall, NAT, DNS, or ISP issue |
| Only one VLAN affected | Gateway interface, SVI, ACL, DHCP option, or route for that VLAN |
| New static IP host fails off-subnet | Mask or gateway manually configured wrong |
Route Table Problems
Routers and Layer 3 switches choose paths from their route tables. Problems appear when the needed route is absent, points to the wrong next hop, has an unexpected preference, or returns by a different path through a firewall.
| Route issue | Troubleshooting clue |
|---|---|
| Missing route | Device has no path to destination network |
| Wrong next hop | Traffic sent to device that cannot forward it correctly |
| Incorrect prefix length | More or fewer addresses matched than intended |
| Administrative distance or metric issue | Less desirable route chosen over expected route |
| Asymmetric routing | Forward and return paths differ, often breaking stateful inspection |
| Route summarization error | A summary hides a more specific needed path |
Use route lookup from the device making the forwarding decision. A route on your laptop does not prove the core router or firewall has the right route.
NAT and PAT Issues
Network Address Translation changes addresses as packets cross boundaries. Port Address Translation lets many internal clients share one public address by tracking ports. NAT can fail because the rule is missing, ordered incorrectly, matched to the wrong source, lacks a public address pool, or conflicts with VPN and firewall policy.
| NAT scenario | Common issue |
|---|---|
| Internal users cannot browse Internet by IP | Source NAT or PAT missing, upstream route missing, or firewall deny |
| Published server unreachable from Internet | Destination NAT, firewall policy, public DNS, or ISP path issue |
| VPN traffic translated unexpectedly | NAT exemption missing or rule order wrong |
| Overlapping private networks | NAT design or address plan conflict |
| Some clients fail when many connect | NAT pool or session capacity issue |
NAT is not a security policy by itself. Firewalls still need rules that permit or deny traffic.
Path Isolation Tools
| Tool or evidence | What it helps answer |
|---|---|
| Ping | Is a target reachable and responding to ICMP? |
| Traceroute | Where does the path appear to stop or change? |
| Route table | Which next hop should be used? |
| ARP or 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? |
Exam Focus
For N10-009, local works but remote fails often points to a gateway or route. Route exists but traffic still fails may involve ACLs, firewall state, return path, or NAT. Internet by IP fails for many clients after a firewall change suggests NAT or policy before DNS.
A host can reach other hosts in its subnet but cannot reach any remote subnet. What client setting should be checked first?
Internal users can ping a public IP address from the firewall, but clients behind the firewall cannot browse the Internet by IP after a rule change. DNS is not involved. What should be checked?
Match each routing clue to the likely issue.
Match each item on the left with the correct item on the right