Captive Portal কিভাবে কাজ করে? প্রযুক্তিগত গভীর বিশ্লেষণ

How Does a Captive Portal Work? A Technical Deep Dive A Purple WiFi Intelligence Briefing [INTRODUCTION — approximately 1 minute] Welcome to the Purple Technical Briefing series. I'm your host, and today we're going deep on captive portals — specifically, how they actually work under the hood. Not the marketing version. The real version: DNS interception, HTTP redirects, walled garden configuration, RADIUS authentication, and session lifecycle management. If you're an IT manager, network architect, or CTO responsible for guest WiFi at a hotel, retail estate, stadium, or public-sector venue, this is the briefing you need before you sign off on your next deployment. We'll cover the full technical stack, the common failure modes, and where platforms like Purple fit into the picture. Let's get into it. [TECHNICAL DEEP-DIVE — approximately 5 minutes] So, how does a captive portal work? At its most fundamental level, a captive portal is a network access control mechanism that intercepts a guest device's internet traffic and redirects it to an authentication or registration page before granting full network access. Simple concept. Complex implementation. Let's walk through the full sequence, step by step. Step one: Association and DHCP. When a guest device connects to your SSID — your guest WiFi network — the access point assigns it an IP address via DHCP, just as you'd expect. At this point, the device has a valid IP address and a default gateway, but it cannot reach the internet. The network is in a pre-authenticated state. The device is associated, but not yet authorised. Step two: DNS interception. Here's where it gets interesting. When the guest device tries to resolve any domain name — let's say it's trying to reach google.com — the DNS query is intercepted by the captive portal system. The DNS server in the walled garden responds with the IP address of the captive portal server, not the actual IP of google.com. This is sometimes called DNS spoofing, though in this context it's entirely intentional and controlled. Every DNS query, for any domain, returns the same answer: the portal's IP address. Step three: HTTP redirect. The guest device's browser then attempts to connect to what it thinks is google.com, but it's actually connecting to the captive portal server. The portal server issues an HTTP 302 redirect — a standard redirect response — pointing the browser to the portal's login or registration page. Modern operating systems, including iOS, Android, Windows, and macOS, have built-in captive portal detection mechanisms. They periodically probe known URLs — Apple uses captive.apple.com, Microsoft uses msftconnecttest.com — and when they detect a redirect rather than the expected response, they automatically launch the captive portal browser window. This is the little pop-up you see on your phone when you connect to airport WiFi. Step four: The walled garden. While the guest is in this pre-authenticated state, the network enforces what's called a walled garden — a set of IP addresses and domains that are accessible without authentication. This typically includes the captive portal server itself, any CDN resources the portal page needs to load, and potentially partner domains. For example, a hotel might whitelist their loyalty programme's domain so returning members can authenticate via their existing account. The walled garden is configured at the access controller or firewall level, using ACLs — access control lists — that permit traffic to whitelisted destinations while blocking everything else. Step five: Authentication and RADIUS. When the guest submits their credentials — whether that's a social login, an email address, a voucher code, or a terms-of-service acceptance — the captive portal server processes that submission and communicates with a RADIUS server. RADIUS stands for Remote Authentication Dial-In User Service, and it's the industry-standard AAA protocol — Authentication, Authorisation, and Accounting. The portal server sends a RADIUS Access-Request packet containing the user's credentials. The RADIUS server validates those credentials against its user database or an external identity provider, and responds with either an Access-Accept or an Access-Reject. If accepted, the RADIUS server can also return authorisation attributes — things like session timeout, bandwidth limits, and VLAN assignment — as RADIUS attributes in the Access-Accept packet. Step six: MAC authorisation and session activation. Once the RADIUS server returns an Access-Accept, the captive portal system instructs the access controller to authorise the guest device's MAC address. From this point, the device's traffic is no longer intercepted. The walled garden is lifted for that specific MAC address, and the device has full internet access — subject to any bandwidth or time limits specified in the RADIUS attributes. The RADIUS server also starts an Accounting session, recording the session start time, the device's MAC address, and the assigned IP. This accounting data is critical for compliance, particularly under GDPR and the EU's data retention requirements for public WiFi operators. Step seven: Session lifecycle and expiry. Sessions don't last forever. The RADIUS Access-Accept typically includes a Session-Timeout attribute, which defines the maximum session duration. When that timer expires, the access controller sends a RADIUS Disconnect-Request, the MAC address is de-authorised, and the device is returned to the pre-authenticated state. The guest will need to re-authenticate. Some deployments use MAC address caching to remember returning devices, allowing them to bypass the portal for a configurable period — typically 24 hours or 30 days — which significantly improves the returning guest experience. Now, a word on HTTPS and the modern challenge. As HTTPS adoption has become near-universal, the traditional HTTP interception model has become more complex. Browsers now enforce HSTS — HTTP Strict Transport Security — which means they refuse to connect to HTTPS sites over plain HTTP. This is why captive portal detection relies on specific HTTP probe URLs rather than intercepting arbitrary HTTPS traffic. If your portal is intercepting HTTPS traffic and presenting a self-signed certificate, you will generate browser security warnings — which is a terrible user experience and a potential compliance issue. The correct approach is to ensure your portal operates on a properly signed domain with a valid TLS certificate, and that your captive portal detection relies on the OS-native probe mechanism rather than HTTPS interception. [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — approximately 2 minutes] Right, let's talk about what actually goes wrong in production deployments, and how to avoid it. The most common failure mode is walled garden misconfiguration. If your portal page loads external resources — JavaScript libraries, fonts, images from a CDN — and those CDN domains aren't in your walled garden, the portal page will fail to render correctly for unauthenticated users. Always audit every external resource your portal page loads and ensure those domains are whitelisted. This is particularly important if you're using a third-party portal platform like Purple, where the portal page may be served from a cloud CDN. The second common issue is iOS Captive Network Assistant conflicts. Apple's CNA — the pop-up browser that iOS uses for captive portal authentication — has significant limitations. It doesn't support all JavaScript features, it doesn't persist cookies in the same way as Safari, and it has strict timeout behaviour. If your portal relies on complex JavaScript flows or OAuth redirects, you may find that iOS users have a degraded experience. The solution is to design your portal with CNA limitations in mind, or to implement a redirect to the device's native browser after the initial detection. Third: RADIUS timeout and failover. In high-density environments — a stadium with 50,000 concurrent sessions, for example — your RADIUS infrastructure needs to be sized accordingly. A RADIUS server that's overwhelmed will cause authentication timeouts, which manifest to the end user as a portal that appears to hang. Implement RADIUS redundancy with primary and secondary servers, and configure appropriate retry and timeout values on your access controllers. Fourth: GDPR and data retention compliance. Under GDPR, if you're collecting personal data at the portal — email addresses, social login data — you need a lawful basis, a privacy notice, and a data retention policy. The ICO in the UK and equivalent authorities across the EU take WiFi data collection seriously. Platforms like Purple handle this at the platform level, providing built-in consent management, data subject access request tooling, and configurable retention policies. But you need to ensure your portal configuration actually enforces those policies — don't assume it's handled automatically without verifying. [RAPID-FIRE Q&A — approximately 1 minute] Let me run through some questions I get asked regularly. "Can a captive portal work with WPA3?" Yes. WPA3 handles the wireless encryption layer independently of the captive portal authentication layer. You can run a captive portal on a WPA3-protected SSID. The portal handles network access control; WPA3 handles over-the-air encryption. "Do captive portals work on 5G devices?" Yes, with caveats. Devices that support 5G Passpoint or OpenRoaming may bypass the captive portal entirely if they have a valid Passpoint credential. This is by design — Passpoint is intended to provide seamless authentication. If you want to enforce portal authentication for all devices, ensure your SSID is not advertising Passpoint support unless you intend it. "What's the difference between a captive portal and 802.1X?" 802.1X is a port-based network access control standard that authenticates devices before they're granted any network access at the Layer 2 level. Captive portals operate at Layer 3 and above — the device gets an IP address first, then is redirected. 802.1X is typically used for corporate networks with managed devices; captive portals are used for guest networks with unmanaged devices. [SUMMARY AND NEXT STEPS — approximately 1 minute] To summarise: a captive portal works through a coordinated sequence of DNS interception, HTTP redirection, walled garden enforcement, RADIUS authentication, and MAC-based session management. Each component needs to be correctly configured for the system to work reliably at scale. For IT teams evaluating or deploying guest WiFi, the key decisions are: cloud-hosted versus on-premises portal infrastructure, RADIUS architecture and redundancy, walled garden configuration management, and compliance tooling for GDPR and data retention. Purple's guest WiFi platform handles all of these layers — from the captive portal server and RADIUS integration through to analytics, marketing automation, and compliance management — across more than 80,000 venues globally. If you're planning a deployment or evaluating your current setup, the Purple team can provide a technical architecture review. Links to the full written guide, architecture diagrams, and implementation checklists are in the show notes. Thanks for listening.