Konfiguration der Captive Portal Weiterleitung auf Enterprise-Netzwerk-Controllern

Welcome to the Purple Technical Briefing. I'm your host, and over the next ten minutes we're going straight into one of the most searched-for, least well-documented topics in enterprise WiFi: configuring captive portal redirection on network controllers. If you've ever searched for "configurar controlador portal cautivo" and come back empty-handed, this is the briefing you needed. We're covering the full picture - the technical architecture, the controller-by-controller configuration steps, the compliance requirements, and the real-world pitfalls that trip up even experienced network teams. Let's get into it. A captive portal is the mechanism that intercepts a guest device's first HTTP or HTTPS request after connecting to your WiFi network, and redirects it to a branded splash page before granting internet access. That splash page might ask for a social login, a form submission, a simple click-through acceptance of terms, or a RADIUS-backed credential check. The redirection itself is handled at the controller level - not the access point, not the firewall. The controller intercepts the unauthenticated client's traffic, applies a pre-authentication access control list - what we call a walled garden - and pushes the client's browser to your portal URL. Why does this matter commercially? Three reasons. First, compliance. Under GDPR, you are required to obtain explicit, informed consent before collecting personal data from visitors. A properly configured captive portal is your consent mechanism. Without it, you are collecting data without a lawful basis - and that is a regulatory exposure. Second, security. An open SSID with no authentication is a liability. Captive portal redirection, combined with VLAN segmentation and a RADIUS server, gives you per-session accountability. You know who connected, when, and from which device. Third, business intelligence. Every authenticated session is a first-party data point. Purple processes 440 million logins annually across 80,000 venues. That data - dwell time, visit frequency, demographic signals - is only available if your captive portal is correctly configured to capture and transmit it. Now let me walk you through the redirect flow, step by step. Step one: a guest device associates with your guest SSID. The controller assigns it an IP address via DHCP but places it in a restricted pre-authentication state. All traffic is blocked except for DNS and the walled garden domains you have explicitly permitted. Step two: the guest opens a browser. Their HTTP request hits the controller. The controller intercepts it and issues a 302 redirect to your portal URL. This is the core redirect mechanism. Step three: the guest's browser loads your splash page, hosted either on the controller itself or, more commonly in enterprise deployments, on an external cloud platform like Purple. Schritt vier: Der Gast authentifiziert sich – über Social Login, ein Formular oder Anmeldedaten. Das Portal sendet ein Autorisierungssignal zurück an den Controller, in der Regel über eine RADIUS Access-Accept-Nachricht oder einen MAC-Autorisierungs-Bypass. Schritt fünf: Der Controller verschiebt den Client aus dem Pre-Authentication-VLAN in das Post-Authentication-VLAN, entfernt die Weiterleitungsregel und gewährt Internetzugang. Dieser fünfstufige Ablauf ist bei allen gängigen Controller-Plattformen identisch. Der Unterschied liegt darin, wie Sie die einzelnen Schritte auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi und anderen konfigurieren. Gehen wir die wichtigsten Plattformen durch. Cisco Meraki. Meraki verwendet eine benutzerdefinierte Splash-Page, die vollständig über das Meraki Dashboard konfiguriert wird – es gibt kein CLI. Navigieren Sie zu Wireless, dann Access Control, wählen Sie Ihre Gäste-SSID aus, stellen Sie die Splash-Page auf "Sign-on with my RADIUS server" oder "Click-through" und geben Sie dann Ihre externe Portal-URL in das Feld Custom Splash URL ein. Der Walled Garden wird im Bereich Advanced Splash Settings konfiguriert – hier fügen Sie die IP-Adressen Ihres Portalservers hinzu, damit der Gast die Splash-Page vor der Authentifizierung erreichen kann. Die Details zum RADIUS-Server werden im RADIUS-Bereich eingetragen: Authentifizierung auf Port 1812, Accounting auf Port 1813. HPE Aruba. Unter ArubaOS konfigurieren Sie ein Captive Portal-Profil im AAA-Bereich, wobei Sie die Login-URL, die auf Ihren RADIUS-Server verweisende Servergruppe und die Weiterleitungs-URL angeben. Dieses Profil weisen Sie dann Ihrer SSID über das virtuelle AP-Profil zu. Die Pre-Authentication-Rolle – von Aruba als "Logon"-Rolle bezeichnet – enthält die ACL, die DNS, DHCP und den Zugriff auf den IP-Bereich Ihres Portalservers erlaubt. Nach der Authentifizierung weist der Controller die Rolle "authenticated" zu, die den vollen Internetzugang ermöglicht. Ruckus SmartZone verwendet für Captive Portal-Bereitstellungen einen Hotspot-WLAN-Typ. Stellen Sie unter der WLAN-Konfiguration den WLAN-Typ auf Hotspot ein, und konfigurieren Sie dann die Portal-URL, den RADIUS-Server für Authentifizierung und Accounting sowie die Walled-Garden-Einträge. Das Northbound Portal Interface verarbeitet den MAC-Autorisierungsfluss zwischen dem Portal und dem Controller. Juniper Mist nutzt einen Cloud-nativen Ansatz. Erstellen Sie unter Network und dann WLANs ein Gäste-WLAN und stellen Sie den Portal-Typ auf "External Captive Portal". Geben Sie Ihre Portal-URL ein und konfigurieren Sie die Details des RADIUS-Servers. Mist übergibt die Client-MAC, die AP-MAC und den SSID-Namen als URL-Parameter an das Portal. Ubiquiti UniFi. Navigieren Sie im UniFi Network Controller zu Settings, dann WiFi, wählen Sie Ihr Gästenetzwerk aus und aktivieren Sie unter Advanced Options die Guest Policy, um das Hotspot-Portal zu aktivieren. Stellen Sie den Portal-Typ auf "External" und geben Sie Ihre Portal-URL ein. Konfigurieren Sie den RADIUS-Server unter Profiles und dann RADIUS. Der Walled Garden ist das am häufigsten falsch konfigurierte Element bei Captive Portal-Bereitstellungen. Wenn Sie hier einen Fehler machen, sehen Ihre Gäste eine Fehlermeldung im Browser anstelle Ihrer Splash-Page. Der Walled Garden muss mindestens Folgendes zulassen: die IP-Adressen oder die Domain Ihres Portal-Servers, die IP-Adressen Ihres RADIUS-Servers, DNS-Auflösung auf Port 53 sowie DHCP auf Port 67 und 68. Wenn Ihr Portal Assets von einem CDN lädt – Schriftarten, Bilder, JavaScript –, müssen diese CDN-Domains ebenfalls im Walled Garden hinterlegt sein. Für Purple-Bereitstellungen stellen wir während des Onboardings die spezifischen IP-Bereiche und Domains für die Whitelist bereit. Die häufigste Fehlerursache ist ein Portal, das zwar den HTML-Frame lädt, aber Bilder nicht rendern oder JavaScript nicht ausführen kann, weil die CDN-Domains im Walled Garden fehlen. Hier dominieren zwei Compliance-Standards: GDPR und PCI DSS. Unter der GDPR muss Ihr Captive Portal einen klaren, spezifischen Einwilligungsmechanismus vorweisen, bevor personenbezogene Daten erfasst werden. Dies bedeutet separate, nicht vorab ausgewählte Kontrollkästchen für den WiFi-Zugang und die Marketing-Einwilligung. Sie dürfen diese nicht koppeln. Der Einwilligungsnachweis muss für Prüfungszwecke gespeichert und abrufbar sein. Die Plattform von Purple übernimmt dies automatisch und speichert die Einwilligungsnachweise für jede authentifizierte Sitzung. Unter PCI DSS muss Ihr Gäste-WiFi-Netzwerk von Ihrer Zahlungskartenumgebung isoliert sein, wenn an Ihrem Standort Kartenzahlungen verarbeitet werden. Dies erfordert ein dediziertes Gäste-VLAN mit Firewall-Regeln, die jegliches Routing zwischen dem Gästesegment und Ihrem POS-Netzwerk verhindern. PCI DSS Version 4.0, die im März 2024 verpflichtend wurde, erfordert mindestens alle sechs Monate Tests der Netzwerkersegmentierung. Lassen Sie mich Ihnen zwei konkrete Szenarien vorstellen. Szenario eins: Ein Hotel mit 350 Zimmern, das Cisco Meraki nutzt. Das Hotel möchte ein einfaches Click-Through-Portal durch ein gebrandetes Gästeerlebnis ersetzen, das E-Mail-Adressen für sein Treueprogramm erfasst. Die Konfiguration: Erstellen Sie eine dedizierte Gäste-SSID auf einem separaten VLAN mit reinem Internetzugang. Konfigurieren Sie die Meraki-Splash-Page so, dass sie auf die Portal-URL von Purple verweist. Richten Sie die RADIUS-Authentifizierung mit den RADIUS-Serverdaten von Purple ein. Konfigurieren Sie den Walled Garden mit den IP-Bereichen von Purple. Erstellen Sie im Purple-Dashboard eine gebrandete Splash-Page mit einem Formular zur Erfassung von Name, E-Mail und Zimmernummer sowie expliziten GDPR-Einwilligungskästchen. Verbinden Sie den Purple CRM-Connector mit der Marketing-Plattform des Hotels. Premier Inn hat dieses Modell in seinem gesamten Portfolio implementiert und konnte einen messbaren Anstieg der Direktbuchungsraten durch über WiFi gewonnene Gäste verzeichnen. Szenario zwei: eine regionale Einzelhandelskette mit 40 Filialen, die HPE Aruba nutzen. Der Einzelhändler benötigt ein einheitliches Gäste-WiFi-Erlebnis an allen Standorten sowie Footfall-Analysen zum Vergleich der Filialleistung. Stellen Sie Aruba Central bereit, um alle 40 Standorte über ein einziges Dashboard zu verwalten. Konfigurieren Sie eine Gäste-WLAN-Vorlage mit einem externen Captive Portal, das auf Purple verweist. Wenden Sie die Vorlage über die Gruppenrichtlinienfunktion von Aruba Central auf alle Standorte an. Konfigurieren Sie in Purple eine einzige Portalvorlage, die für alle Standorte gilt, mit standortspezifischen Analyse-Dashboards. Die Walled-Garden- und RADIUS-Konfiguration wird einmal in der Vorlage definiert und automatisch übertragen. Ergebnis: Das IT-Team verwaltet 40 Standorte über eine einzige Konsole. Das Marketing-Team erhält standortspezifische Footfall-Daten, Verweilzeit-Analysen und Raten wiederkehrender Besuche – alles über ein einziges Purple-Dashboard. Vier Fallstricke, die ich immer wieder sehe. Erstens: Fehler bei der HTTPS-Interzeption. Moderne Browser und mobile Betriebssysteme nutzen HTTPS-Probes, um Captive Portals zu erkennen. Wenn Ihr Controller den HTTPS-Traffic nicht abfangen kann – was ein gültiges Zertifikat für die Redirect-Domain erfordert –, schlägt die Probe lautlos fehl und der Gast sieht keine Weiterleitung. Die Lösung: Konfigurieren Sie die virtuelle Schnittstelle Ihres Controllers mit einem vertrauenswürdigen Zertifikat oder verwenden Sie reine HTTP-Probes auf Ihrer Gäste-SSID. Zweitens: DNS-Leakage. Wenn Ihre Pre-Authentication-ACL uneingeschränktes DNS zulässt, können Gäste DNS-Tunneling nutzen, um das Captive Portal vollständig zu umgehen. Beschränken Sie DNS ausschließlich auf Ihren zugewiesenen Resolver. Drittens: Abweichende Sitzungs-Timeouts. Wenn das Sitzungs-Timeout Ihres Controllers kürzer ist als die Gültigkeit des Sitzungs-Tokens Ihres Portals, werden Gäste mitten in der Sitzung zurück zum Portal geleitet. Gleichen Sie diese Werte an – typischerweise 24 Stunden für das Gastgewerbe und acht Stunden für den Einzelhandel. Viertens: Fehlendes Accounting. RADIUS-Accounting – die Nachrichten "Accounting-Start" und "Accounting-Stop" – teilt Ihrem Portal mit, dass eine Sitzung beendet wurde. Ohne konfiguriertes Accounting sind die Sitzungsdaten Ihres Portals ungenau und Ihre Analysen unzuverlässig. Schnelle Fragen, schnelle Antworten. Kann ich ein externes Portal mit jedem Controller verwenden? Ja, vorausgesetzt, der Controller unterstützt die Weiterleitung an ein externes Captive Portal – was alle von uns besprochenen Plattformen tun. Benötige ich einen RADIUS-Server, um ein Captive Portal zu betreiben? Nicht immer. Einfache Click-Through-Portale können den MAC-Authorisation-Bypass ohne einen vollwertigen RADIUS-Server nutzen. Für anmeldedatenbasierte oder Social-Login-Portale ist RADIUS jedoch der Standardmechanismus. Funktioniert ein Captive Portal mit WPA3? Ja. WPA3 übernimmt die Verschlüsselungsebene der drahtlosen Verbindung. Das Captive Portal übernimmt die Authentifizierungsebene. Sie arbeiten unabhängig voneinander und sind vollständig kompatibel. Wie lässt sich Purple in meinen bestehenden Controller integrieren? Purple fungiert als externer Portalserver. Sie leiten die Splash-URL Ihres Controllers auf den Portal-Endpunkt von Purple um, konfigurieren den Walled Garden mit den IP-Bereichen von Purple und richten RADIUS mithilfe der Serverdaten von Purple ein. Die Integration erfolgt nach demselben Schema, unabhängig davon, ob Sie Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist oder Ubiquiti UniFi nutzen. Zusammenfassend lässt sich sagen: Die Captive Portal-Weiterleitung wird auf Controller-Ebene und nicht auf dem Access Point konfiguriert. Die Kernkomponenten sind: die Splash-URL, die auf Ihr Portal verweist, der Walled Garden, der den Zugriff auf Ihren Portalserver ermöglicht, RADIUS für Authentifizierung und Accounting sowie die VLAN-Segmentierung zur Netzwerktrennung. Die Konfigurationsschritte unterscheiden sich je nach Anbieter, aber die Architektur ist einheitlich. Zur Einhaltung von Compliance-Richtlinien muss Ihr Portal eine GDPR-konforme Einwilligungserfassung und eine PCI-DSS-konforme Netzwerksegmentierung implementieren. WPA3 ist der aktuelle Standard für drahtlose Verschlüsselung und sollte Ihre Mindestanforderung bei jeder Neuimplementierung sein. Purple lässt sich nativ in Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet integrieren. Mit über 80.000 Standorten und 440 Millionen Logins im Jahr 2024 ist die Plattform herstellerunabhängig konzipiert – Ihre Wahl des Controllers schränkt Ihre Fähigkeit zur Erfassung von First-Party-Gästedaten oder zur Durchführung von Analysen nicht ein. Ihr nächster Schritt: Vergleichen Sie Ihre aktuelle Controller-Konfiguration mit der Checkliste für Walled Garden und RADIUS-Accounting in diesem Leitfaden. Wenn Sie ein neues Gäste-WiFi-Netzwerk einrichten, beginnen Sie mit den anbieterspezifischen Konfigurationsschritten für Ihre Controller-Plattform und binden Sie Purple als externes Portal ein. Vielen Dank fürs Zuhören. Das war das Purple Technical Briefing.