Captive Portal Architecture: Security, Redirection, and Best Practices

Speak in British English with a confident, authoritative, and conversational tone - like a senior network consultant briefing a client over a coffee. Measured pace, clear diction, no rush. Occasional natural pauses for emphasis. Professional but not stiff: Welcome to the Purple Technical Briefing. I'm your host, and today we're going deep on captive portal architecture - specifically the security model, the redirection mechanics, and the design decisions that separate a compliant, well-engineered deployment from one that will cause you problems at three in the morning. [medium pause] Let's set the scene. You're running guest WiFi across a hotel chain, a retail estate, or a stadium. Thousands of devices connect every day. Some of those devices are carrying malware. Some of those users will attempt to access content they shouldn't. And your legal team wants to know, in writing, that you've captured valid consent before you store a single byte of personal data. [medium pause] That's the problem captive portal architecture is designed to solve. Let's unpack how it actually works. [medium pause] Section one. The redirection chain. When a guest device connects to your WiFi SSID, it gets an IP address from a DHCP pool on a dedicated guest VLAN - let's call it VLAN 20. Your corporate devices are on VLAN 10. These two VLANs must never route to each other. That's non-negotiable from a PCI DSS standpoint, and frankly from a basic security standpoint too. Now, the device is connected, but it hasn't authenticated yet. The controller puts it in what we call a pre-authentication state. The device can only reach a small whitelist of domains - the walled garden. Everything else gets intercepted. Here's the clever bit. When the device tries to load a web page - or when the operating system performs its captive portal detection check, which iOS does automatically by hitting captive.apple.com - the DNS resolver on the gateway returns the IP address of the captive portal server instead of the real destination. The browser follows that redirect and lands on your splash page. [medium pause] This is Layer 3 and Layer 7 working together. The VLAN handles the network isolation. The DNS intercept handles the redirect. And the captive portal handles the identity and consent layer. Three distinct mechanisms, all working in sequence. [medium pause] Section two. Authentication and RADIUS. Once the guest interacts with the splash page - whether that's accepting terms and conditions, entering an email address, authenticating via social login, or verifying an SMS code - the platform needs to tell the network controller to open the firewall for that specific device. This is where RADIUS comes in. RADIUS stands for Remote Authentication Dial-In User Service. It's a protocol defined in RFC 2865, and it's the industry standard for communicating authentication decisions between a policy server and a network access device. Purple operates as a cloud-hosted RADIUS server. When a guest completes the captive portal flow, Purple sends a RADIUS Access-Accept message to the local WiFi controller - whether that's a Cisco Meraki, an HPE Aruba controller, a Ruckus SmartZone, or a Juniper Mist access point. The controller receives that message and transitions the guest device from the pre-authentication state to the authorised state, opening the firewall rules and granting internet access. [medium pause] There's an important extension to RADIUS you should know about: Change of Authorisation, or CoA. CoA allows the RADIUS server to send a mid-session message to the controller to revoke or modify a session that's already active. Purple uses CoA to enforce session timeouts, to disconnect devices that have been flagged for policy violations, and to support right-to-erasure workflows under GDPR - where a user requests deletion of their data, and Purple can immediately revoke their active session. [medium pause] Section three. The walled garden. The walled garden is a whitelist of IP addresses and domain names that unauthenticated devices can reach before they've completed the captive portal flow. Get this wrong, and your splash page won't load. Get it very wrong, and you've created a security gap. At a minimum, your walled garden needs to include the captive portal URL itself, any CDN endpoints serving the portal's assets, and the authentication endpoints for any social login providers you're using - Google, Facebook, Microsoft. If you're using SMS verification, you'll need to whitelist the SMS gateway's API endpoint. The trap that catches most deployments is dynamic IP addresses. Cloud services don't always have static IPs. If you whitelist an IP rather than a domain, and that IP changes, your portal breaks. Use domain-based whitelisting where your controller supports it, and test after every change. [medium pause] Section four. Security design. Let's talk about the security architecture in more detail, because this is where most deployments have gaps. First: client isolation. Enable it. This is a setting on the access point that prevents guest devices from communicating directly with each other over the wireless medium. Without it, a compromised device on your guest network can probe and attack other guest devices. It's a one-tick-box fix that eliminates an entire class of peer-to-peer attack. Second: DHCP lease times. In a high-turnover venue - a transport hub, a stadium, a busy retail store - you need short lease times. Thirty to sixty minutes. If you leave the default at twenty-four hours and you have ten thousand devices connecting on a match day, you will exhaust your IP address pool before half-time. New devices won't connect. Your operations team will get complaints. Keep leases short. Third: encryption. Your captive portal must be served over HTTPS with a valid TLS certificate. If it's served over HTTP, modern browsers will flag it as insecure, users will distrust it, and you're transmitting credentials in plaintext. Use TLS 1.2 at minimum; TLS 1.3 is preferred. The WiFi transport layer should use WPA2-AES or WPA3 - never WEP, never TKIP. Fourth: VLAN segmentation. Your guest VLAN must be completely isolated from any network segment that touches payment card data. PCI DSS version 4.0 is explicit on this. If your guest network can route to a subnet containing a point-of-sale system, your entire POS network is in scope for a PCI audit. That's a significant compliance burden. Segment correctly from day one. [medium pause] Section five. GDPR and data compliance. Every captive portal that collects personal data - and email address, phone number, and social login all count as personal data under GDPR - must meet specific requirements. You need a lawful basis for processing. For guest WiFi, that's typically consent. The consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count. Bundling WiFi consent with marketing consent doesn't count. Purple's conscious-choice opt-in model separates network access consent from marketing consent, so guests can get online without being forced to accept marketing emails. You need to document what data you collect, why you collect it, where it's stored, and how long you retain it. Purple is ISO 27001 certified, GDPR compliant, CCPA compliant, and Cyber Essentials certified. The platform stores data in compliant data centres with documented retention policies. And you need a right-to-erasure workflow. If a guest requests deletion of their data, you must be able to action that within thirty days. Purple's platform supports this natively, and the RADIUS CoA mechanism I mentioned earlier means you can revoke active sessions at the same time. [medium pause] Now let's move to implementation recommendations and the pitfalls we see most often. [medium pause] Pitfall one: misconfigured walled gardens. The splash page loads, but the social login button doesn't work. Or the page loads but the logo doesn't appear because the CDN domain isn't whitelisted. Test your walled garden on a fresh device with no cached DNS before you go live. Pitfall two: shared PSKs. Some venues still use a single WiFi password written on a chalkboard. That's not a captive portal - that's a shared secret that anyone can photograph and share. It gives you no identity data, no consent record, and no ability to revoke individual access. Replace it with a managed captive portal. Pitfall three: insufficient DHCP pool sizing. I've covered this, but it bears repeating. Size your DHCP pool for peak concurrent connections, not average connections. In a stadium with forty thousand fans, you might have twenty thousand devices trying to connect simultaneously. Plan accordingly. Pitfall four: no session timeout. Without a session timeout, a device that connected six months ago and never returned still holds an authorised session state in your controller. That's a stale record that wastes resources and creates audit noise. Set session timeouts. Thirty minutes of inactivity is a reasonable default. [medium pause] Rapid-fire Q and A. Question: Does captive portal work on all devices? Answer: Modern operating systems - iOS, Android, Windows, macOS - all have captive portal detection built in. They detect the redirect and present the portal automatically. Older devices may require the user to open a browser manually. Purple's platform handles both flows. Question: Can we use captive portal alongside 802.1X? Answer: Yes. Many enterprise deployments use 802.1X for staff devices - where certificates or credentials authenticate automatically - and a captive portal for guest devices on a separate SSID. Purple integrates with RADIUS infrastructure that supports both flows simultaneously. Question: What about OpenRoaming? Answer: OpenRoaming is a standard that allows devices to connect to WiFi automatically using certificate-based authentication, bypassing the captive portal entirely. Purple acts as a free identity provider for OpenRoaming under the Connect licence. It's the future direction for seamless guest connectivity, but captive portals remain the standard for data capture and consent management today. [medium pause] To summarise. A well-architected captive portal deployment rests on five pillars. VLAN isolation to protect your corporate network. DNS interception and HTTPS redirection to present the splash page. RADIUS authentication to open the firewall after consent. A correctly configured walled garden to ensure the portal loads reliably. And GDPR-compliant data handling to protect both your guests and your organisation. Purple's platform handles all five layers across 80,000 live venues, with 440 million logins processed in 2024 and 99.999% uptime. It integrates natively with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet - so whatever hardware you're running, you can deploy without ripping and replacing. If you want to go deeper on any of these topics - SSID design, RADIUS configuration, or GDPR compliance workflows - visit purple.ai for the full technical guide library. Thanks for listening.