Successful gateway reachability moves the failure boundary upstream
If the client can ping its default gateway, the local path has already proven several dependencies for that ICMP exchange: the client has a usable local interface, the IP/prefix is plausible enough to classify the gateway as local, ARP or equivalent neighbor resolution succeeded, the VLAN/link path reaches the gateway, and the gateway interface responded. That is valuable evidence—but it does not prove the router can reach the Internet.
One client, one subnet, or every LAN client changes the likely cause
One client fails
Endpoint DNS, VPN routes, proxy settings, host firewall, or local application state become stronger.
One subnet fails
Subnet-specific NAT, ACL, policy routing, or VLAN-to-WAN rules become stronger.
All LAN clients fail
WAN session, default route, edge firewall, NAT platform, provider service, or shared DNS become stronger.
Scope prevents you from treating an endpoint problem like an ISP outage—or an ISP outage like a browser problem.
Test a known remote IP before touching DNS
A numeric destination bypasses hostname resolution. If a remote IP succeeds, upstream IP forwarding works for that test and DNS becomes a logical next branch. If the remote IP fails too, changing DNS servers cannot repair the underlying path.
The router can answer local clients while having nowhere to send Internet traffic
A router automatically knows its directly connected networks, so the LAN can function perfectly even when the router lacks a valid default route. Unknown Internet destinations need either a default route or a more-specific matching route.
This is one of the cleanest explanations for “gateway works, Internet does not.”
A default route can exist and still point to the wrong next hop
Do not stop at “there is a 0.0.0.0/0 route.” Verify the next hop and egress interface. A stale route after an ISP change, VPN tunnel, lab configuration, or failover event can send traffic toward a dead or unintended path.
The LAN side can be healthy while the provider-facing side is down
A SOHO router may continue serving DHCP, responding to pings, switching local traffic, and hosting its management page even when the modem/ONT link, PPPoE session, DHCP lease, or provider circuit is down.
A valid WAN address narrows the problem, but does not finish the diagnosis
If the router has a provider-assigned WAN address and gateway, the handoff and address acquisition are functioning to some degree. The next questions become whether the router can reach a remote numeric IP, whether NAT is translating client traffic, whether firewall policy permits forwarding, and whether the provider path is usable.
Compare traffic generated by the router with traffic forwarded for a client
This is one of the highest-information tests on the page. If the router itself can ping a remote IP but LAN clients cannot, the provider path and router's own upstream routing work. The failure becomes more specific to forwarded client traffic.
Private clients may have a route upstream but no usable return path without translation
Clients using RFC 1918 private space commonly depend on source NAT/PAT at the Internet edge. The router can possess a valid WAN address and default route while still failing to translate traffic from one LAN subnet.
One subnet can lose Internet while another works if translation rules are incomplete
A NAT policy may include 192.168.10.0/24 but omit a newly created 192.168.20.0/24 VLAN. That produces a very specific scope pattern: both subnets can reach the gateway, but only one reaches the Internet.
Traffic to the router and traffic through the router are separate policy cases
A firewall can allow ICMP to the gateway's LAN interface while denying client-to-Internet forwarding. That is why a successful gateway ping proves very little about outbound TCP/UDP policy.
Inspect the rule that matches the actual forwarded flow, including source subnet, destination, protocol, service, and egress zone.
Firewall hit counts can show whether traffic reaches the expected rule
If the expected outbound rule never increments while the client is testing, traffic may be matching a different rule, taking another route, or failing before the firewall decision. If a deny rule increments exactly during the test, you have much stronger policy evidence.
Traceroute can help show whether traffic leaves the local gateway
If the first provider hop responds, the packet is making it beyond the local edge. If the trace never advances beyond the gateway, inspect the local route, WAN state, NAT, and edge policy first.
Hop 4 alone is not proof of failure because later hops respond. Interpret traceroute as path evidence, not a guaranteed list of every forwarding device.
Use multiple artifacts before blaming the provider
| Evidence | Stronger interpretation |
|---|---|
| No WAN carrier/address | Handoff/provider-edge issue |
| WAN valid, router remote ping fails | Provider/upstream route or edge policy |
| Router remote ping works, clients fail | NAT/forwarding policy/client path |
| Remote IP works, names fail | DNS |
| One public service fails, others work | Remote/service-specific problem |
Swipe horizontally to see the boundary matrix.
Move to DNS only after numeric reachability works
If the client can reach a known remote numeric IP but cannot open sites by hostname, inspect the configured resolver, reachability to that resolver, UDP/TCP 53 policy, and the returned records.
This is exactly why the numeric test belongs before DNS changes.
Compare who is actually performing the lookup
Some home gateways advertise themselves as the DNS resolver and forward queries upstream; others hand clients public or provider resolver addresses directly. If the router can resolve names but clients cannot, inspect DHCP-provided DNS values, client policy, or LAN-to-resolver access.
If neither the router nor clients can resolve while remote numeric IPs work, the shared upstream resolver path becomes stronger.
Small ICMP probes can succeed while larger application flows stall
A successful gateway ping—and even a successful remote ping—does not prove that larger packets survive the path. PPPoE, VPNs, tunnels, and other encapsulation can reduce effective MTU. If small probes work but HTTPS, VPN, or file transfer stalls, investigate path MTU and fragmentation-related behavior.
The forward path can work while replies take a broken route back
Internet traffic is not guaranteed to return along the same path. A misrouted return route, upstream ACL, stateful firewall, or NAT issue can cause replies to disappear even after outbound packets leave successfully.
If peers have Internet, move back toward the endpoint
When the gateway and Internet work for neighboring clients, inspect the failing endpoint's DNS configuration, VPN software, proxy settings, local firewall, route table, interface metrics, or browser/application state. Shared WAN troubleshooting becomes lower value.
Gateway works, router has no default route
Observed: every client reaches the gateway. The router route table has connected LAN routes but no default route.
Inference: Internet traffic has no upstream forwarding path. Fix route/WAN configuration before touching DNS.
Router can reach the Internet, clients cannot
Observed: the router successfully pings a public IP. LAN clients reach the router but cannot reach the same public IP.
Inference: provider reachability and the router's own default route work. Inspect NAT, LAN-to-WAN firewall policy, or client-specific routing.
One VLAN has no Internet after a network expansion
Observed: original VLAN works; new VLAN reaches its gateway but cannot reach the Internet. NAT configuration includes only the original subnet.
Inference: translation policy does not include the new subnet.
Remote IP works but websites fail by name
Observed: 1.1.1.1 replies, while DNS queries to the configured resolver time out.
Inference: upstream IP forwarding is working for the numeric test. DNS is the first failed dependency.
Small pings work but VPN and large HTTPS transfers stall
Observed: gateway and remote pings succeed; larger encapsulated flows fail after a tunnel change.
Inference: investigate MTU/path-MTU behavior instead of declaring the Internet path fully healthy.
Each successful checkpoint removes entire branches from the diagnosis
| Checkpoint | What it proves | What remains unproven |
|---|---|---|
| Gateway ping | Local ICMP first hop | WAN/NAT/DNS/app |
| Router remote ping | Router upstream IP path | Client NAT/forwarding |
| Client remote IP | Client upstream IP forwarding | DNS/application |
| DNS lookup | Name resolution | Required application |
| Application transaction | End-to-end service for that test | Other services/paths |
Swipe horizontally to see the evidence matrix.
Use the nearest successful checkpoint to choose the next branch
Make one controlled change so the result creates new evidence
Keep the client and destination constant while testing a different DNS resolver only after numeric reachability is proven. Keep the route and WAN constant while temporarily disabling one outbound policy rule in a safe lab. Compare router-originated and client-forwarded tests without changing both at once.
Restore service in layers and prove each one
1. Gateway: local first hop still works.
2. Remote IP: upstream forwarding works from the client.
3. DNS: hostname resolution returns the expected answer.
4. Application: the original web, VPN, or cloud workflow succeeds.
5. Negative control: restricted traffic remains blocked where required.
This sequence prevents a repaired route from being mistaken for a fully repaired user experience.
Do not overstate what a gateway ping tells you
- Gateway ping success does not prove a default route exists.
- Gateway ping success does not prove NAT is working.
- Gateway ping success does not prove outbound firewall policy permits clients.
- Router Internet access does not prove forwarded client traffic works.
- Remote IP success does not prove DNS.
- DNS success does not prove the application.
- One silent traceroute hop does not prove transit failure.
- Small ping success does not prove MTU-sensitive applications.
Change the traffic origin without changing the destination
When the same public IP is reachable from the router but not from a LAN client, the difference is not the provider destination—it is the forwarding path through the router. That makes NAT, client-to-WAN firewall policy, policy routing, and client-specific state far more useful places to investigate than the modem or ISP.
This is a classic controlled comparison because only the traffic source and forwarding context change.
Once the gateway responds, local neighbor discovery has already done its job for that exchange
A successful gateway ping means the client resolved and reached its first-hop neighbor well enough for ICMP. Repeatedly clearing ARP or replacing local cables after that success usually adds little information unless the problem is intermittent or scope evidence points back to the LAN.
Separate the customer edge from the provider handoff
In many environments the Internet path includes a customer router, a modem or ONT, and then a provider next hop. The customer's LAN gateway can be perfectly healthy while the modem/ONT loses registration, the WAN lease expires, or the provider-facing session fails.
Breaking the path into these boundaries keeps “the router works locally” from being mistaken for “the provider path is healthy.”
Use more than one remote destination before declaring the entire Internet unreachable
A single public host may filter ICMP, rate-limit probes, or be temporarily unavailable. Test more than one known destination and, when possible, more than one protocol. If multiple unrelated public IPs fail from both the router and clients, the shared upstream path becomes much stronger.
If only one destination fails while others work, move toward remote-service or route-specific troubleshooting instead of declaring a universal WAN outage.
A browser error can look like DNS even when the failure is elsewhere
Some browser messages are vague, and cached DNS entries can hide resolver problems. Use a direct lookup tool to see whether the name resolves, what address is returned, and which resolver answered. Then test the returned address directly.
This prevents a valid DNS answer from being blamed for a transport or application failure.
NAT can fail because of state capacity, not only because the rule is missing
Busy gateways maintain translation/session tables. If those tables are exhausted or corrupted, new outbound sessions may fail even though the NAT policy is logically correct. Evidence can include high session counts, allocation failures, logs, or a pattern where established flows continue while new ones fail.
A special routing rule can override the normal default route for selected clients
Some routers send traffic from specific VLANs, users, or applications through a VPN, secondary ISP, or security appliance. If one subnet reaches the gateway but not the Internet while another works, inspect policy-based routing in addition to NAT and ACLs.
The default route can be healthy while policy-selected traffic follows a failed path.
Internet reachability is not fully verified until the original user workflow succeeds
A remote numeric ping proves only that one ICMP exchange completed. DNS success proves name resolution. A TCP connection proves transport reachability to a port. The final check should be the actual web, cloud, VPN, or other application transaction that originally failed.
24 Can Ping Gateway but Not Internet digital flashcards
Practice default routes, WAN state, NAT/PAT, firewall forwarding, provider-path evidence, DNS branching, MTU, asymmetry, scope, and verification order.