Troubleshooting Public WiFi: Fixing 'Connected, No Internet' and Splash Page Redirection Failures

Welcome to this technical briefing from Purple. 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 will 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 start with the mechanics. Most people think of a captive portal 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 307 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 Network 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. Now let us talk implementation. What does a well-configured captive portal deployment actually look like in practice? 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 fully qualified domain name 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. Let me give you two real-world scenarios that illustrate these principles. Scenario one: a 350-room hotel in central London. The property ran a single slash-24 subnet for guest WiFi. During a large conference, 400 delegates arrived simultaneously. Within 20 minutes, the DHCP pool was exhausted. Guests reported being connected but unable to reach the portal or the internet. The immediate fix was to extend the subnet to slash-22, giving 1,022 usable addresses, and to reduce the lease time from 24 hours to 8 hours. The longer-term fix was to implement Purple's cloud-managed captive portal, which monitors DHCP pool utilisation in real time and alerts the network team before exhaustion occurs. Portal failure rate dropped to near zero within 48 hours of the change. Scenario two: a major retail chain with 200 stores. The chain used social login via Google and Facebook on their guest portal. After Google updated its OAuth infrastructure, the new authentication domains were not in the walled garden. Guests could reach the portal page but the social login buttons produced blank screens. The chain's IT team spent two days diagnosing the issue before identifying the walled garden gap. The fix took 10 minutes once identified. The lesson: never hardcode IP addresses in your walled garden for cloud-based OAuth providers. Use wildcard domain entries and review them quarterly. Now for some rapid-fire questions we hear regularly from venue IT teams. Why does the portal work on iPhones but not on Android devices? 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. A guest says the portal loaded but they cannot get online after logging in. 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. How do we handle guests who keep getting logged out after a few minutes? 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. To summarise the key points from today's briefing. Guest WiFi captive portal failures fall into six categories: DHCP pool 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. Purple operates across 80,000 venues and has processed 440 million logins in 2024 alone. We have seen every failure mode described in this briefing - and built the tooling to prevent them. If you want to explore how Purple's cloud overlay integrates with your existing Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist infrastructure, visit purple.ai or speak to your account manager. Thank you for listening.