Wie funktioniert ein Captive Portal? Technischer Tiefgang

Ein umfassender technischer Einblick in die Architektur von Captive Portals, der DNS-Interception, HTTP-Weiterleitung, Walled Gardens und RADIUS-Authentifizierung für IT-Profis erklärt.

📖 7 Min. Lesezeit📝 1,564 Wörter🔧 2 Beispiele❓ 3 Fragen📚 8 Schlüsselbegriffe

🎧 Diesen Leitfaden anhören

Transkript anzeigen

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.

Wichtigste Erkenntnisse

✓Captive portals operate at Layer 3, intercepting DNS and HTTP traffic to redirect unauthenticated users to a login page.
✓The 'Walled Garden' is a critical pre-authentication whitelist; misconfiguring it breaks portal rendering and third-party logins.
✓Never attempt to intercept HTTPS traffic; rely on OS-native Captive Network Assistant (CNA) probes.
✓RADIUS provides the backbone for Authentication, Authorisation (bandwidth limits, session timeouts), and Accounting (compliance logs).
✓Cloud-hosted portal and RADIUS infrastructure provides superior scalability and centralised management compared to on-premises servers.
✓MAC address caching enables seamless roaming for returning guests by bypassing the portal via MAB (MAC Authentication Bypass).
✓Modern platforms like Purple integrate captive portal functionality with OpenRoaming/Passpoint for secure, cellular-like connectivity.

Zusammenfassung für Führungskräfte

Für IT-Manager und Netzwerkarchitekten, die öffentliche oder Unternehmens- Guest WiFi bereitstellen, ist das Captive Portal die kritische Grenze zwischen einem nicht authentifizierten Gerät und Ihrer Netzwerkinfrastruktur. Dieser Leitfaden bietet einen technischen Tiefgang in die Funktionsweise eines Captive Portals – er entfernt die Marketing-Ebene, um die zugrunde liegenden Mechanismen der DNS-Interception, HTTP-Weiterleitung, Walled Garden-Konfiguration und RADIUS-Authentifizierung zu untersuchen.

Ob Sie eine High-Density-Bereitstellung für ein Stadion, ein verteiltes Netzwerk für den Retail oder eine konforme Lösung für das Healthcare entwerfen, das Verständnis des Sitzungslebenszyklus und der architektonischen Abhängigkeiten ist unerlässlich. Ein falsch konfiguriertes Portal führt zu einer verschlechterten Benutzererfahrung, Browser-Sicherheitswarnungen und potenziellen Compliance-Fehlern. Dieser Referenzleitfaden beschreibt die technische Architektur, Best Practices für die Implementierung und häufige Fehlerursachen, um sicherzustellen, dass Ihre Bereitstellung sicher, skalierbar und konform mit modernen Standards wie WPA3 und Passpoint ist.

Technischer Tiefgang

Im Kern ist ein Captive Portal ein Layer-3-Netzwerkzugriffssteuerungsmechanismus. Es fängt den Datenverkehr von einem verbundenen, aber nicht authentifizierten Gerät ab und leitet den Benutzer zu einer Authentifizierungsschnittstelle um, bevor der vollständige Netzwerkzugriff gewährt wird.

Der Prozess basiert auf einer koordinierten Abfolge von Netzwerkdiensten:

1. Assoziation und IP-Zuweisung Wenn sich ein Gastgerät mit der SSID verbindet, überbrückt der Wireless Access Point oder Controller die Verbindung zu einem bestimmten VLAN. Der lokale DHCP-Server weist eine IP-Adresse, Subnetzmaske und ein Standard-Gateway zu. In diesem Stadium ist das Gerät auf Layer 2 verbunden, befindet sich aber auf Layer 3 in einem „vorauthentifizierten“ Zustand. Der gesamte ausgehende Datenverkehr unterliegt strengen Zugriffssteuerungslisten (ACLs), die vom Network Access Server (NAS), typischerweise dem Wireless LAN Controller (WLC) oder der Edge-Firewall, durchgesetzt werden.

2. DNS-Interception (DNS-Spoofing) Um das Captive Portal auszulösen, muss das Netzwerk die anfänglichen Webanfragen des Benutzers abfangen. Wenn das Gerät versucht, einen Domainnamen aufzulösen (z. B. www.example.com), wird die DNS-Abfrage vom NAS oder einem dedizierten DNS-Server innerhalb des Walled Garden abgefangen. Anstatt die tatsächliche öffentliche IP-Adresse für die angeforderte Domain zurückzugeben, gibt der DNS-Server die IP-Adresse des Captive Portal-Servers zurück.

3. HTTP-Weiterleitung Wenn der Browser des Clients versucht, eine HTTP-Verbindung zur gefälschten IP-Adresse herzustellen, antwortet der Captive Portal-Server mit einer HTTP 302 (Found) oder HTTP 303 (See Other) Weiterleitung. Dies weist den Browser an, zur tatsächlichen URL der Captive Portal-Anmeldeseite zu navigieren.

Moderne Betriebssysteme verwenden Captive Network Assistant (CNA)-Mechanismen, um dies automatisch zu erkennen. Beim Verbinden mit einem Netzwerk sendet das Betriebssystem eine HTTP GET-Anfrage an eine bekannte Probe-URL (z. B. captive.apple.com für iOS/macOS, msftconnecttest.com für Windows). Wenn das Betriebssystem eine HTTP-Weiterleitung anstelle des erwarteten 200 OK oder einer spezifischen HTML-Nutzlast empfängt, geht es davon aus, dass ein Captive Portal vorhanden ist, und startet automatisch einen Pseudo-Browser, um die Portalseite anzuzeigen.

4. Der Walled Garden Während des vorauthentifizierten Zustands muss der Benutzer in der Lage sein, die Portalseite und die zugehörigen Assets zu laden. Der „Walled Garden“ ist eine Whitelist von IP-Adressen, Subnetzen und Domains, die auf dem NAS konfiguriert sind. Datenverkehr, der für diese Whitelist-Standorte bestimmt ist, ist erlaubt, während aller andere Datenverkehr verworfen wird. Ein korrekt konfigurierter Walled Garden muss Folgendes umfassen:

Die IP-Adresse des Captive Portal-Servers.
Content Delivery Networks (CDNs), die CSS-, JavaScript- und Bild-Assets für die Portalseite hosten.
Identitätsanbieter (z. B. Facebook, Google), wenn Social Login aktiviert ist.
Zahlungs-Gateways, wenn das Portal kostenpflichtigen Zugang erfordert.

5. Authentifizierung und RADIUS Sobald der Benutzer seine Anmeldeinformationen übermittelt oder die Nutzungsbedingungen akzeptiert, fungiert der Captive Portal-Server als RADIUS-Client. Er erstellt ein RADIUS Access-Request-Paket mit den Benutzerdetails und sendet es an den RADIUS (Remote Authentication Dial-In User Service)-Server.

Der RADIUS-Server validiert die Anfrage anhand seiner Datenbank. Bei Erfolg gibt er ein Access-Accept-Paket zurück. Entscheidend ist, dass dieses Paket anbieterspezifische Attribute (VSAs) enthalten kann, die die Sitzungsparameter definieren, wie z. B. Session-Timeout (maximale Verbindungsdauer), Idle-Timeout und Bandbreitenbegrenzungen.

6. Sitzungsaktivierung und Abrechnung Nach Erhalt des Access-Accept weist der Captive Portal-Server den NAS an, die MAC-Adresse des Clients zu autorisieren. Die Walled Garden-Beschränkungen werden aufgehoben, und dem Gerät wird voller Internetzugang gewährt. Gleichzeitig sendet der NAS ein RADIUS Accounting-Request (Start)-Paket an den RADIUS-Server, um die Sitzung für Analyse- und Compliance-Zwecke zu verfolgen.

Implementierungsleitfaden

Die Bereitstellung eines robusten Captive Portals erfordert eine sorgfältige Koordination zwischen der Wireless-Infrastruktur und der Portalplattform. Für IT-Manager, die Guest WiFi Providers: What to Look for When Choosing a WiFi Platform bewerten, sind die folgenden architektonischen Ansätze zu berücksichtigen:

Cloud-basiert vs. On-Premises Moderne Unternehmensbereitstellungen hebevorzugen stark Cloud-gehostete Portal- und RADIUS-Infrastrukturen. Plattformen wie Purple bieten eine global verteilte RADIUS-Architektur, wodurch die Notwendigkeit von lokalen AAA-Servern entfällt. Der lokale WLC leitet seine RADIUS-Authentifizierungs- und Accounting-Anfragen einfach an die Endpunkte des Cloud-Anbieters weiter. Dieser Ansatz skaliert nahtlos und zentralisiert die Verwaltung über mehrere Standorte hinweg, was besonders vorteilhaft für verteilte Gastgewerbe und Einzelhandelsumgebungen ist.

Walled Garden Konfiguration Die häufigste Ursache für Probleme bei der Portal-Darstellung ist ein unvollständiger Walled Garden. Moderne Webseiten sind stark auf externe Ressourcen angewiesen. Wenn eine Schriftart oder eine JavaScript-Bibliothek, die auf einem Drittanbieter-CDN gehostet wird, blockiert ist, kann das Portal hängen bleiben oder im OS's CNA-Browser falsch dargestellt werden.

Empfehlung: Verwenden Sie domänenbasierte Walled Garden-Einträge, sofern von Ihrem WLC unterstützt (z.B. *.purple.ai). Wenn Ihre Hardware nur IP-basierte Walled Gardens unterstützt, müssen Sie eine aktualisierte Liste der IP-Subnetze des Portal-Anbieters pflegen.

Umgang mit HTTPS-Abfangen Historisch gesehen haben Captive Portals den gesamten Port 80 (HTTP) und Port 443 (HTTPS) Verkehr abgefangen. Mit der weit verbreiteten Einführung von HTTP Strict Transport Security (HSTS) führt das Abfangen von HTTPS-Verkehr jedoch dazu, dass Browser schwerwiegende Sicherheitswarnungen anzeigen, da das SSL-Zertifikat des Portals nicht mit der angeforderten Domain übereinstimmt.

Empfehlung: Fangen Sie niemals HTTPS-Verkehr ab. Verlassen Sie sich vollständig auf die OS-nativen CNA-Mechanismen (die über HTTP prüfen) oder weisen Sie Benutzer explizit an, zu einer bekannten HTTP-URL (z.B. http://neverssl.com) zu navigieren, um die Weiterleitung auszulösen.

Best Practices

1. MAC-Adress-Caching für nahtloses Roaming Um die Benutzererfahrung zu verbessern, implementieren Sie MAC-Adress-Caching. Wenn sich ein Benutzer erfolgreich authentifiziert, speichert der RADIUS-Server seine MAC-Adresse. Wenn der Benutzer die Verbindung trennt und innerhalb eines bestimmten Zeitfensters (z.B. 30 Tage) zurückkehrt, sendet der WLC eine MAC Authentication Bypass (MAB)-Anfrage an den RADIUS-Server. Der Server erkennt die MAC-Adresse und gibt sofort ein Access-Accept zurück, wodurch der Netzwerkzugriff gewährt wird, ohne dass der Benutzer erneut mit dem Portal interagieren muss.

2. Design für den Captive Network Assistant (CNA) Die von iOS und Android gestarteten Pseudo-Browser zur Anzeige von Captive Portals haben im Vergleich zu vollwertigen Browsern eine eingeschränkte Funktionalität. Sie unterstützen oft keine Pop-ups, haben strenge Timeout-Beschränkungen und behandeln Cookies anders.

Empfehlung: Halten Sie die Portal-Benutzeroberfläche schlank. Vermeiden Sie komplexe JavaScript-Frameworks oder große Mediendateien, die dazu führen könnten, dass der CNA ein Timeout erhält. Wenn Sie komplexe Interaktionen (wie App-Downloads) benötigen, verwenden Sie das Portal, um das Gerät zuerst zu autorisieren, und leiten Sie den Benutzer dann zu seinem nativen Browser weiter.

3. Integration mit OpenRoaming und Passpoint Während Captive Portals für die Datenerfassung und die Akzeptanz von Bedingungen unerlässlich bleiben, bewegt sich die Branche hin zu nahtlosen Authentifizierungsstandards wie Passpoint (Hotspot 2.0). Purple fungiert als kostenloser Identitätsanbieter für Dienste wie OpenRoaming unter der Connect-Lizenz. Geräte, die mit einem OpenRoaming-Profil konfiguriert sind, können sich sicher auf Layer 2 (über 802.1X/EAP) authentifizieren, ohne mit einem Captive Portal zu interagieren, was ein zellulares Roaming-Erlebnis bietet. Ihre Infrastruktur sollte beide Mechanismen gleichzeitig unterstützen.

Fehlerbehebung & Risikominderung

Symptom: Die Portalseite erscheint nicht automatisch auf mobilen Geräten.

Grundursache: Der Walled Garden ist falsch konfiguriert, wodurch die CNA-Probe-Anfragen des Betriebssystems direkt das Internet erreichen können. Wenn das Betriebssystem ein 200 OK von captive.apple.com erhält, geht es davon aus, dass es vollen Internetzugang hat und startet das Portal nicht.
Abhilfe: Stellen Sie sicher, dass die CNA-Probe-Domains nicht im Walled Garden auf der Whitelist stehen. Sie müssen abgefangen und zum Portal-Server umgeleitet werden.

Symptom: Benutzer sehen eine SSL/TLS-Zertifikatswarnung.

Grundursache: Der WLC versucht, HTTPS-Verkehr abzufangen und präsentiert das SSL-Zertifikat des Portals anstelle des Zertifikats für die vom Benutzer angeforderte Domain.
Abhilfe: Deaktivieren Sie die HTTPS-Weiterleitung auf dem WLC.

Symptom: Social Login (z.B. Facebook, Google) lädt nicht oder authentifiziert nicht.

Grundursache: Die erforderlichen Domains für den OAuth-Flow des Identitätsanbieters fehlen im Walled Garden.
Abhilfe: Überprüfen Sie die Walled Garden-Konfiguration anhand der aktuellen Dokumentation des Identitätsanbieters. Beachten Sie, dass sich diese IP-Bereiche und Domains häufig ändern.

ROI & Geschäftsauswirkungen

Ein Captive Portal ist nicht nur eine technische Notwendigkeit; es ist ein strategischer Vorteil. Durch den Ersatz generischer Pre-Shared Keys (PSKs) durch ein verwaltetes Portal erreichen Organisationen:

Datenerfassung und Marketing-Automatisierung: Die Integration des Portals mit einer WiFi Analytics -Plattform ermöglicht es Veranstaltungsorten, verifizierte Erstanbieterdaten (E-Mails, Demografie) im Austausch für den Zugang zu sammeln. Diese Daten speisen CRM-Systeme und zielgerichtete Marketingkampagnen.
Compliance und Risikominderung: Betreiber von öffentlichem WiFi unterliegen Datenschutzgesetzen und der Haftung für Urheberrechtsverletzungen. Ein Captive Portal mit RADIUS-Accounting bietet ein auditierbares Protokoll darüber, welches Gerät (MAC-Adresse) zu einem bestimmten Zeitpunkt welche IP-Adresse hatte, wodurch der Veranstaltungsort vor Haftung geschützt wird.
Bandbreitenmanagement: Durch die Durchsetzung von RADIUS-Attributen wie Filter-Id oder WISPr-Bandwidth-Max-Down kann die IT verhindern, dass einzelne Benutzer die WAN-Verbindung monopolisieren, wodurch ein konsistentes Erlebnis für alle Gäste gewährleistet und kritischer Back-Office-Verkehr geschützt wird. Dies ist besonders relevant bei der Bewertung von Die zentralen SD WAN Vorteile für moderne Unternehmen .

Schlüsselbegriffe & Definitionen

Walled Garden

An access control list (ACL) applied to unauthenticated users, permitting traffic only to specific IP addresses or domains required to load the captive portal.

Crucial for allowing access to CDNs, payment gateways, and social login APIs before the user is fully authorised.

RADIUS (Remote Authentication Dial-In User Service)

The industry-standard networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) management.

The captive portal server uses RADIUS to tell the wireless controller whether a user is allowed on the network and what restrictions apply.

Captive Network Assistant (CNA)

A pseudo-browser built into modern operating systems (iOS, Android, Windows) designed specifically to detect and display captive portals.

CNAs have limited functionality compared to full browsers; portals must be designed to accommodate their constraints.

MAC Authentication Bypass (MAB)

A process where the network uses a device's MAC address as its identity to authenticate against a RADIUS server without user interaction.

Used to implement 'MAC Caching', allowing returning guests to connect seamlessly without seeing the portal again.

DNS Interception / Spoofing

The process where the network intercepts a user's DNS query and returns the IP address of the captive portal server instead of the actual destination.

This is the primary mechanism used to force the user's web traffic to the portal page.

HTTP 302 Redirect

An HTTP response status code indicating that the requested resource has been temporarily moved to a different URI.

Used by the portal server to redirect the intercepted HTTP request to the actual login page URL.

Vendor-Specific Attributes (VSAs)

Custom parameters included in a RADIUS message that allow vendors to support features not defined in the base RADIUS standard.

Used to pass specific policies, like bandwidth limits or VLAN assignments, from the portal platform to the specific brand of wireless controller.

Passpoint (Hotspot 2.0)

A standard that enables mobile devices to automatically discover and authenticate to Wi-Fi networks securely without user interaction.

The modern alternative to captive portals for seamless roaming; platforms like Purple act as identity providers for Passpoint networks.

Fallstudien

A 500-room hotel is upgrading its guest WiFi. They want returning guests to connect seamlessly without seeing the portal again for 30 days, but they require a daily bandwidth limit of 10Mbps per device.

Configure the WLC to use external RADIUS authentication pointing to the cloud provider. 2. Enable MAC Address Caching on the RADIUS server with a 30-day retention policy. 3. Configure the portal profile to assign a RADIUS Vendor-Specific Attribute (VSA) for bandwidth limiting (e.g., WISPr-Bandwidth-Max-Down = 10000000) in the Access-Accept packet.

Implementierungshinweise: This approach balances user experience with network protection. By using MAC caching, the initial captive portal interaction is preserved for terms acceptance, while subsequent connections rely on seamless MAB (MAC Authentication Bypass) at Layer 2. The bandwidth VSA ensures the WLC enforces the limit dynamically.

A retail chain deploys a new captive portal featuring a Facebook login option. Users report that when they click the Facebook button, the page hangs indefinitely inside the captive portal pop-up.

The WLC's walled garden configuration is incomplete. The network administrator must add Facebook's required OAuth domains (e.g., graph.facebook.com, connect.facebook.net) and IP subnets to the pre-authentication ACL.

Implementierungshinweise: This is the most common failure mode in modern portal deployments. Because the device is in a pre-authenticated state, any traffic to domains not explicitly whitelisted in the walled garden is dropped. The CNA browser simply times out waiting for the Facebook API response.

Szenarioanalyse

Q1. You are deploying a captive portal at a stadium. The portal requires users to watch a 15-second video hosted on YouTube before gaining access. Users are reporting that the portal loads, but the video frame is blank. What is the most likely architectural cause?

💡 Hinweis:Consider the state of the device before it is fully authenticated and what resources it needs to access.

Empfohlenen Ansatz anzeigen

The walled garden configuration is incomplete. The network administrator must add YouTube's video delivery domains and CDNs to the walled garden ACL. Without this, the unauthenticated device cannot reach the YouTube servers to stream the video content, even though the main portal page (hosted elsewhere) loads successfully.

Q2. A client insists on intercepting all HTTPS traffic to force users to the captive portal, arguing that users rarely type 'http://' anymore. Why is this a bad idea, and what is the standard alternative?

💡 Hinweis:Think about how modern browsers handle SSL/TLS certificates and HSTS.

Empfohlenen Ansatz anzeigen

Intercepting HTTPS traffic requires the wireless controller to present a certificate for the requested domain (e.g., google.com). Since the controller does not possess Google's private key, the browser will flag the connection as insecure and display a severe certificate warning, breaking the user experience. The standard alternative is to rely on the Operating System's built-in Captive Network Assistant (CNA), which automatically probes known HTTP URLs in the background specifically to trigger the redirect gracefully.

Q3. A venue wants to limit guest WiFi sessions to 2 hours. How is this enforced technically within the captive portal architecture?

💡 Hinweis:Which component is responsible for Authorisation and passing policy parameters to the network hardware?

Empfohlenen Ansatz anzeigen

This is enforced via RADIUS. When the captive portal server successfully authenticates the user, it receives an Access-Accept packet from the RADIUS server. This packet includes a 'Session-Timeout' attribute set to 7200 seconds (2 hours). The wireless controller reads this attribute, applies the timer to the user's session, and automatically disconnects the device when the timer expires.