Why Guest Wi-Fi Exists but Still Feels Unusable

Start with the address, not the signal bars

The Wi-Fi icon confirms only that the device associated with an access point. It says nothing about whether the device received a usable IP address or whether its traffic can leave the guest segment. The fastest diagnostic is to inspect the network details on the client and look at the IP address, subnet, gateway, and DNS servers.

If the IP is missing or begins with 169.254, the failure happened at DHCP and the problem is almost certainly on the network side. If the IP looks plausible but the gateway or DNS differs from a known-working device, you have a quick clue about the broken link in the chain.

• Toggle airplane mode and reconnect to force a fresh DHCP request.
• Forget the saved network and rejoin it.
• Disable VPN and private DNS while testing.

DHCP exhaustion and guest address conflicts

Every guest device needs an address from a pool. In small deployments, the pool may simply be full, especially after many visitors have come and gone but leases have not expired. In larger venues, a single small subnet can exhaust in minutes even though the access point radios are perfectly healthy.

When a device that normally lives on the home or corporate network carries a static IP into the guest segment, the DHCP exchange can fail silently. The device associates with the SSID but keeps parameters that do not apply to the guest VLAN. Clearing the saved registration or removing the static IP and reconnecting resolves this on many consumer routers.

On access points running in bridge or switch mode, guests may be isolated from the actual internet gateway by design. In that case, verify that the guest SSID maps to the correct VLAN and that the VLAN has a reachable gateway and DHCP server.

• Compare the client subnet with the expected guest subnet.
• Remove static IP reservations for devices that will only use the guest SSID.
• Verify the DHCP scope is attached to the correct port or VLAN.

DNS: wrong resolver, same symptom as no internet

When DNS is misdirected, devices pass every other test but still cannot load a website. An older Apple support article describes a guest network whose base station was pointed at a DNS server inside the LAN. Guests could reach each other but not resolve public names, so the internet appeared broken while the radio link was fine.

The fix is to hand out an external or properly forwarding DNS server through the guest DHCP scope. Do not point guest clients at an internal resolver that cannot answer public queries, and confirm that the firewall permits DNS traffic from the guest segment to the outside.

• Set the guest DHCP scope to use a public or ISP DNS server.
• Allow outbound UDP port 53 from the guest VLAN.
• Test name resolution with a simple DNS query rather than only loading a page in a browser.

Isolation and firewall rules that cut too deep

Guest networks are isolated for security: they block access to internal resources and often block guest-to-guest traffic as well. Isolation itself does not block the internet, but an incorrect rule can accidentally sever the path to the gateway. Across multiple switches and access points, the guest VLAN must be tagged consistently everywhere.

If a captive portal uses RADIUS, a guest who sees the login page but still has no internet after signing in usually means the controller never received the authorization decision or the post-authentication rule did not open access. Check the shared secret and confirm that RADIUS ports 1812 and 1813 are reachable.

• Ensure client isolation still allows communication with the AP and gateway.
• Verify the guest VLAN tag is consistent on every trunk link.
• When using RADIUS, inspect authorization logs and post-authentication rules.

Bandwidth caps that make a working network feel broken

A network can be fully connected at the IP and DNS layers and still feel unusable because of a low throughput cap. Some router firmware applies a conservative default limit to the entire guest segment, so every visitor shares a small slice of bandwidth. The result looks like a fault even though the configuration is doing exactly what it was told.

Shared caps also create unfairness: one guest downloading a large update can consume the whole pool. Prefer a modest per-device limit over a single hard threshold for all guests, and remember that mobile clients need less bandwidth than people expect for web, email, and video calls.

• Locate the QoS or bandwidth control section for the guest SSID.
• Review the default per-segment cap if performance is unusually poor.
• Use per-device limits to prevent one guest from affecting everyone else.

Captive portal failures on modern devices

Captive portals work by intercepting an unencrypted connectivity probe and redirecting it to a login page. Modern devices increasingly resist that interception: a browser that immediately requests an HTTPS site cannot be redirected cleanly without a certificate warning. An active VPN hides the probe entirely, and private DNS bypasses the network's DNS redirection.

On the guest side, the fastest workaround is to open a plain HTTP test address in the browser, turn off VPN and private DNS until the portal loads, and reconnect to clear cached state. On the operator side, the long-term standards-based approach is to advertise the portal through DHCP in accordance with published specifications, rather than relying on fragile interception.

• Open an unencrypted HTTP probe address in the browser.
• Forget the network and reconnect to clear stale session state.
• Check that operating system probe domains are allowed before authentication.