“Connected” is one passed checkpoint, not an end-to-end health report
The Wi-Fi icon usually tells you the client has joined an access point at Layer 2. Everything after that is a separate dependency: correct VLAN placement, DHCP configuration, default-gateway reachability, remote routing, NAT, firewall policy, DNS, captive-portal state, WAN/provider service, and the application itself.
Evidence-first path
Association → Correct VLAN/IP → Gateway → Remote numeric IP → DNS → Required service → Edge policy/NAT/WAN → Verification.
The troubleshooting goal is to find the earliest stage that lacks evidence of success. If the client already has a valid lease and can reach its gateway, do not keep resetting the wireless adapter. If a remote numeric IP works, do not treat the whole Internet path as dead. If DNS returns the expected address but HTTPS fails, move beyond DNS.
Start by asking whether the client received the configuration the WLAN was supposed to provide
A wireless client can associate successfully and still land in the wrong network or fail DHCP. The most useful configuration fields are the IPv4 address, mask/prefix, default gateway, DNS servers, and DHCP state. Interpret them against the intended SSID/VLAN design rather than calling any syntactically valid address “good.”
This is not a general Internet problem yet. The client has usable-looking Layer 3 values, but they are wrong relative to intended placement. Investigate SSID-to-VLAN mapping, NAC/role assignment, trunk/VLAN handling, and DHCP scope relationship.
ipconfig reports 169.254.44.12 with no normal default gateway. Peers on the same SSID have 10.90.0.x addresses. That evidence moves attention to DHCP delivery, client-specific VLAN/role, or upstream path—not DNS or the ISP.The default gateway is the first major Layer 3 checkpoint beyond the client
If the client cannot reach its configured gateway, the failure is still local enough that Internet DNS and remote application tests are downstream distractions. Check the client's prefix, intended VLAN, AP-to-switch path, gateway interface, local filtering, and whether the gateway actually belongs to the client's subnet.
If the gateway responds, that is useful evidence that the wireless link, local VLAN path, and Layer 3 handoff are working for the tested exchange. It does not prove that the router has a valid default route, that NAT is working, or that the ISP is reachable.
| Checkpoint | What success supports | What still remains unknown |
|---|---|---|
| Wi-Fi associated | Wireless Layer 2 join | IP config, gateway, Internet |
| Correct IP config | Expected local addressing | Gateway reachability |
| Gateway reachable | Useful local Layer 3 path | Remote routing/NAT/WAN |
| Remote numeric IP reachable | Some remote IP-layer path | DNS and exact application |
Swipe horizontally to see the full table.
Use a numeric remote target to separate IP reachability from name resolution
A hostname test can fail before packets ever reach the destination because DNS is part of the path. Testing a known remote numeric IP removes that dependency. This makes the comparison highly discriminating.
nslookup then times out against the configured resolver. The evidence weakens a total WAN outage and strengthens the DNS branch. Changing Wi-Fi channels would not address the first unresolved dependency.Continue with Can Ping IP but Not Domain Name when numeric reachability survives but hostname-dependent access fails.
DNS success narrows the problem, but it does not prove the application
A resolver query can show whether the configured DNS service returns an expected answer. If it does, move forward. A browser depends on DNS, transport, TLS, server response, redirects, scripts, and application logic, so a browser failure by itself is weak DNS evidence.
Conversely, if DNS queries are slow or fail for every client while remote numeric connectivity works, the shared resolver becomes a much more precise suspect.
Local connectivity can be perfect while edge translation or upstream routing is broken
Private-address clients often depend on an edge device to translate outbound traffic for Internet access. A client can reach its gateway successfully while NAT is missing, misapplied, exhausted, or otherwise unable to create correct return reachability. The router can also lack a usable default route or lose its WAN next hop.
A route entry or NAT state should still be interpreted with boundaries. Presence of a route does not prove its next hop works; presence of a translation entry does not prove the return path or remote service succeeds.
“No Internet” can really mean one protocol, port, source, or destination is blocked
Firewall policy should be evaluated as an exact flow: source, destination, protocol, port, direction, state, and rule order. A broad label such as “Internet blocked” may hide a selective deny.
Reverse the case: DNS resolves correctly and the server is listening on TCP/443, but a firewall log shows a deny for the exact client subnet to that server/port. The policy artifact has greater information value than another Wi-Fi reconnect attempt.
A client can be correctly addressed and routed yet intentionally restricted before portal completion
Guest WLANs often place new clients into a limited state until they accept terms, authenticate, or satisfy another access condition. The user may therefore have a valid IP address and a reachable gateway while general Internet traffic is blocked or redirected by policy.
HTTPS-first browsing can make this confusing because secure sites cannot be transparently replaced with a login page without certificate problems. Use the network's documented login process or a plain HTTP portal-detection page when appropriate.
One client, one SSID, wireless-only, and everyone have very different shared dependencies
| Scope | More interesting causes | Useful control |
|---|---|---|
| One wireless client only | Client IP/DNS, VPN/proxy, local firewall, NAC role, stale profile | Working peer on same SSID |
| One SSID only | SSID VLAN, DHCP scope, role/policy, WLAN-specific uplink | Different SSID on same APs |
| All wireless, wired normal | Wireless controller/uplink, WLAN VLAN/policy, AP-side dependency | Wired client to same target |
| Wired + wireless | Router/firewall, WAN, DNS, ISP, shared service | Local-only path or alternate external service |
| One application only | DNS record, port/policy, server, application dependency | Other application over same network |
Swipe horizontally to see the full table.
The number of affected users matters, but service scope matters too. Hundreds of users can all report “no Internet” when one widely used cloud application is actually the only failing destination.
Full Wi-Fi bars can coexist with a dead WAN because radio and Internet functions are separate
A standalone AP can keep advertising its SSID and accepting clients even when the upstream router loses Internet access. Consumer all-in-one devices combine AP, switch, router, NAT, firewall, and WAN functions in one box, but those functions are still logically separate.
This is why “the Wi-Fi signal is full strength” does not contradict an ISP outage. Signal strength describes the local radio relationship; the Internet path begins beyond that relationship.
When only one client fails, inspect software that changes its path or policy
A VPN can install routes or DNS settings that differ from peers. A proxy can redirect application traffic through another dependency. A host firewall can block selected flows. NAC can assign a restricted role to one endpoint. These are especially relevant when other clients on the same SSID, AP, VLAN, gateway, and Internet circuit work normally.
Choose the artifact that answers the next unresolved dependency
| Unresolved question | High-value evidence | Common low-value repetition |
|---|---|---|
| Did client get correct IP/VLAN? | Client config + expected SSID/VLAN design | Reconnect Wi-Fi repeatedly |
| Does local Layer 3 work? | Gateway test | Remote traceroute first |
| Does remote IP path work? | Known remote numeric target | Change DNS before testing IP |
| Does naming work? | Direct DNS query | Use browser error as DNS proof |
| Is exact service allowed? | Listener/service + firewall/policy evidence | Assume ping tells whole story |
| Is failure shared? | Peer/wired/SSID control | Reset all endpoints |
Swipe horizontally to see the full table.
Move forward only when the previous dependency has evidence of success
- Confirm the client is associated to the intended SSID/BSSID.
- Verify the expected VLAN/IP, mask, gateway, and DNS configuration.
- Test the local default gateway.
- Test a known remote numeric IP when appropriate.
- Query DNS directly for the intended hostname.
- Test the exact application/service requirement.
- Inspect NAT, firewall, default route, WAN, or ISP based on the failure boundary.
- Check captive-portal/NAC state for guest or restricted networks.
- Compare a working peer, wired control, or alternate service.
- Make the smallest justified change and preserve evidence of earlier successes.
Verify the original Internet requirement, not just one intermediate checkpoint
After a repair, repeat the same service that failed. If the issue was DNS, verify both the query and the real application. If the issue was NAT or WAN, test more than one external destination. If the failure was widespread, verify multiple clients or paths so one cached success does not create false confidence.
Write the answer as observation → bounded inference → next evidence → smallest justified change → verification
nslookup times out to the configured resolver. That weakens a wireless-link, local-gateway, and total-WAN failure and supports a DNS dependency problem. Inspect resolver reachability/configuration, correct the narrow DNS issue, then verify both name resolution and the original application.”A default route and a NAT rule solve different parts of the Internet path
A router can know where to send Internet-bound traffic and still fail to translate private addresses correctly. It can also have a NAT policy present while the upstream route or WAN next hop is unusable. These artifacts should therefore be interpreted separately instead of treating “routing/NAT” as one undifferentiated cause.
| Artifact | What it answers | What it does not prove |
|---|---|---|
| Default route | Which next hop/interface is selected for unmatched remote destinations | That next hop is reachable or return traffic succeeds |
| NAT rule | Which traffic should be translated | That translations are actively created and replies return |
| NAT translation entry | A translation exists for a specific flow/state | That the remote application completed successfully |
| WAN interface up | Interface reports operational state | That ISP routing or upstream service is healthy |
Swipe horizontally to see the full table.
This distinction becomes especially useful when local clients can reach their gateways but every external destination fails. Instead of repeatedly testing Wi-Fi, inspect which route the edge selects, whether the next hop is usable, whether translation occurs for the client flow, and whether replies return.
Compare what the client sees with what the gateway or edge device sees
One endpoint can only tell part of the story. If the client sends traffic but the gateway never sees it, the failure is still local or VLAN-related. If the gateway sees the packet and creates a translation but no reply returns, the boundary moves toward WAN, upstream routing, policy, or the remote side. If a reply reaches the gateway but never reaches the client, the return-path or local policy becomes more interesting.
The AP Networking value is in correlating two viewpoints. Client output explains what the endpoint attempted; router/firewall artifacts explain how the network handled that attempt. Together they create stronger localization than either artifact alone.
“Some sites work” is powerful evidence because it proves part of the path is already functional
If several unrelated external sites work but one destination fails, a complete ISP outage becomes much weaker. The failure may involve a destination-specific route, firewall rule, DNS record, application port, remote service, or policy. Likewise, if web browsing works but one VPN application fails, the Internet path is not universally broken.
Selective success should be preserved as a control. Ask what differs between working and failing flows: destination IP, hostname, protocol, port, source policy, NAT behavior, path, or authentication. This turns a vague “Internet problem” into a much smaller differential diagnosis.
24 “Wi-Fi connected but no Internet” flashcards built around failure boundaries
Filter by association boundary, DHCP, gateway, remote IP, DNS, NAT, firewall, captive portal, scope, evidence, troubleshooting, or verification. Click—or press Enter/Space—to reveal the answer.