Lab 3: Wireless Clients Cannot Reach Local Resources

Scenario: Connected to Wi-Fi, Still Cannot Work

The office has a wired LAN plus two wireless networks: Office for employees and Guest for visitors. Several laptops show 'connected' but cannot print, open an internal web app, or reach shares. A wired desktop in the same room works fine. This is the classic integrated trap: connected only means the client associated to an access point (AP) and passed wireless authentication. It does not prove the right VLAN, DHCP options, name resolution, or firewall permission.

Separate the Wireless Checkpoints

Wi-Fi access is a chain. Break it into stages and identify the first one that fails.

Step 1: Which SSID?

Check which SSID each laptop joined. An employee on Guest receives a guest-subnet address and is intentionally blocked from internal printers and shares; that is guest isolation working, not a fault. The fix is simply to reconnect the user to the Office SSID, which is well within entry-level scope. If on Office, compare the IP to the expected employee subnet. A wrong subnet points to SSID-to-VLAN mapping or DHCP scope; 169.254.x.x means no DHCP; a correct IP with wrong DNS explains why printing by IP works but internal names fail.

Devices remember saved networks and silently rejoin the strongest known SSID, so a laptop that drifted onto Guest after a reboot is one of the most common real-world causes of this exact ticket.

Step 2: Radio Conditions

A weak or noisy signal (low RSSI, Received Signal Strength Indicator) causes slow throughput, drops, and failed DHCP renewals, but it usually does not move a client to a different subnet unless the client roamed to a different SSID. Ask: signal strength, distance, walls/metal shelving, microwave or Bluetooth interference, one laptop or many near one AP, better when closer? The 2.4 GHz band penetrates walls better but has only three non-overlapping channels (1, 6, 11) and more interference; the 5 GHz band is faster with more channels but shorter range.

A client stuck on a far 2.4 GHz AP through a concrete wall may associate yet renew DHCP unreliably, producing intermittent rather than total failure - a different signature from the wrong-SSID case.

Step 3: Layered Tests

Confirm SSID and security method, then check IP/mask/gateway/DNS, ping the gateway for that wireless VLAN, test the printer by IP, then by name. IP works, name fails = DNS. Gateway fails for many clients on one SSID = AP uplink, SSID-VLAN mapping, DHCP relay, or firewall policy. Wired works, wireless does not = do not declare the whole LAN down. A decisive test is to move the affected laptop to a wired jack: if it then reaches everything, the LAN, DHCP, DNS, and printer are all healthy and the fault is confined to the wireless path. That single comparison saves the next tier from investigating servers that were never broken.

Step 4: Security and Escalation

Use WPA2 or WPA3; avoid open employee networks and never reuse the Wi-Fi passphrase as an admin password. WPA3 adds protection against offline password-guessing and is preferred where every client supports it, while WPA2 with a strong passphrase remains acceptable for mixed fleets. Changing a shared SSID can disconnect every user, so document and escalate before touching business SSID settings. Escalate with SSID joined, device type and operating system, IP settings, RSSI, location, AP name or MAC address, the wired comparison result, and results by IP and by name.

If an engineer asks you to identify AP status LEDs or cable an AP per a diagram, follow the instruction and report what you observe rather than inventing configuration changes.

Why Wireless Hides So Many Layers

Wireless feels like a single thing to users - 'the Wi-Fi is broken' - but it stacks more independent layers than wired Ethernet does. Before a wireless client ever sees an IP address, it must scan for the SSID, associate to an AP, complete WPA2/WPA3 authentication, and only then run DHCP. A wired host skips the first three. That is why 'connected' is such a misleading word: it confirms only association and authentication, the two purely radio steps, and says nothing about whether the client landed in the right VLAN or got a usable lease.

Training yourself to mentally separate 'radio is up' from 'network access works' is the single most valuable habit for these tickets.

The AP's mode also changes the picture. In bridge mode the AP simply extends a VLAN onto the air, so wireless clients share the same subnet, DHCP, and gateway as wired clients on that VLAN. In router/NAT mode (common on consumer gear) the AP creates its own subnet and NATs to the office LAN, which isolates wireless clients from internal resources exactly like the rogue-router case. Knowing which mode the approved AP uses tells you immediately whether a wrong-subnet symptom is expected or a red flag. Capture the AP name or MAC in your notes so the engineer can confirm its configured mode.

Common Traps

• Assuming 'connected' equals 'has network access.'
• Blaming the whole LAN when only wireless clients fail.
• Changing a shared SSID passphrase mid-day without escalation.
• Forgetting that a saved profile can silently rejoin the wrong SSID.