Guest Wi-Fi Users Bypassing the Captive Portal
You deploy a captive portal on the guest SSID. Authentication is local-user with a shared guest account, portal on the guest interface, and a policy allowing guest->WAN only after auth. Users report that some devices (smart TVs, a printer) get internet without ever seeing the portal, and a few phones seem to authenticate as the shared account even after the guest password was changed. The guest VLAN is 10.20.0.0/24; the FortiGate is the gateway.
1. Why do some devices reach the internet without authenticating, and how do you enforce the portal for all of them?
Read the worked answer
Likely causes:
- MAC-based / device exemptions or a policy above the captive-portal policy that matches those devices (e.g., an allow-all guest policy, or a MAC address object bypass). Check policy order - a permit policy above the portal policy lets traffic through before authentication.
- Captive portal only intercepts HTTP/HTTPS; devices using other ports/protocols (smart TV streaming over QUIC/UDP 443, printer to cloud) bypass the redirect. If the policy permits those without auth, they flow.
Enforce: ensure the only policy from the guest VLAN requires authentication (action accept with captive-portal security mode), remove any permissive policy above it, and block/redirect non-HTTP where required. For devices that can't authenticate, either add them to an explicit, documented exemption with a dedicated policy (and restrict their destinations) or use MAC-based authentication for them - but don't leave an implicit allow-all.
2. Phones still authenticate with the shared account after the password change. What explains this and how do you fix the access model?
Read the worked answer
The shared account is the root problem: once a device authenticates, its session/IP is cached and remains valid until timeout, so changing the password doesn't revoke existing sessions. New logins with the old password should fail, so continued success implies:
- Cached authenticated sessions (auth timeout still active), or
- A second credential path (e.g., a MAC-based or cookie-based auth, or the old password is still valid on another user/group), or
- The change wasn't applied to the group the portal references.
Fix the model: replace the shared account with per-user accounts (or sponsor/self-registration), shorten auth timeouts, and enable re-authentication. Use diagnose firewall auth list to see cached sessions and clear stale ones. Per-user accounts give revocation, accountability, and prevent the "everyone is the same user" problem.