Why Is My Guest WiFi Not Connecting? Troubleshooting Captive Portal Issues

TITLE: Why Is My Guest WiFi Not Connecting? Troubleshooting Captive Portal Issues FORMAT: Purple Technical Briefing Podcast VOICE: UK English - Senior Solutions Architect tone DURATION: Approximately 10 minutes --- SECTION 1: Introduction and Context - approximately 1 minute Hello, and welcome to this technical briefing from Purple. I am your host, and today we are tackling one of the most persistent, most misunderstood problems in enterprise wireless networking: the guest WiFi captive portal that simply refuses to load. You have been there. A guest arrives at your hotel, your retail store, your stadium, or your conference centre. They join the WiFi network. Nothing happens. No login page. No internet. Just a spinning icon and a growing sense of frustration. For venue operations directors and IT managers, that moment is not just a minor inconvenience. It represents a direct failure of your guest experience, a spike in front-of-house support calls, and a missed opportunity to capture the first-party data that justifies your wireless infrastructure investment. In this briefing, we are going to go under the hood. We will explain exactly how captive portal detection works at the operating system level, identify the six root causes responsible for the vast majority of connection failures, and give you a practical, actionable troubleshooting framework you can hand to your IT team today. Let us get into it. --- SECTION 2: Technical Deep-Dive - approximately 5 minutes To fix a captive portal problem, you first need to understand what a captive portal actually does at the network level. Most people think of it as simply a login page. It is actually a network-level traffic interception mechanism, and that distinction matters enormously when things go wrong. Here is the sequence. A guest's device joins your guest SSID and receives an IP address via DHCP. At that point, the operating system does not wait for the user to open a browser. In the background, a system service immediately fires off an unencrypted HTTP GET request to a vendor-controlled probe URL. Apple devices query captive.apple.com. Android devices query connectivitycheck.gstatic.com. Windows devices query msftconnecttest.com. Firefox has its own probe at detectportal.firefox.com. If the network has open internet access, these probes return their expected responses, and the operating system concludes everything is fine. But on a guest network, your wireless gateway or controller intercepts that HTTP probe before it reaches the internet. Instead of the expected response, the gateway returns an HTTP 302 redirect pointing to your captive portal splash page. The operating system detects the unexpected redirect, realises it is behind a captive portal, and opens a sandboxed browser window - often called the Captive Portal Assistant - to display the login page. That is the happy path. Now let us talk about the six ways it breaks. Root cause number one: DHCP pool exhaustion. This is the silent killer at high-density events. If you are running a conference with two thousand attendees on a standard slash-24 subnet, you have 254 usable IP addresses. If your DHCP lease time is set to the default 24 hours, you will exhaust that pool within minutes of doors opening. Every subsequent connection attempt fails before the captive portal sequence even begins. The fix is straightforward: set guest DHCP lease times to between 15 and 30 minutes for high-turnover environments, and size your subnets appropriately for peak concurrent users, not just total headcount. Root cause number two: DNS interception failure. The captive portal redirect depends on the gateway intercepting the HTTP probe. But the probe requires a DNS lookup first. If your DNS configuration does not permit pre-authenticated clients to resolve external domain names, the probe never fires. Ensure your firewall policy explicitly allows DNS queries from unauthenticated clients, and verify that your DNS interception is working by running a packet capture against a test device. Root cause number three: incomplete walled garden. The walled garden - also called the pre-authentication access control list - defines which external domains unauthenticated guests can reach. If your portal splash page loads assets from a CDN that is not in the walled garden, the page renders as a blank screen. If you offer social login via Google, Apple, or Facebook, every OAuth domain those providers use must be whitelisted. And here is the critical point: social identity providers update their CDN IP ranges and authentication domains regularly. A walled garden that worked perfectly six months ago may be silently broken today. Schedule quarterly walled garden audits and use wildcard domain snooping where your hardware supports it. On Cisco Meraki, HPE Aruba, Ruckus, and Juniper Mist, this is available natively. Root cause number four: HSTS blocking the redirect. HTTP Strict Transport Security, or HSTS, is a browser security policy that forces connections to specific domains over HTTPS only. If a guest's device attempts to contact an HSTS-preloaded domain - and that includes virtually every major website - and your gateway tries to intercept that HTTPS request to redirect to the portal, the browser detects a certificate mismatch. It presents a non-bypassable security warning and blocks the redirect entirely. The correct solution is never to attempt HTTPS interception. Your gateway should only redirect the unencrypted HTTP canary probes. The long-term standards-based fix is RFC 8910, which defines DHCP Option 114. This option allows your DHCP server to directly advertise the captive portal URL to the client device, bypassing the need for HTTP redirection entirely. iOS 14 and Android 11 and above support this natively. Root cause number five: active VPN on the guest device. A VPN encrypts all traffic from the device and routes it through an external tunnel before it reaches your gateway. Your gateway never sees the HTTP probe. The captive portal detection sequence never triggers. The guest sees no login page and no internet. The fix for the guest is simple: disable the VPN, connect to the portal, then re-enable the VPN. For your front-of-house staff, this should be the first question they ask when a guest reports a connection problem. Root cause number six: MAC address randomisation breaking session persistence. Modern iOS and Android devices use randomised MAC addresses by default as a privacy feature. Each time a device connects to a network, it may present a different MAC address. Since captive portal session state is tracked by MAC address, a guest who authenticated an hour ago may be presented with the login page again after their device's MAC rotates. The guest-facing fix is to disable Private Address for your specific SSID in the network settings. The operator-side fix is to implement profile-based authentication - such as OpenRoaming via Passpoint and 802.1X - which authenticates at Layer 2 using credentials rather than MAC addresses, making randomisation irrelevant. --- SECTION 3: Implementation Recommendations and Pitfalls - approximately 2 minutes Now that we understand the root causes, let us talk about what a well-configured captive portal deployment actually looks like. Start with your DHCP architecture. For any venue expecting more than 200 concurrent devices, move away from a single slash-24 subnet. Use slash-22 or larger, and set lease times to match your venue's dwell profile. A hotel sets leases to 8 hours. A stadium sets leases to 3 hours. A shopping centre sets leases to 90 minutes. A conference centre sets leases to 30 minutes. Next, validate your walled garden before every major event. The minimum required entries are: your portal's FQDN and all associated CDN domains, the captive portal detection URLs for Apple, Google, Windows, and Firefox, and the OAuth domains for every social login provider you support. On Purple's platform, we maintain and update these walled garden entries automatically as part of our cloud-managed service, which removes the manual maintenance burden from your team. For your portal certificate, use a publicly trusted TLS certificate from a recognised certificate authority. Self-signed certificates will trigger browser warnings on every device. Renew certificates before expiry - a lapsed certificate is one of the most common causes of sudden, venue-wide portal failures. One pitfall that catches many IT teams: testing the portal from a device that has previously authenticated. Your device's session is still active, so you bypass the portal entirely and conclude everything is working. Always test from a device in a fresh, unauthenticated state - either a new device, or one where you have forgotten the network and cleared the WiFi profile. Finally, consider the strategic direction of travel. Captive portals are a mature technology, but they carry inherent friction. OpenRoaming, built on Passpoint and 802.1X, allows returning guests to connect automatically and securely without ever seeing a login page. Purple acts as a free identity provider for OpenRoaming under our Connect plan. Venues like Premier Inn and Manchester Airports Group are already deploying this to eliminate re-authentication friction for repeat visitors while maintaining full GDPR compliance and first-party data capture. --- SECTION 4: Rapid-Fire Q and A - approximately 1 minute Let us run through the most common questions we hear from venue IT teams. Question: Why does the portal work on iPhones but not on Android devices? Answer: Android uses connectivitycheck.gstatic.com as its probe URL. If that domain is blocked by your firewall or not in your walled garden, Android devices never trigger the portal. Add it explicitly. Question: A guest says the portal loaded but they cannot get online after logging in. Answer: This is almost always a RADIUS authorisation failure. Check that your RADIUS server is reachable from the wireless controller, verify the shared secret matches on both sides, and review the RADIUS logs for Access-Reject messages. Question: How do we handle guests who keep getting logged out after a few minutes? Answer: Check your idle timeout setting. Many controllers default to a 5-minute idle timeout, which is far too aggressive for mobile devices that sleep between interactions. Set idle timeout to at least 30 minutes for hospitality and retail environments. --- SECTION 5: Summary and Next Steps - approximately 1 minute To summarise: guest WiFi captive portal failures fall into six categories - DHCP exhaustion, DNS interception failure, incomplete walled garden, HSTS redirect blocking, active VPN on the client device, and MAC address randomisation. Each has a specific, testable fix. For your IT team, the immediate actions are: audit your DHCP lease times and subnet sizing, validate your walled garden against the current OAuth domains of your social login providers, and test your portal from a fresh unauthenticated device after every configuration change. For your longer-term roadmap, evaluate OpenRoaming as the successor to captive portal re-authentication for returning visitors. The technology is mature, the standards are established under IEEE 802.1X and WPA3-Enterprise, and Purple makes it available at no additional software cost under the Connect plan. For more technical guides, case studies, and implementation resources, visit purple.ai. Thank you for listening to this Purple technical briefing. Keep your networks reliable and your guests connected.