¿Qué es un Captive Portal y cómo funciona?

What Is a Captive Portal and How Does It Work? A Purple Technical Briefing — Episode Runtime: Approximately 10 Minutes --- INTRODUCTION AND CONTEXT — approximately 1 minute Welcome. If you're responsible for a network that serves guests, visitors, or the public — whether that's a hotel, a retail estate, a stadium, or a conference centre — then captive portals are almost certainly part of your infrastructure today. And yet, in my experience advising IT teams across a range of sectors, the captive portal is one of the most misunderstood components in the entire guest WiFi stack. People know what it does — it's that login page that pops up when you connect to the WiFi at an airport or a coffee shop. But very few IT managers can tell you precisely how it works under the bonnet, why devices behave differently, or what the architectural trade-offs are when you're deploying at scale. So in the next ten minutes, I want to give you a clear, practical picture of captive portal architecture — from the initial HTTP intercept all the way through to how Purple's platform turns that authentication moment into a genuine business intelligence asset. Let's get into it. --- TECHNICAL DEEP-DIVE — approximately 5 minutes Let's start with the fundamentals. A captive portal is a network access control mechanism that intercepts a device's outbound internet traffic and redirects it to a designated web page — the splash page — before granting full network access. It creates what's commonly called a "walled garden": a restricted state where only traffic to the portal itself is permitted. Now, how does that interception actually happen? There are two primary mechanisms, and understanding the difference matters for your deployment architecture. The first is DNS hijacking. When a device connects to your access point and attempts to resolve any domain name — say, google.com — your gateway intercepts that DNS query and returns the IP address of your captive portal server instead. The device's browser then loads the portal page, believing it has reached its intended destination. This is the most widely deployed approach because it works regardless of the HTTP or HTTPS status of the destination. The second mechanism is HTTP redirect. Here, the gateway allows the DNS resolution to succeed, but intercepts the subsequent HTTP request and issues a 302 redirect response, pointing the browser to the portal URL. This approach is cleaner in terms of DNS integrity, but it has a significant limitation: it only works for plain HTTP traffic. With the near-universal adoption of HTTPS, most modern implementations combine both techniques. Now, here's where it gets technically interesting: the Captive Network Assistant, or CNA. Every major operating system — iOS, macOS, Android, and Windows — has a built-in mechanism for detecting captive portals automatically. The moment your device associates with a WiFi network, the operating system fires off an HTTP probe to a known endpoint. Apple devices probe captive.apple.com/hotspot-detect.html and expect an HTTP 200 response containing the word "Success". Android probes connectivitycheck.gstatic.com/generate_204 and expects an HTTP 204 No Content response. Windows uses its Network Connectivity Status Indicator, or NCSI, probing www.msftncsi.com/ncsi.txt. If the response doesn't match the expected value — which it won't, because your gateway has intercepted it — the operating system concludes it's behind a captive portal and automatically launches the CNA. On iOS and macOS, this is a lightweight mini-browser — sometimes called the Captive Portal Mini Browser, or CPMB — that opens as a modal overlay. On Android 11 and later, it's a dedicated captive portal handler. On Windows, it opens the default browser. This automatic detection is enormously important for user experience. Without it, users would need to manually open a browser and navigate somewhere before the portal appeared. The CNA eliminates that friction entirely. However — and this is a critical point for your implementation — the CNA mini-browser is not a full browser. It has significant limitations. There are no persistent cookies. Local storage is restricted. JavaScript support varies by OS version. The window closes automatically once authentication completes, and on iOS, it will also close if the user switches to another application mid-flow. This means your splash page design must account for these constraints. Heavy JavaScript frameworks, third-party social login SDKs, and complex redirect chains can all fail silently inside a CNA environment. Let me walk you through the complete authentication flow from a network architecture perspective. Step one: the device associates with the SSID and obtains an IP address via DHCP. At this point, the gateway places the device in an unauthenticated state — it can reach the portal server, and nothing else. Step two: the OS fires its captive portal detection probe. The gateway intercepts this and returns an unexpected response, triggering the CNA. Step three: the CNA loads the splash page. The user completes the required action — accepting terms, entering an email address, authenticating via social login, or entering a voucher code. Step four: upon successful completion, the portal server sends an authorisation signal to the gateway, typically via an API call or a RADIUS authentication message. The gateway identifies the device by its MAC address and moves it from the unauthenticated to the authenticated state. Step five: full internet access is granted. The CNA closes. The user is online. From a standards perspective, the gateway-to-portal communication is typically handled via one of three protocols. RADIUS, defined under RFC 2865, is the most mature and widely supported. WISPr — the Wireless Internet Service Provider roaming protocol — is an XML-based standard used specifically for hotspot authentication. And increasingly, modern deployments use vendor-specific REST APIs, which offer greater flexibility but require tighter integration between your portal platform and your network hardware. One more architectural consideration worth flagging: MAC address randomisation. Since iOS 14, Android 10, and Windows 10 version 2004, devices randomise their MAC address per SSID by default. This has significant implications for session management and returning visitor recognition. If your portal relies on MAC address persistence for re-authentication — allowing returning visitors to skip the portal — you need to understand that this mechanism is increasingly unreliable. Purple's platform addresses this through profile-based authentication and device fingerprinting techniques that are more resilient to MAC randomisation. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes Let me give you the practical guidance that actually matters when you're deploying this in a production environment. First: design for the CNA, not the full browser. Your splash page should be lightweight, load in under two seconds on a 3G connection, and avoid any JavaScript that requires persistent storage or cross-origin requests. Test your portal specifically inside the iOS CNA — not just in Safari — because the behaviour is materially different. Second: get your walled garden right. The walled garden is the list of domains and IP addresses that unauthenticated devices can reach before completing the portal flow. At minimum, this needs to include your portal server, your CDN endpoints, and any third-party authentication providers you're using — Google OAuth, Facebook Login, and so on. A misconfigured walled garden is the single most common cause of portal failures in enterprise deployments. If a social login provider's JavaScript SDK can't load because its CDN domain isn't whitelisted, the login button simply won't work — and users will blame the WiFi. Third: plan for HTTPS. DNS hijacking doesn't work for HTTPS destinations because the browser will throw a certificate error before the redirect can complete. Modern captive portal implementations use an HTTP-only probe domain — typically a vendor-specific endpoint — specifically to avoid this. Ensure your gateway is configured to intercept the OS probe URLs rather than relying on intercepting arbitrary HTTPS traffic. Fourth: GDPR and data compliance. If you're collecting personal data at the portal — email addresses, phone numbers, social profile data — you need explicit consent under GDPR, and that consent must be granular. Bundling marketing consent with terms of service acceptance is not compliant. Purple's platform includes configurable consent management that is purpose-built for GDPR, CCPA, and PDPA compliance, with audit trails for every consent event. Fifth: session management and bandwidth policy. Define your session timeout, idle timeout, and per-device bandwidth limits before you go live. In a hotel environment, a 24-hour session with a 10 Mbps per-device cap is a reasonable starting point. In a stadium, you'll want much shorter sessions — perhaps 4 to 6 hours — with aggressive bandwidth shaping to ensure equitable throughput across thousands of concurrent connections. The most common pitfall I see in enterprise deployments is treating the captive portal as a set-and-forget component. It isn't. OS updates — particularly iOS major releases — regularly change CNA behaviour. Apple's move to require HTTPS for captive portal detection in iOS 14 caught many operators off-guard. You need a monitoring process that validates portal behaviour after every major OS release. --- RAPID-FIRE Q AND A — approximately 1 minute Let me address a few questions I hear regularly. Can I use a captive portal with WPA2 or WPA3 encryption? Yes. The portal layer operates at the application level, above the wireless encryption layer. You can — and should — run your guest SSID with WPA2 or WPA3 Personal encryption even when using a captive portal. This protects the over-the-air traffic even before authentication completes. Does a captive portal satisfy PCI DSS network segmentation requirements? Partially. The portal enforces logical separation between guest and corporate networks, but PCI DSS requires that your cardholder data environment be on a completely separate network segment with no bridging. A captive portal alone is not sufficient — you need VLAN segmentation at the switch and controller level. What's the difference between a captive portal and IEEE 802.1X? They solve the same problem — network access control — but at different layers. 802.1X is a port-based authentication standard that operates at Layer 2, before an IP address is even assigned. Captive portals operate at Layer 7, after IP assignment. 802.1X is more secure and more seamless for corporate devices with certificates, but it requires device-side configuration. Captive portals work with any device, any OS, with zero pre-configuration — which is why they remain the dominant choice for guest access. --- SUMMARY AND NEXT STEPS — approximately 1 minute To bring this together: a captive portal is a network access control mechanism that intercepts unauthenticated traffic and redirects it to a splash page. The CNA — built into every major operating system — automates the detection and presentation of that portal. The authentication flow involves DNS interception, gateway state management, and a handoff between your portal platform and your network hardware. For Purple customers, the platform abstracts this complexity entirely. You get a drag-and-drop splash page builder, pre-built integrations with Cisco Meraki, Aruba, Ruckus, and Extreme Networks, GDPR-compliant consent management, and real-time analytics that turn every WiFi authentication event into a data point in your customer intelligence platform. If you're evaluating a captive portal deployment — or looking to migrate from a legacy solution — the three things I'd recommend you assess first are: CNA compatibility across your target device mix, your walled garden configuration, and your data compliance posture. Purple's professional services team can run a full network readiness assessment for you. The link is in the show notes. Thanks for listening. --- END OF SCRIPT