Apple CNA, Android Connectivity Check, Microsoft NCSI: Cómo funciona realmente la detección de Captive Portal

Apple CNA, Android Connectivity Check, Microsoft NCSI: How Captive Portal Detection Actually Works A Purple WiFi Technical Briefing --- INTRODUCTION AND CONTEXT — approximately 1 minute Welcome to the Purple Technical Briefing series. I'm your host, and today we're getting into something that sits at the very heart of every guest WiFi deployment — captive portal detection. Specifically, we're looking at how Apple, Android, and Windows each decide, the moment a device joins your network, whether a captive portal is present and whether they should show it to the user. This matters enormously in practice. Get it wrong, and your guests connect to the network but never see the splash page. Or they see it twice. Or Windows loops endlessly on the sign-in prompt. These are real, recurring support tickets across hotels, stadiums, retail chains, and conference centres. And the root cause, almost every time, is a misconfigured walled garden or a misunderstanding of how these three OS families actually behave differently from one another. So let's get into it. --- TECHNICAL DEEP-DIVE — approximately 5 minutes Let's start with Apple, because Apple's Captive Network Assistant — the CNA — is probably the most widely discussed and the most frequently misunderstood. When an Apple device, whether that's an iPhone, iPad, or Mac, joins a new WiFi network, the operating system immediately fires off an HTTP GET request. On modern iOS and macOS, that probe goes to captive.apple.com, specifically the path /hotspot-detect.html. The device is expecting a very specific response: an HTTP 200 with a body that reads, verbatim, "Success" wrapped in basic HTML tags. If it gets that exact response, the OS concludes it has full internet access and does nothing further. No portal, no pop-up. But if the response is anything other than that — a redirect, a different body, a timeout — the CNA kicks in. It opens what Apple calls WebSheet, which is a sandboxed mini-browser. Not Safari. Not Chrome. A locked-down browser window that has no access to Safari extensions, cannot save passwords, and on macOS is fixed at roughly 900 pixels wide. This is important for portal designers: your splash page must render correctly in that constrained environment. Now here's the first critical nuance. The CNA probe is HTTP, not HTTPS. If your captive portal gateway intercepts that probe and redirects it to an HTTPS URL, the CNA will not handle it gracefully. The user will see a certificate warning, or the portal simply won't open. Your redirect must stay on HTTP port 80 for the initial probe interception. The second nuance: if your walled garden passthrough list includes captive.apple.com and allows it to reach the real Apple server, the device will get the genuine "Success" response, conclude it has internet, and never show the portal. This is a classic misconfiguration — operators add captive.apple.com to their passthrough list thinking they're helping, but they're actually bypassing their own portal. Apple has also been rolling out support for RFC 8910, the Captive Portal API, which uses DHCP option 114 to signal portal presence positively rather than relying on probe interception. iOS 16 and later support this. It's a cleaner mechanism, but it requires your DHCP server or access point to advertise the option — something most legacy deployments don't yet do. Now let's move to Android. Android's connectivity check works on a fundamentally different principle. Instead of expecting a specific body text in an HTTP 200 response, Android expects an HTTP 204 — that's 204 No Content. The primary probe URL is connectivitycheck.gstatic.com/generate_204. Secondary probes go to clients2.google.com/generate_204 and connectivitycheck.android.com. When Android fires that probe and receives a 204, it concludes: internet is available, no portal. When it receives anything else — a redirect, a 200 with content, a timeout — it flags the network as requiring sign-in and shows the user a notification: "Sign in to WiFi network." Tapping that notification opens the full Chrome browser, not a sandboxed mini-browser. This is a significant difference from Apple. Android users get the full browser experience, which means your portal can use JavaScript, cookies, and modern CSS without the constraints of CNA's WebSheet. The critical walled garden implication for Android: if you block connectivitycheck.gstatic.com entirely — don't allow it through at all — Android doesn't detect a captive portal. Instead, it shows "Connected, no internet." The user sees the WiFi icon with an exclamation mark and has no idea a portal exists. You must allow the probe URL through your walled garden but intercept it with a redirect rather than blocking it outright. Android 11 introduced support for RFC 7710 bis and the Captive Portal API via DHCP option 114, mirroring Apple's approach. If the DHCP handshake includes the API URL, Android fetches it immediately and prompts the user to log in. This is more reliable than probe interception, but again requires infrastructure support. Now, Windows. And this is where things get interesting, because Windows uses a dual-probe mechanism that trips up a lot of deployments. Windows Network Connectivity Status Indicator — NCSI — runs two checks simultaneously when a device joins a network. First, an HTTP probe: GET request to http://www.msftconnecttest.com/connecttest.txt, expecting a 200 response with the body text "Microsoft Connect Test". Second, a DNS probe: it resolves dns.msftncsi.com and expects a specific IPv6 address in response — fd3e:4f5a:5b81::1. If the HTTP probe is redirected, Windows detects a captive portal and opens the default browser — Edge, in modern deployments — pointing it at the portal URL. This part works fine. The problem is what happens after authentication. Here's the Windows looping scenario, which I see in support tickets regularly. User authenticates on the portal. The portal marks their MAC address as authorised. But Windows then re-runs its NCSI probes. If msftconnecttest.com is still being intercepted — perhaps because the gateway hasn't yet propagated the MAC authorisation — Windows concludes the portal is still active and opens the browser again. The user has to sign in a second time, or sometimes a third. This loop continues until the gateway correctly passes NCSI traffic for that client. The fix is straightforward but requires attention: ensure your gateway propagates MAC authorisation immediately and that post-auth traffic to msftconnecttest.com and dns.msftncsi.com passes through cleanly. Also worth noting: older Windows versions used www.msftncsi.com rather than msftconnecttest.com. If you're supporting Windows 7 or 8 clients — yes, they still exist in enterprise and public-sector environments — you need both domains in your walled garden. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes Let me give you the practical implementation framework. Your walled garden — the list of hosts accessible before authentication — must cover all three OS probe sets. At minimum, that means: captive.apple.com and www.apple.com for Apple; connectivitycheck.gstatic.com, clients2.google.com, and connectivitycheck.android.com for Android; and www.msftconnecttest.com, dns.msftncsi.com, and www.msftncsi.com for Windows. Do not allow these hosts to reach their real destinations. Allow the DNS resolution to succeed, but intercept the HTTP traffic and redirect it to your portal. The distinction matters: DNS must resolve, HTTP must redirect. For the portal itself, always serve the initial redirect on HTTP port 80. Your portal login page can be HTTPS — and should be, for credential security — but the initial interception and redirect must happen over HTTP. Apple's CNA will not follow an HTTPS redirect. Test with all three OS families before go-live. The most common gap I see is teams testing on their own iPhones and declaring the portal working, without ever checking Windows or Android. A quick test matrix: iPhone on iOS 16+, Android on a stock Google device, and a Windows 10 or 11 laptop. Run each one, check that the portal appears, complete authentication, and verify the device shows full internet connectivity afterwards. If you're running a Purple WiFi deployment, the platform handles walled garden configuration automatically and maintains an updated host list as Apple, Google, and Microsoft update their probe endpoints. This matters because these URLs do change — Google has updated its probe URLs across Android versions, and Microsoft shifted from msftncsi.com to msftconnecttest.com in Windows 10. --- RAPID-FIRE Q AND A — approximately 1 minute Question: My Apple users see the portal on first connect but not on reconnect. Why? Answer: iOS caches the captive portal state per SSID. Once authenticated, the device remembers that network as "internet available." If you want to re-prompt on reconnect, you need to clear the MAC authorisation on your gateway, which forces the device to re-probe. Some venues do this on a timer — say, 24 hours — for daily re-authentication. Question: Android shows "Connected, no internet" even though the portal is working for Apple users. What's wrong? Answer: Your walled garden is blocking connectivitycheck.gstatic.com rather than redirecting it. Add it to your passthrough list but ensure the gateway intercepts and redirects the HTTP traffic. Question: Can I use HTTPS for my entire portal, including the initial redirect? Answer: No. The initial interception must be HTTP. You can redirect from HTTP to HTTPS for the login page itself, but the first redirect from the probe URL must be plaintext HTTP. Otherwise Apple CNA won't trigger, and users will see certificate warnings. --- SUMMARY AND NEXT STEPS — approximately 1 minute To wrap up: Apple CNA, Android Connectivity Check, and Microsoft NCSI are three distinct mechanisms with different probe URLs, different expected responses, and different failure modes. Apple expects HTTP 200 with a specific body. Android expects HTTP 204. Windows runs a dual HTTP and DNS probe and is vulnerable to post-auth looping if your gateway is slow to propagate authorisation. Your walled garden must cover all three probe sets. Your initial redirect must be HTTP. And you should test with all three OS families before any deployment goes live. If you want to go deeper on the RFC 8910 Captive Portal API — the future of this space — or on how Purple WiFi automates walled garden management across multi-vendor infrastructure, head to purple.ai. The Guest WiFi and WiFi Analytics documentation covers the full technical architecture. Thanks for listening. We'll be back with another technical briefing shortly.