Full Wi-Fi signal, but no route to the internet

Start by defining the actual boundary

A report of “Wi-Fi not working” can describe several different failures. One device may be affected while another device on the same SSID works. Local services may remain reachable while only the internet path is unavailable. A crew network may work while a guest VLAN fails in one area.

Record the client, SSID, access point or area, time, intended destination and whether the symptom is continuous or intermittent. This prevents a broad network change from being made in response to a narrow endpoint or service problem.

Test from the client outward

The most efficient order follows the path the affected traffic must take. Confirm that the client has an address, prefix, gateway and DNS servers appropriate for the intended network. Then test the local gateway. If the gateway is unreachable, the useful investigation remains onboard and local to the client, wireless association, VLAN or switching path.

If the gateway responds, test a known IP destination before testing a hostname. An IP test that succeeds while a hostname fails points toward DNS rather than general upstream loss. If both fail, continue through firewall policy, route selection, NAT and the active WAN path.

• Client lease and expected network parameters
• Reachability of the assigned gateway
• Reachability of a known IP destination
• DNS resolution using the configured resolver
• Firewall, route and current WAN state

Use comparison before configuration changes

A known-good client on the same SSID and in the same area is often more useful than a reset. Compare its address, VLAN, gateway, DNS and route behaviour with the affected client. If both clients fail, compare the access point uplink and switch-port state with a working area.

Where multiple WAN services are available, confirm which path policy intends to use and which path is actually active. A green WAN status does not by itself prove that the relevant VLAN is permitted to use it or that return traffic is following the expected route.

Record evidence before restoring service

Before changing a VLAN, restarting a gateway or forcing failover, capture enough evidence to explain the failure. Useful records include the client parameters, access point, switch path, relevant policy, active route and timestamps that can be matched with logs.

The repair is complete only when the affected service works from the intended client and location. A management interface showing healthy equipment is supporting evidence, not the acceptance test.