If the default gateway is unreachable, remote troubleshooting is downstream of the known failure
A client sending traffic outside its own subnet normally has to deliver a local Layer 2 frame to its default gateway before any remote route can matter. That makes an unreachable gateway a boundary problem: first confirm the client believes the gateway is local, then confirm it can resolve and reach that gateway across the correct Layer 2 domain.
After locating the local gateway boundary, test whether your explanation stays within the observed evidence. The AP Networking Routing and Default Gateway Practice Test contrasts unanswered next-hop ARP, successful gateway ping, remote transport denial, and missing return routes across three difficulty levels.
One client, one VLAN, or the entire site point to different failure domains
One client fails
Check local IP, mask, gateway, NIC, port, VLAN, ARP, and duplicate addressing first.
One VLAN fails
Check SVI/router interface, VLAN trunking, shared switch path, and VLAN-specific policy.
Many VLANs fail
Check common gateway devices, core links, routing platform state, and broad policy or power events.
Scope is high-information evidence because it tells you whether to start at the endpoint, the broadcast domain, or a shared infrastructure layer.
Before blaming the router, prove that the gateway is actually inside the client's local subnet
The source example is excellent: client 192.168.20.130/26 belongs to network 192.168.20.128/26, whose traditional usable range is .129–.190. Gateway 192.168.20.1 is outside that subnet.
Either the host IP/prefix or gateway configuration is wrong. Testing remote DNS at this point adds little because the first-hop configuration itself is invalid.
A bad prefix changes which destinations the client tries to ARP for locally
A wrong subnet mask can create confusing symptoms even when the IP address and gateway look familiar. If the mask is too broad, the client may treat a truly remote destination as local and ARP for it instead of using the gateway. If the mask is too narrow, the client may try to send local traffic to the gateway unnecessarily.
If IPv4 believes the gateway is local, the next question is whether its MAC address can be resolved
For a normal Ethernet or Wi-Fi LAN, the client needs a Layer 2 destination before it can send the frame to its gateway. ARP provides that mapping for IPv4.
An incomplete result can point toward the wrong VLAN, a broken local switch path, the gateway interface being down, an incorrect gateway address, or a configuration error that caused the client to ARP for the wrong destination.
Neighbor resolution is stronger when you pair it with MAC-table learning
ARP tells you whether the client learned a MAC for the gateway IP. The switch MAC table tells you where the corresponding Layer 2 address is being learned. Those artifacts together can distinguish “the client never receives an ARP reply” from “the gateway MAC is appearing on an unexpected port.”
Link up does not mean the client shares the gateway's broadcast domain
A healthy cable, Wi-Fi association, or switch link proves only a lower-layer attachment. A client placed into VLAN 30 cannot normally ARP directly for a gateway that exists only in VLAN 20. Compare the failing access port or SSID-to-VLAN mapping with a known-good peer.
The lease itself can reveal that the endpoint landed in the wrong network
If the network uses DHCP, compare the failing client's lease with a working peer. A different subnet, gateway, DNS set, or scope can indicate wrong VLAN placement, relay behavior, or an unintended DHCP source.
Do not accept “the client has an IP address” as proof that it has the correct IP configuration.
Local switching can work while the Layer 3 gateway function is down
If multiple clients in the same VLAN can reach one another but none can reach the gateway, inspect the router interface or switch virtual interface. It may be administratively down, operationally down, misaddressed, or absent from the intended VLAN.
This pattern separates a healthy Layer 2 broadcast domain from a failed Layer 3 first-hop function.
A working access VLAN can still lose the gateway if the VLAN is not carried to the Layer 3 device
In switched networks, the access port can be configured correctly while an upstream trunk no longer carries that VLAN. Endpoints on the same access switch may still communicate locally, yet the VLAN's gateway becomes unreachable because frames never reach the SVI/router path.
Alternating gateway MAC addresses are a high-value duplicate-address clue
A default gateway IP should have the intended Layer 2 owner in that broadcast domain. If ARP entries for the gateway flip between two unrelated MAC addresses, investigate a duplicate address, misconfigured device, rogue gateway, or an HA design that is not behaving as intended.
Repeatedly clearing ARP may temporarily change the symptom but does not identify the competing device.
A failed ping alone does not prove the gateway cannot forward
Gateways can filter or deprioritize ICMP Echo sent to their own interface. If remote traffic successfully crosses the gateway, the gateway is clearly forwarding even if it does not answer ping.
Endpoint policy can distort the evidence before traffic ever leaves the client
Host-based security software, local route changes, VPN clients, or unusual interface metrics can alter which interface or next hop is used. If one endpoint alone fails while nearby peers work, inspect its route table and active interfaces rather than assuming a shared switch or gateway fault.
Compare artifacts from two clients that should behave identically
| Artifact | Working client | Failing client |
|---|---|---|
| IP/prefix | Expected subnet | Different prefix? |
| Gateway | Expected IP | Wrong gateway? |
| ARP entry | Complete/stable | Incomplete/flapping? |
| VLAN | Expected VLAN | Wrong VLAN? |
| Route | Normal default | VPN/static override? |
Swipe horizontally to see the peer-comparison table.
One client has the wrong /26 gateway
Observed: 192.168.20.130/26 with gateway 192.168.20.1.
Interpretation: the gateway is outside the client's local /26. Correct the addressing plan before investigating the router itself.
All clients in one VLAN lose the gateway but can still reach one another
Observed: peer-to-peer traffic inside the VLAN works, gateway ARP fails for every client.
Interpretation: inspect SVI/router interface state, upstream trunk carriage, or the shared path between the VLAN and its Layer 3 gateway.
Gateway ARP alternates between two MAC addresses
Observed: clients intermittently reach the gateway and ARP ownership flips.
Interpretation: investigate duplicate IP ownership or an unintended device claiming the gateway address. Clearing ARP is not a root-cause fix.
Gateway ping fails, but Internet access works
Observed: local echo requests time out while remote web traffic succeeds.
Interpretation: the gateway is forwarding traffic. ICMP to the interface is filtered or deprioritized; do not misdiagnose the gateway as unreachable for forwarding.
Only one laptop cannot reach the gateway after connecting a VPN
Observed: nearby peers work. The laptop route table shows a VPN-installed route and altered interface preference.
Interpretation: the problem is endpoint-specific route/interface state, not the shared gateway.
Match the artifact to the dependency you are testing
| Evidence | Supports | Still unproven |
|---|---|---|
| Correct IP/prefix/gateway | Client config is plausible | Layer 2 reachability |
| Stable gateway ARP | Local neighbor resolution | Remote forwarding |
| Peer traffic works | Some Layer 2 path works | Gateway interface |
| Gateway ping works | ICMP first-hop reachability | Remote routing/DNS/app |
| Remote IP works | Gateway forwards/routed path works | DNS/application |
Swipe horizontally to see the gateway evidence matrix.
Use the first failed dependency to choose the next test
Prove the gateway first, then move upstream in controlled steps
1. Client state: IP, prefix, and default gateway are correct.
2. Neighbor state: gateway ARP mapping is complete and stable.
3. First hop: gateway is reachable or forwarding is otherwise demonstrated.
4. Remote IP: test numeric reachability beyond the gateway.
5. DNS: confirm name resolution only after IP forwarding works.
6. Application: test the actual required service.
This ordered verification turns each successful checkpoint into reusable evidence instead of restarting the diagnosis from scratch.
Avoid conclusions that go beyond the evidence
- Link up does not prove the correct VLAN.
- An IP address does not prove the correct subnet or gateway.
- Failed ping does not prove the gateway cannot forward.
- Peer traffic does not prove the SVI is up.
- Clearing ARP does not solve a duplicate gateway owner.
- Remote DNS tests are premature while the first hop is still broken.
- One-host failure should not immediately be treated as a site-wide router outage.
A correct gateway address can still be bypassed by an unexpected route
Most client traffic uses the default route only when no more-specific route matches. A VPN, static route, virtual adapter, or stale route can therefore redirect traffic away from the expected local interface. If one client fails while peers work, inspect the active route table and interface metrics before treating the gateway device as broken.
This matters because “gateway unreachable” can actually be a route-selection problem rather than a Layer 2 failure.
Cached neighbor state can briefly hide or preserve a problem
A client may continue using a previously learned gateway MAC until the ARP entry ages or changes. That means a gateway failure, duplicate address, or VLAN change can produce intermittent behavior rather than an immediate clean outage.
Record the ARP table before flushing it. If the mapping changes unexpectedly after refresh, that change is evidence. If the same stable MAC returns but traffic still fails, move the investigation toward switch forwarding, the gateway interface, or policy.
A short capture can show whether the client is asking for the gateway and whether anyone answers
When command output is ambiguous, a packet capture on the endpoint can reveal the actual local exchange. Repeated ARP requests with no reply show that the client is trying to resolve the gateway but is not receiving an answer. An ARP reply followed by failed IP traffic moves the boundary past neighbor discovery.
Wi-Fi association can succeed while the client still cannot reach the gateway
A wireless client may associate to an AP but be mapped to the wrong VLAN, fail key/authentication transitions, experience severe RF loss, or receive the wrong DHCP scope. Compare the failing client's gateway loss with a wired control or another wireless client on the same SSID.
More than one physical router can legitimately participate in one logical gateway
In a first-hop redundancy design, clients may use one virtual gateway IP while multiple routers participate behind it. Seeing different infrastructure MAC information during an HA event is not automatically a rogue duplicate; interpret the behavior against the intended design.
The key test is whether the logical gateway identity remains reachable and whether ownership changes follow the expected redundancy mechanism. Unexpected flapping outside that design remains suspicious.
Use the symptom pattern to jump to the highest-information artifact
| Pattern | Strong next artifact | Why |
|---|---|---|
| One client, peers good | Client config + route + port/VLAN | Failure is endpoint-specific |
| All clients in one VLAN | SVI + trunk + VLAN state | Shared first-hop path |
| ARP incomplete everywhere | Gateway interface / VLAN carriage | No local owner is answering |
| ARP MAC changes repeatedly | Duplicate/HA ownership evidence | Layer 2 ownership is unstable |
| Ping fails, remote traffic works | ICMP policy | Forwarding is already proven |
| Gateway works, remote IP fails | Route/WAN/firewall | Local first hop is proven |
Swipe horizontally to see the failure-pattern matrix.
Make one controlled change so the result creates evidence instead of noise
Move the same laptop to a known-good port without changing its IP settings. Keep the same port but compare a known-good laptop. Temporarily remove a VPN while leaving the LAN unchanged. These tests isolate one variable at a time.
This is far stronger than rebooting the switch, router, client, and AP together, because a multi-variable reset destroys causality.
24 Gateway Unreachable Troubleshooting digital flashcards
Practice subnet math, ARP, VLAN placement, SVI/gateway state, duplicate IP clues, ICMP evidence boundaries, peer comparison, and verification order.