A connection icon proves local attachment, not Internet reachability
Ethernet can show connected because the NIC negotiated a physical link. Wi-Fi can show connected because the client associated with an access point. Neither state proves that the client has the right IP address, correct subnet mask, reachable gateway, working DHCP lease, DNS resolver, edge route, NAT, firewall policy, provider path, or application service.
Use the first failed checkpoint to narrow the fault domain
| Checkpoint | If it fails | Best next evidence |
|---|---|---|
| Link/association | Physical or wireless access problem | Interface state, cable, SSID, authentication |
| IP configuration | DHCP/static/VLAN issue | Address, prefix, gateway, DNS, lease |
| Gateway | Local Layer 2/3 boundary problem | ARP, VLAN, mask, SVI/router interface |
| Remote numeric IP | Routing/NAT/firewall/WAN | Route, NAT, edge logs, provider state |
| DNS name | Resolver/name-resolution problem | Resolver query and client DNS settings |
| Application | Port/TLS/proxy/service issue | TCP test, listener, proxy, TLS evidence |
Swipe horizontally to see the troubleshooting table.
Read the complete client IP configuration before testing the Internet
A connected client with the wrong addressing cannot be diagnosed from the browser. Check the IPv4 address, prefix/mask, default gateway, DNS servers, and whether the configuration came from DHCP or static settings.
APIPA is a boundary clue: DHCP assignment did not complete as expected. It does not by itself prove that the DHCP server is down.
A working device on the same intended network is one of the highest-value controls
Compare address range, prefix, gateway, DNS, VLAN/SSID, and DHCP state. If the failing client has a different subnet or resolver while the peer works, that difference is much more useful than restarting random infrastructure.
Same subnet?
Compare IP and prefix.
Same gateway?
Compare first-hop routing boundary.
Same DNS?
Compare resolver source and addresses.
Test the default gateway to separate local failure from upstream failure
If the client cannot reach its gateway, stay local. Investigate VLAN placement, ARP resolution, subnet mask, gateway address, wireless/client isolation, switch port state, or gateway interface/SVI state.
If the gateway responds, you have proven a useful local Layer 3 checkpoint and can move outward.
A gateway value can be valid-looking but still be wrong
First calculate whether the gateway is inside the client's local subnet. Then test whether the host can resolve and reach it. Those are separate questions.
Test a numeric remote IP to split DNS from broader Internet-path failure
If a remote numeric IP works while names fail, the path is functional enough for that numeric test and DNS becomes the leading branch. If the numeric IP also fails, changing DNS is not the first fix.
This is a classic information-gain test because the two outcomes send you into very different branches.
Timeout, NXDOMAIN, and wrong-answer responses mean different things
A DNS timeout suggests the resolver may be unreachable or blocked. NXDOMAIN means that resolver says the name does not exist in the namespace it knows. A wrong returned address points toward stale or incorrect records. If DNS returns the correct IP and the site still fails, move to TCP/TLS/application evidence.
If remote numeric IP fails, inspect the edge path in dependency order
Internal routing can work while Internet return traffic fails
A private client can reach its local router and the router can know a default route, yet Internet access can still fail if source translation is missing or wrong.
This is why “router can reach Internet” does not prove “client can reach Internet.”
If every client fails at once, compare shared dependencies before touching endpoints
When all clients can still reach the router but none can reach a remote numeric IP, shared edge components become much stronger suspects: WAN interface, provider link, edge default route, NAT, common firewall policy, or upstream outage.
Client-specific controls can break Internet access while the LAN remains healthy
If peers on the same VLAN work, investigate local firewall software, VPN routes, proxy settings, stale DHCP configuration, NAC role, DNS overrides, or endpoint-specific security software before escalating to the ISP.
VPN
Can install a default route or DNS settings that redirect traffic into a failed tunnel.
Proxy
Can break web browsing while ping or other protocols still work.
Host firewall
Can block traffic from one endpoint while peers remain normal.
A network can intentionally permit connection but restrict broader access
Guest Wi-Fi, NAC, and captive portals may permit association and DHCP while withholding broader network access until authentication, registration, posture checks, or role assignment succeeds.
A valid lease from the wrong subnet is evidence of logical misplacement
A client may have a perfectly valid IP configuration and still be in the wrong VLAN or SSID role.
Changing only the client mask is not a real repair.
One protocol family can fail while the other works
Modern clients may prefer IPv6 when both IPv4 and IPv6 are available. A broken IPv6 default route or DNS advertisement can create delays or “no Internet” reports even though IPv4 is healthy. The reverse can also occur.
If DNS and remote IP work, move to the required protocol and service
At this point the problem may be TCP port policy, proxy behavior, TLS/certificate handling, service listener state, or application configuration rather than basic Internet access.
Each successful checkpoint should eliminate weaker hypotheses
| Success | What it proves | What it does not prove |
|---|---|---|
| Link/association | Local attachment | IP or Internet service |
| Valid IP lease | Addressing obtained | Correct VLAN or upstream path |
| Gateway reachable | Local Layer 3 boundary works | WAN/NAT/DNS |
| Remote numeric IP works | Useful remote IP path | Name resolution/application |
| DNS resolves | Name-to-address mapping works | TCP/TLS/application |
| TCP connection works | Transport path/listener reachable | Application-level success |
Swipe horizontally to see the evidence ladder.
Connected Wi-Fi, APIPA address, peers work
Do not begin with the ISP. The client has not even reached the expected Layer 3 configuration stage.
Gateway works, remote IP fails, all users affected
Because the failure is network-wide, a single endpoint's proxy or local firewall is much less likely.
Remote IP works, DNS times out
This is a resolver-path problem until evidence says otherwise.
Only web browsing fails on one client
The Internet path is largely healthy. The client-specific proxy is the first failed application dependency.
Rebuild the entire chain after the repair
Do not stop because one page opens. Verify the configuration and the original task in order.
- Client has the intended IP, prefix, gateway, and DNS.
- Default gateway is reachable.
- Remote numeric IP succeeds when expected.
- DNS returns the intended answer.
- The actual application works.
- If the issue was shared, a second client also works.
If security or captive access was involved, verify that prohibited traffic remains restricted.
Use combinations of successful and failed tests to narrow the cause quickly
One result is useful; a pattern is much stronger. The same “no Internet” complaint can come from very different mechanisms, but the combination of gateway, remote IP, DNS, and application results usually creates a much smaller fault domain.
| Gateway | Remote IP | DNS | Application | Stronger branch |
|---|---|---|---|---|
| Fail | Fail | Unknown | Fail | Local VLAN/ARP/mask/gateway |
| Pass | Fail | Unknown | Fail | Routing/NAT/firewall/WAN |
| Pass | Pass | Fail | Fail | DNS/resolver |
| Pass | Pass | Pass | Fail | Proxy/TLS/port/service |
| Pass | Pass | Pass | Intermittent | Application, wireless quality, VPN, or policy state |
Swipe horizontally to see the failure-pattern matrix.
A DHCP problem can fail in several different ways
Not every DHCP problem produces APIPA. A client can receive a lease from the wrong scope, obtain a stale lease, receive the right IP but wrong gateway option, or receive an incorrect DNS server. Compare the lease against the intended network design rather than asking only whether DHCP “worked.”
No lease
APIPA or missing configuration. Investigate path, scope, server, or client state.
Wrong lease
Valid-looking address from the wrong VLAN or DHCP scope.
Bad options
Correct subnet but wrong gateway or DNS can still break Internet access.
ARP tells you whether the client can reach the local routing boundary
If the gateway is in the correct subnet but the client's ARP entry for it remains incomplete, the host cannot resolve the gateway's Layer 2 address. That shifts attention toward VLAN placement, gateway interface state, switch path, client isolation, or local Layer 2 filtering.
This is more specific than simply observing that a ping failed.
Use translation state to separate edge routing from source-translation failure
If the edge router itself can reach the Internet and clients can reach the edge, inspect whether client traffic creates the expected NAT translations. Missing translations, wrong inside/outside roles, or policy exclusions can stop return traffic while leaving the internal network healthy.
The router may be healthy locally but have no usable path upstream
A client can reach the router even when the edge router has no default route, has a stale next hop, or has an upstream interface down. Check the route that should carry unknown Internet destinations and then verify the next hop is actually reachable.
Firewall logs can prove the policy decision without proving the application
If the firewall logs an outbound deny for the client, that is direct evidence that policy stopped the flow. If it logs an allow, the application can still fail later because of NAT, upstream routing, TLS, proxy, or service state.
A broken VPN can hijack routes or DNS while the local network remains healthy
Some VPN clients install a default route, specific private routes, or resolver settings. If the tunnel is connected but the remote VPN gateway or policy is broken, the endpoint can appear locally connected while ordinary Internet traffic disappears into the tunnel.
Web failure is not always Internet failure
If ping, remote numeric IP, and DNS all succeed but browsers fail, inspect proxy configuration and application-specific controls. A manually configured proxy can make HTTP/HTTPS fail while other protocols remain normal.
A client can have perfect addressing and still be intentionally restricted
Guest networks may grant DHCP, gateway access, and limited DNS while redirecting or blocking broader traffic until authentication completes. Check portal/NAC role, session state, and whether the client was placed into a restricted VLAN.
Compare IPv4 and IPv6 before assuming both are broken
If a browser prefers IPv6 but the IPv6 default route is broken, users may see long delays or failures even though IPv4 works. Conversely, an IPv4 NAT or DNS problem can coexist with a healthy IPv6 path. Test each protocol family separately when the environment is dual-stack.
IPv4 test
Gateway, remote IP, DNS over IPv4.
IPv6 test
Router advertisement/default route, remote IPv6, DNS AAAA behavior.
Compare
Use the working family as a control.
Work outward from the client and stop at the first failed dependency
You do not need to run every test every time. Once a failed checkpoint is found, choose the next artifact that distinguishes the remaining hypotheses inside that branch.
One user has Wi-Fi, a valid lease, and no browser access
Decision: this is not a generic Internet outage. The client has working local routing, remote IP reachability, and DNS. The configured proxy is the first failed application dependency. Remove or correct the proxy according to the network policy, then re-test the browser while preserving the already-proven checkpoints.
24 Device Connected but No Internet digital flashcards
Practice link-state limits, DHCP, APIPA, gateway testing, numeric IP tests, DNS, NAT, firewalls, VPNs, proxies, captive portals, VLAN placement, dual stack, troubleshooting scope, and verification.