Fehlerbehebung bei Captive Portal Weiterleitungen: Behebung von Verbindungsfehlern beim Gäste WiFi

Wenn Gäste sich mit Ihrem WiFi verbinden, aber nicht auf das Internet zugreifen können, ist die Ursache fast immer eine falsch konfigurierte Captive Portal Weiterleitung - nicht ein Hardwarefehler. Dieser Leitfaden bietet eine tiefgehende technische Referenz für IT-Manager, Netzwerkarchitekten und CTOs zur Diagnose und Behebung der gesamten Kette von Fehlern: von Verbindungstests auf Betriebssystemebene und HSTS-Zertifikatskonflikten bis hin zu RADIUS-Autorisierungslücken und DHCP-Erschöpfung. Er ordnet jedes Fehlermuster einer konkreten Lösung zu und zeigt, wie das hardwareunabhängige Cloud-Overlay von Purple diese Probleme bei Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet Bereitstellungen beseitigt.

📖 9 Min. Lesezeit📝 2,237 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 9 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

SPRECHER (BRITISCHES ENGLISCH, KOMPETENTER BERATER-TON):

Willkommen beim technischen Briefing von Purple. Heute widmen wir uns einem der hartnäckigsten Probleme in der Unternehmensvernetzung: dem Fehlschlagen der Weiterleitung zum Captive Portal. Wenn Ihre Gäste als mit dem WiFi verbunden angezeigt werden, aber kein Internetzugang besteht, sind Ihre Besucher frustriert, Ihr Helpdesk wird überrannt und Ihre Datenerfassungsstrategie kommt zum Erliegen. In diesem Briefing werden wir die technische Architektur von Captive Portals analysieren, untersuchen, warum moderne Betriebssysteme und Browser diese oft blockieren, und Ihnen konkrete Implementierungsstrategien an die Hand geben, um diese Probleme dauerhaft zu lösen.

[PAUSE]

Stellen wir uns folgendes Szenario vor. Sie haben Access Points von Cisco Meraki oder HPE Aruba an einhundert Einzelhandelsstandorten bereitgestellt. Die Hardware läuft einwandfrei. Aber Gäste beschweren sich, dass sie nicht auf das Internet zugreifen können. Sie wählen die SSID aus, ihr Gerät zeigt das WiFi-Symbol an, aber die Splash-Page erscheint nie. Oder noch schlimmer, sie sehen einen beängstigenden SSL-Zertifikatsfehler.

Warum passiert das? Es liegt daran, wie Betriebssysteme die Internetverbindung erkennen. Wenn sich ein Gerät mit einem Netzwerk verbindet, sendet es einen HTTP-Probe an eine bekannte URL. Bei iOS ist das captive.apple.com. Bei Android ist es connectivitycheck.gstatic.com. Windows verwendet msftconnecttest.com. Wenn das Gerät eine standardmäßige HTTP-200-OK-Antwort erhält, geht es davon aus, dass es direkten Internetzugang hat. Wenn das Netzwerk-Gateway diese Anfrage abfängt und mit einer HTTP-302-Weiterleitung an eine andere URL antwortet, weiß das Betriebssystem, dass es sich hinter einem Captive Portal befindet. Es öffnet dann einen Pseudo-Browser, um die Splash-Page zu laden.

Der Fehler tritt in der Regel an diesem Abfangpunkt auf.

[PAUSE]

Der erste große Fehlerpunkt ist die Prüfung des Network Connectivity Status Indicator, kurz NCSI. Wenn Ihre Firewall oder Ihr Gateway diese unverschlüsselten HTTP-Anfragen blockiert, erhält das Betriebssystem nie die 302-Weiterleitung. Es geht einfach davon aus, dass das Netzwerk fehlerhaft ist. Um dies zu beheben, müssen Sie sicherstellen, dass Ihre Access Control Lists vor der Authentifizierung den HTTP-Verkehr zu diesen spezifischen URLs zur Betriebssystem-Erkennung zulassen.

Das zweite und immer häufiger auftretende Problem ist HTTP Strict Transport Security, kurz HSTS. Moderne Browser erzwingen HTTPS für große Domains. Wenn sich ein Benutzer mit Ihrem WiFi verbindet und sofort versucht, google.com zu öffnen, besteht sein Browser auf einer verschlüsselten Verbindung. Wenn Ihr Gateway diese HTTPS-Anfrage abfängt und versucht, sie auf das Captive Portal umzuleiten, erkennt der Browser einen Man-in-the-Middle-Angriff. Das von Ihrem Gateway präsentierte Zertifikat stimmt nicht mit google.com überein. Das Ergebnis ist eine harte Blockierung. Der Benutzer sieht eine Sicherheitswarnung und kann nicht zur Anmeldeseite gelangen.

Die Lösung hierfür ist zweigeteilt. Erstens: Verlassen Sie sich auf die Erkennungsmechanismen auf Betriebssystemebene, die wir gerade besprochen haben. Diese verwenden unverschlüsseltes HTTP, genau um diesen Zertifikatskonflikt zu vermeiden. Zweitens: Stellen Sie sicher, dass Ihre Walled-Garden-Konfiguration fehlerfrei ist.

Was ist ein walled garden? Es ist die Liste von Domains und IP-Adressen, auf die ein Gast zugreifen kann, bevor er sich authentifiziert. Wenn Sie Social Login über Microsoft Entra ID oder Google Workspace nutzen oder Zahlungen über Stripe abwickeln, müssen diese Domains in Ihrem walled garden hinterlegt sein. Wenn sie das nicht sind, wird die Splash Page zwar geladen, aber der Authentifizierungsprozess schlägt stillschweigend fehl.

[PAUSE]

Sehen wir uns ein Praxisbeispiel an. McDonald's bedient Millionen von Kunden an Tausenden von Standorten. Sie nutzen Purple, um ihr Gast-WiFi zu verwalten. Wenn ihr Session-Timeout zu kurz eingestellt ist, muss sich ein Kunde, der während eines langen Mittagessens sein Smartphone nutzt, möglicherweise mehrmals neu authentifizieren. Das ruiniert das Nutzererlebnis. Wir empfehlen, die Session-Dauer in der Gastronomie und im Einzelhandel auf 24 Stunden festzulegen und MAC-Address-Caching zu nutzen, um wiederkehrende Geräte nahtlos zu erkennen.

[PAUSE]

Nun zu den Empfehlungen für die Implementierung. Wenn Sie ein Captive Portal bereitstellen, müssen Sie Ihr Gateway so konfigurieren, dass es DNS- und HTTP-Traffic korrekt abfängt. Wenn Sie ein Cloud-Overlay wie Purple nutzen, muss Ihre lokale Hardware - ob Juniper Mist oder Ubiquiti UniFi - in der Lage sein, die Purple RADIUS-Server zu erreichen.

Hier ist eine kritische Fehlerquelle: die DNS-Auflösung. Wenn ein Gastgerät den Hostnamen Ihres Captive Portals nicht auflösen kann, schlägt die Weiterleitung fehl. Stellen Sie sicher, dass Ihr DHCP-Server zuverlässige DNS-Adressen vergibt, und überprüfen Sie, ob Ihr Gateway DNS-Anfragen durch den walled garden passieren lässt.

Berücksichtigen Sie außerdem die physische Umgebung. High-Density-Standorte wie Stadien oder Verkehrsknotenpunkte - wie die Manchester Airports Group - haben es mit Tausenden von gleichzeitigen Verbindungsversuchen zu tun. Wenn Ihr lokaler DHCP-Pool erschöpft ist, verbinden sich neue Geräte zwar mit dem Access Point, erhalten aber keine IP-Adresse. Sie erreichen nicht einmal die Captive Portal-Phase. Dimensionieren Sie Ihre Subnetze immer passend für Spitzenkapazitäten und nutzen Sie kurze DHCP-Lease-Zeiten für Netzwerke mit hoher Fluktuation.

[PAUSE]

Nun zu einer schnellen Fragerunde basierend auf häufigen Helpdesk-Tickets.

Frage eins: Warum funktioniert das Portal auf iPhones, schlägt aber auf Android-Geräten fehl?

Antwort: Das ist fast sicher ein Problem mit dem walled garden. Sie haben wahrscheinlich captive.apple.com freigegeben, aber connectivitycheck.gstatic.com vergessen. Aktualisieren Sie Ihre Pre-Authentication-Zugriffskontrolllisten.

Frage zwei: Gäste authentifizieren sich erfolgreich, haben aber immer noch kein Internet. Warum?

Antwort: Überprüfen Sie Ihre RADIUS-Konfiguration. Das Gateway empfängt wahrscheinlich nicht die Access-Accept-Nachricht vom RADIUS-Server oder die Firewall-Regeln nach der Authentifizierung blockieren den Traffic. Überprüfen Sie das Shared Secret und stellen Sie sicher, dass die Ports 1812 und 1813 geöffnet sind.

Frage drei: Können wir HTTPS für die erste Weiterleitung nutzen, um Sicherheitswarnungen zu vermeiden?

Antwort: Nein. Sie können eine HTTPS-Anfrage nicht abfangen, ohne einen Zertifikatsfehler zu verursachen, es sei denn, Sie installieren ein Root-Zertifikat auf jedem Gastgerät - was bei öffentlichem WiFi unmöglich ist. Sie müssen sich darauf verlassen, dass die unverschlüsselten HTTP-Betriebssystem-Probes das Portal auslösen.

[PAUSE]

Zusammenfassend lässt sich sagen: Fehler beim Captive Portal sind selten Hardwarefehler. Es handelt sich fast immer um Konfigurationsfehler im Redirect-Flow, im Walled Garden oder in den DNS-Einstellungen.

Erstens: Stellen Sie sicher, dass URLs zur OS-Erkennung vor der Authentifizierung zugänglich sind.

Zweitens: Konfigurieren Sie Ihren Walled Garden so, dass alle erforderlichen Identitätsanbieter und Content Delivery Networks enthalten sind.

Drittens: Überprüfen Sie die RADIUS-Kommunikation zwischen Ihrem Gateway und Ihrer Authentifizierungsplattform.

Viertens: Dimensionieren Sie Ihre DHCP-Bereiche für Spitzenlasten.

Indem Sie diese Elemente meistern, eliminieren Sie Verbindungsprobleme. Sie frustrieren Ihre Besucher nicht länger und beginnen mit der Erfassung der First-Party-Daten, die Sie zur Steigerung von Kundenbindung und Umsatz benötigen. Die identitätsbasierten Netzwerke von Purple vereinfachen diesen Prozess. Sie bieten ein hardwareunabhängiges Cloud-Overlay, das die Komplexität von RADIUS, Captive Portals und Analysen nahtlos an 80.000 Live-Standorten weltweit bewältigt.

Vielen Dank für Ihre Teilnahme an diesem Purple Technical Briefing. Detailliertere Konfigurationsanleitungen und Architekturdiagramme finden Sie unter purple.ai.

Wichtigste Erkenntnisse

✓Fehler beim Captive Portal sind fast immer Konfigurationsprobleme - keine Hardwarefehler. Die Redirect-Kette umfasst sechs Schritte, und jeder einzelne kann fehlschlagen.
✓Jedes Betriebssystem sendet eine andere HTTP-Probe-URL, um Captive Portals zu erkennen. Wenn Ihr Gateway eine dieser Probes blockiert, sieht das Betriebssystem die Splash Page nie.
✓Versuchen Sie niemals, HTTPS-Verkehr für eine Captive Portal-Umleitung abzufangen. HSTS führt zu schweren Zertifikatsfehlern. Verlassen Sie sich auf die unverschlüsselten HTTP-Probes des Betriebssystems.
✓Der Walled Garden muss vor der Authentifizierung OS-Probe-URLs, Identity-Provider-Domains (Microsoft Entra ID, Google Workspace), CDN-Ressourcen und die Domains von Zahlungsanbietern enthalten.
✓Authentifizierung (Ausfüllen des Login-Formulars) und Autorisierung (das Gateway öffnet die Firewall-Regel) sind getrennte Schritte. Wenn das Portal Erfolg anzeigt, aber kein Internet vorhanden ist, ist die RADIUS-Kommunikation zwischen dem Gateway und den Servern von Purple gestört.
✓In stark frequentierten Umgebungen führt eine DHCP-Erschöpfung zu identischen Symptomen wie ein Ausfall des Captive Portal. Dimensionieren Sie Ihren DHCP-Pool für die maximale Anzahl gleichzeitiger Geräte und nutzen Sie kurze Lease-Times.
✓Testen Sie jede Bereitstellung vor der Abnahme auf iOS, Android und Windows. Betriebssystemspezifische Fehler weisen auf Lücken im Walled Garden hin, nicht auf grundlegende Fehlkonfigurationen.

Management-Zusammenfassung

Die Suchanfrage „Gast-WiFi verbunden, aber kein Internet“ gehört zu den häufigsten Support-Tickets im Enterprise-Networking. Das Symptom ist für jeden Besucher sichtbar; die Ursache bleibt für die meisten IT-Teams jedoch unsichtbar, bis sie die Weiterleitungskette verstehen. Ein Captive Portal (auch Splash Page oder Hotspot-Gateway genannt) fängt den ersten HTTP-Konnektivitätstest eines Geräts ab und gibt eine HTTP 302-Weiterleitung an eine Anmeldeseite aus. Wenn ein Schritt in dieser Kette fehlschlägt - blockierte Tests, HSTS-Konflikte, Lücken im Walled Garden, RADIUS-Fehler oder DHCP-Erschöpfung - sieht der Gast nichts als ein verbundenes WiFi-Symbol und kein Internet. Dieser Leitfaden führt Sie durch jeden Fehlermodus, die zugrunde liegende Protokollmechanik und die Konfigurationsänderungen, mit denen Sie diese beheben können. Purple ist in über 80.000 Live-Standorten im Einsatz und verarbeitet jährlich 440 Millionen Anmeldungen (interne Daten von Purple, 2024). Die hier beschriebenen Muster stellen die häufigsten Ursachen dar, die wir in den Bereichen Hotellerie, Einzelhandel, Transportwesen und im öffentlichen Sektor beobachten.

Technischer Deep-Dive

Wie die Erkennung von Captive Portals tatsächlich funktioniert

Jedes gängige Betriebssystem verfügt über einen integrierten Mechanismus, mit dem erkannt wird, ob ein Netzwerk eine Authentifizierung erfordert, bevor der Internetzugang gewährt wird. Das Verständnis dieser Mechanismen ist die Grundlage für jede Fehlerbehebung bei Captive Portals.

Wenn sich ein Gerät mit einer SSID verbindet, sendet das Betriebssystem eine unverschlüsselte HTTP GET-Anfrage an eine vordefinierte URL. Die folgende Tabelle listet die Test-URLs nach Plattform auf.

Betriebssystem	Test-URL	Erwartete Antwort
iOS / macOS	`http://captive.apple.com/hotspot-detect.html`	HTTP 200 mit bestimmtem Body
Android (Google)	`http://connectivitycheck.gstatic.com/generate_204`	HTTP 204 No Content
Windows (NCSI)	`http://www.msftconnecttest.com/connecttest.txt`	HTTP 200 mit Body „Microsoft Connect Test“
Chrome (alle Plattformen)	`http://www.gstatic.com/generate_204`	HTTP 204 No Content
Firefox	`http://detectportal.firefox.com/success.txt`	HTTP 200

Wenn das Gateway eine dieser Anfragen abfängt und eine HTTP 302-Weiterleitung an die URL des Captive Portals zurückgibt, erkennt das Betriebssystem, dass es sich hinter einem Portal befindet, und öffnet einen Pseudo-Browser (ein leichtgewichtiges WebView), um die Splash Page anzuzeigen. Wenn der Test vollständig blockiert wird, meldet das Betriebssystem „Keine Internetverbindung“ und versucht gar nicht erst, das Portal zu öffnen. Dies ist die mit Abstand häufigste Ursache für das Symptom „Gast-WiFi verbunden, aber kein Internet“.

Das HSTS-Problem

HTTP Strict Transport Security (HSTS) ist eine Web-Sicherheitsrichtlinie, die in RFC 6797 definiert ist. Sie weist Browser an, alle reinen HTTP-Verbindungen zu einer Domain abzulehnen und jedes Zertifikat zurückzuweisen, das nicht exakt übereinstimmt. Große Domains wie google.com, facebook.com und die meisten Banking-Seiten befinden sich auf der HSTS-Preload-Liste, die in Chrome, Firefox, Safari und Edge integriert ist.

Wenn ein Gast einen Browser öffnet und google.com eingibt, aktualisiert der Browser die Anfrage auf HTTPS, bevor sie das Gerät verlässt. Das Gateway kann eine HTTPS-Anfrage nicht abfangen und sauber umleiten - es müsste ein Zertifikat für google.com vorlegen, das es nicht besitzt. Der Browser erkennt die Zertifikatsabweichung und zeigt eine schwerwiegende Sicherheitswarnung an. Der Gast kann nicht zur Login-Seite fortfahren.

Die korrekte Architektur basiert vollständig auf den oben beschriebenen HTTP-Probes auf Betriebssystemebene. Diese Probes verwenden reines HTTP zu Non-HSTS-URLs, speziell damit Gateways sie ohne Zertifikatskonflikte abfangen und umleiten können. Ihr Gateway muss diese HTTP-Probes abfangen und den 302-Redirect ausführen. Versuchen Sie nicht, HTTPS-Traffic für Captive Portal-Zwecke abzufangen.

Der Walled Garden

Ein Walled Garden ist die Gruppe von Domains und IP-Adressen, die ein Gerät erreichen kann, bevor es sich authentifiziert hat. Wenn der Walled Garden zu eng gefasst ist, lädt die Splash Page zwar, aber die Authentifizierung schlägt fehl. Häufige Lücken sind:

Identity Provider-Domains: Wenn Sie Microsoft Entra ID, Okta oder Google Workspace für Social Login oder SSO verwenden, müssen deren Authentifizierungs-Endpunkte im Walled Garden hinterlegt sein.
CDN- und Asset-Domains: Ihre Splash Page lädt möglicherweise CSS, JavaScript oder Schriftarten von einem Content Delivery Network. Wenn diese CDN-Domains blockiert sind, wird die Seite fehlerhaft dargestellt.
Zahlungsanbieter-Domains: Wenn Sie den Zugang über Stripe oder einen anderen Anbieter kostenpflichtig machen, müssen die JavaScript SDK-Domains des Anbieters vorab authentifiziert sein.
Purple Plattform-Domains: Der Cloud-Overlay von Purple erfordert, dass das Gateway die RADIUS-Server und Portal-Endpunkte von Purple erreichen kann. Diese sind in den Hardware-Integrationshandbüchern von Purple für jede unterstützte Plattform dokumentiert.

RADIUS und die Autorisierungslücke

RADIUS (Remote Authentication Dial-In User Service) ist das Protokoll, das Ihr lokales Gateway mit der Authentifizierungsplattform verbindet. Wenn ein Gast das Login-Formular ausfüllt, sendet das Captive Portal die Anmeldedaten an den RADIUS-Server. Der RADIUS-Server gibt eine Access-Accept- oder Access-Reject-Nachricht zurück. Das Gateway reagiert auf diese Nachricht, indem es die Firewall-Regel, die den Internetzugang gewährt, öffnet oder geschlossen hält.

Die Autorisierungslücke - bei der sich ein Gast erfolgreich auf der Splash Page anmeldet, aber immer noch kein Internet hat - bedeutet fast immer, dass das Gateway die Access-Accept-Nachricht nicht empfangen oder verarbeitet hat. Häufige Ursachen sind ein nicht übereinstimmendes Shared Secret, die Blockierung der UDP-Ports 1812 und 1813 durch eine lokale Firewall oder eine falsch auf dem Gateway konfigurierte RADIUS-Server-IP-Adresse.

DHCP-Erschöpfung in High-Density-Umgebungen

In Stadien, Konferenzzentren und Verkehrsknotenpunkten ist eine DHCP-Erschöpfung eine häufige Ursache für Verbindungsfehler, die identisch mit einem Captive Portal-Problem aussehen. Wenn der DHCP-Pool voll ist, verbindet sich ein neues Gerät mit dem Access Point, erhält aber nie eine IP-Adresse. Ohne eine IP-Adresse kann das Gerät den HTTP-Probe nicht senden und erreicht das Captive Portal nie. Das Gerät wird als mit der SSID verbunden angezeigt, hat aber kein Internet.

Für Veranstaltungsorte wie die Manchester Airports Group (MAG), bei denen die Passagierzahlen stark ansteigen, müssen Subnetze für die maximale Anzahl gleichzeitiger Geräte dimensioniert werden, nicht für den Durchschnitt. Kurze DHCP-Lease-Zeiten (15 - 30 Minuten für transiente Besuchernetzwerke) fordern Adressen von abgereisten Geräten schnell zurück.

Implementierungshandbuch

Die folgenden Schritte gelten für jede Hardwareplattform - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet - bei der Integration mit dem Cloud-Overlay von Purple.

Schritt 1: Konfigurieren Sie die SSID für das externe Captive Portal. Stellen Sie in Ihrem Hardware-Controller die Gäste-SSID so ein, dass nicht authentifizierte Clients auf die externe Portal-URL von Purple umgeleitet werden. Deaktivieren Sie jede lokale Splash-Page auf dem Controller selbst.

Schritt 2: Definieren Sie den Walled Garden. Fügen Sie mindestens die folgenden Domains hinzu: Das Portal von Purple und die RADIUS-Endpunkte (siehe Ihr Hardware-Integrationshandbuch), die oben aufgeführten OS-Erkennungs-Probe-URLs, die Domains Ihres Identitätsanbieters (Microsoft Entra ID, Okta oder Google Workspace) und alle CDN-Domains, die Ihre Splash-Page-Assets verwenden.

Schritt 3: RADIUS konfigurieren. Geben Sie die RADIUS-Server-IP-Adressen von Purple und das Shared Secret aus Ihrem Purple-Dashboard ein und stellen Sie den Authentifizierungsport auf 1812 sowie den Accountingport auf 1813 ein. Stellen Sie sicher, dass Ihre lokale Firewall ausgehendes UDP auf diesen Ports zulässt.

Schritt 4: Sitzungsparameter festlegen. Stellen Sie für das Gastgewerbe und den Einzelhandel die Sitzungsdauer auf 24 Stunden mit aktiviertem MAC-Adress-Caching ein. Dies verhindert, dass Gäste während eines einzigen Besuchs zur erneuten Authentifizierung gezwungen werden. Für Hochsicherheitsumgebungen sind kürzere Sitzungen mit erneuter Authentifizierung angemessen.

Schritt 5: Dimensionieren Sie Ihren DHCP-Bereich. Berechnen Sie die maximale Anzahl gleichzeitiger Geräte für Ihren Veranstaltungsort bei Spitzenkapazität. Ein Restaurant mit 500 Plätzen kann während eines geschäftigen Service 800 Geräte verzeichnen. Dimensionieren Sie den DHCP-Pool auf 1.000 Adressen mit einer Lease-Zeit von 30 Minuten.

Schritt 6: Betriebssystemübergreifend testen. Testen Sie nach der Konfiguration den gesamten Ablauf auf iOS-, Android- und Windows-Geräten. Jedes verwendet eine andere Probe-URL und WebView-Implementierung. Ein Fehler auf einer Plattform, während andere funktionieren, ist fast immer eine Lücke im Walled Garden.

Best Practices

Die folgenden Empfehlungen spiegeln Standards und Muster aus den über 80.000 Installationen von Purple an Veranstaltungsorten wider.

Separate guest and staff networks. Betreiben Sie mindestens drei SSIDs: Guest WiFi, Staff WiFi und ein IoT-Netzwerk. Der Datenverkehr von Gästen muss von internen Systemen isoliert werden. Einzelheiten zur Architektur finden Sie in unserem Leitfaden Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi .

Nutzen Sie ein dediziertes Guest-VLAN. Segmentieren Sie den Datenverkehr von Gästen in ein eigenes VLAN, um laterale Bewegungen zu verhindern und Firewall-Richtlinien zu vereinfachen. Dies ist eine PCI-DSS-Anforderung, falls Kreditkartendaten über das Netzwerk übertragen werden.

Implementieren Sie bewusste Opt-ins. Die GDPR verlangt, dass die Datenerfassung am Captive Portal auf einer informierten, ausdrücklichen Einwilligung basiert. Die bewussten Opt-ins von Purple präsentieren die Optionen zur Datenerfassung klar und mit separaten Kontrollkästchen für jeden Zweck. Dies ist für Standorte im Vereinigten Königreich oder in der EU obligatorisch.

Überwachen Sie die Portal-Integrität proaktiv. Die Plattform für WiFi Analytics von Purple bietet Echtzeit-Einblicke in Anmeldeerfolgsraten, Sitzungszahlen und Authentifizierungsfehler. Ein plötzlicher Abfall erfolgreicher Anmeldungen ist eine Frühwarnung für ein RADIUS- oder Walled-Garden-Problem, noch bevor sich Gäste beschweren.

Verwenden Sie ein einheitliches Branding. Die Splash Page ist die erste Interaktion, die ein Gast mit Ihrer Marke in Ihrem Netzwerk hat. Ein gut gestaltetes Portal erhöht die Opt-in-Raten und setzt Erwartungen für das WiFi-Erlebnis. Design-Richtlinien finden Sie unter How to make a great first impression with your guest WiFi .

Fehlerbehebung und Risikominderung

Wenn ein Problem mit dem Captive Portal gemeldet wird, befolgen Sie diese Diagnose-Reihenfolge, bevor Sie Konfigurationsänderungen vornehmen.

Isolieren Sie die Fehlerquelle. Fragen Sie den Gast, welches OS und welchen Browser er verwendet. Testen Sie denselben Ablauf selbst auf demselben OS. Wenn das Problem OS-spezifisch ist, liegt die Ursache fast sicher an einem fehlenden Walled-Garden-Eintrag für die Probe-URL dieses Betriebssystems.

Überprüfen Sie die DNS-Auflösung. Versuchen Sie von einem Gerät im Guest-VLAN aus, den Hostnamen des Captive Portals aufzulösen. Wenn die DNS-Auflösung fehlschlägt, kann das Gerät die Splash Page nicht erreichen, selbst wenn die Weiterleitung korrekt erfolgt. Überprüfen Sie, ob Ihr DHCP-Server zuverlässige DNS-Adressen verteilt und ob das Gateway DNS-Abfragen im Pre-Authentication-Status zulässt.

Erfassen Sie die Weiterleitung. Verwenden Sie die Browser-Entwicklertools (F12) oder ein Packet Capture, um den HTTP-Austausch zu beobachten. Sie sollten die Probe-Anfrage des Betriebssystems sehen, gefolgt von einer HTTP-302-Antwort, die die Portal-URL enthält. Wenn Sie die Probe-Anfrage sehen, aber keine 302-Antwort, fängt das Gateway den Datenverkehr nicht korrekt ab. Wenn Sie überhaupt keine Probe-Anfrage sehen, hat das OS bereits (möglicherweise aus einem zwischengespeicherten Zustand) festgestellt, dass es Internetzugang hat, und sendet die Probe nicht. RADIUS-Kommunikation überprüfen. Überprüfen Sie auf dem Gateway die RADIUS-Accounting-Protokolle. Eine erfolgreiche Authentifizierung erzeugt einen „Accounting-Start“-Eintrag. Wenn nach der Anmeldung eines Gastes keine Accounting-Einträge angezeigt werden, ist die RADIUS-Kommunikation gestört. Überprüfen Sie das Shared Secret, die Server-IP und die Firewall-Regeln.

DHCP-Lease-Auslastung prüfen. Überprüfen Sie auf dem DHCP-Server die aktuelle Anzahl der Leases im Vergleich zur Poolgröße. Wenn die Auslastung 90 % überschreitet, droht eine Erschöpfung des Pools. Erweitern Sie den Pool oder verkürzen Sie die Lease-Zeit umgehend.

Die folgende Tabelle ordnet die häufigsten Symptome ihren Ursachen und der entsprechenden Behebung zu.

Symptom	Wahrscheinlichste Ursache	Behebung
Portal erscheint auf keinem Gerät	OS-Probe wird durch Gateway-ACL blockiert	Probe-URLs zur Pre-Auth-Erlaubnisliste hinzufügen
Portal erscheint auf iOS, nicht auf Android	Android-Probe-URL fehlt im Walled Garden	`connectivitycheck.gstatic.com` zum Walled Garden hinzufügen
HTTPS-Zertifikatsfehler beim Laden des Portals	Gateway fängt HTTPS anstelle von HTTP ab	Nur auf HTTP-Probe-Abfangung verlassen
Portal lädt, kein Internet nach dem Login	RADIUS Access-Accept nicht vom Gateway empfangen	Shared Secret, Ports 1812/1813, RADIUS-Server-IP überprüfen
Social-Login-Button schlägt geräuschlos fehl	Identity-Provider-Domain nicht im Walled Garden	Endpunkte von Microsoft Entra ID / Google Workspace hinzufügen
Gäste müssen sich bei jedem Besuch neu authentifizieren	Sitzungsdauer zu kurz oder MAC-Caching deaktiviert	Sitzung auf 24 Stunden festlegen, MAC-Adress-Caching aktivieren
Sporadische Ausfälle zu Stoßzeiten	DHCP-Pool-Erschöpfung	Subnetz erweitern, Lease-Zeit verkürzen

ROI und geschäftliche Auswirkungen

Jeder Ausfall eines Captive Portals ist ein verlorenes Datenerfassungsereignis. Die Guest WiFi -Plattform von Purple verwandelt jede erfolgreiche Authentifizierung in einen First-Party-Datensatz - Name, E-Mail-Adresse, demografische Daten und Besuchshäufigkeit - der direkt in Marketing-Automatisierung und Treueprogramme einfließt.

Für einen Gastronomie- und Hotellerie -Betreiber wie Premier Inn oder Whitbread bedeutet eine Verbesserung der Authentifizierungs-Erfolgsquote des Portals um 10 % in einem Portfolio von 700 Standorten monatlich zehntausende zusätzliche Opt-in-Datensätze. Diese Datensätze bilden die Grundlage für personalisierte E-Mail-Kampagnen mit messbar höheren Öffnungsraten als bei gekauften Listen.

Für Einzelhandels -Betreiber ist das Captive Portal der Einstiegspunkt, um die Verweildauer der Kunden, die Häufigkeit von Wiederholungsbesuchen und das Verhalten an verschiedenen Standorten zu verstehen. Purple hat in seinem Standort-Netzwerk 29 Milliarden Datenpunkte (interne Daten von Purple) erfasst. Diese Daten sind nur so gut wie die Authentifizierungsrate, mit der sie generiert werden.

Für Verkehrsknotenpunkte wie die Manchester Airports Group ist ein zuverlässiges Guest WiFi eine Kennzahl für die Passagierzufriedenheit, die auf Vorstandsebene verfolgt wird. Ein Portal, das in Stoßzeiten sporadisch ausfällt, führt zu Beschwerden und beschädigt den Net Promoter Score des Standorts. Für Gesundheitswesen -Umgebungen entlastet ein zuverlässiges Gäste-WiFi das klinische Personal, das sich andernfalls mit Beschwerden über die Konnektivität befassen müsste, und unterstützt die Patientenzufriedenheit.

Die SLA von Purple mit 99,999 % Betriebszeit stellt sicher, dass das Cloud-Overlay selbst nicht die Fehlerquelle ist. Wenn Portalprobleme auftreten, liegt die Ursache fast immer an der lokalen Konfiguration - ein Problem, das Sie mit diesem Leitfaden ohne die Eröffnung eines Support-Tickets beheben können.

Referenzen

[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, November 2024. https://community.fortinet.com/fortigate-3/troubleshooting-tip-general-captive-portal-explanation-flow-and-troubleshooting-188409

[2] RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements. IETF. https://www.rfc-editor.org/info/rfc8910

[3] Network Connectivity Status Indicator overview for Windows. Microsoft Learn, Februar 2025. https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview

[4] 7 Captive Portal Problems That Break Guest WiFi (And Quick Fixes). Spotipo, Februar 2026. https://www.spotipo.com/post/troubleshooting-captive-portals-common-issues

[5] Solution for HSTS issues with captive portal. Ubiquiti Community. https://community.ui.com/questions/Solution-for-HSTS-issues-with-captive-portal/17b033e7-3dfe-4830-af8f-bf6ead23d8b0

Schlüsseldefinitionen

Captive Portal

Eine Webseite, die einem Gerät beim Beitritt zu einem Netzwerk angezeigt wird, bevor der vollständige Internetzugang freigegeben wird. Das Gateway fängt die erste HTTP-Verbindungsprüfung des Geräts ab und leitet sie an die Portal-URL weiter.

Der Mechanismus hinter jeder Gäste-WiFi-Login-Seite, von Hotellobbys bis hin zu Stadion-Promenaden. Definiert in RFC 8910.

Walled garden

Die Gruppe von Domains und IP-Adressen, die ein Gerät erreichen kann, bevor die Authentifizierung am Captive Portal abgeschlossen ist. Der Datenverkehr zu Walled garden-Zielen umgeht die Authentifizierungsanforderung.

Muss OS-Prüf-URLs, Endpunkte von Identitätsanbietern, CDN-Domains und Zahlungsabwickler-Domains enthalten. Ein falsch konfigurierter Walled garden ist die zweithäufigste Ursache für Fehler beim Captive Portal.

NCSI (Network Connectivity Status Indicator)

Eine Windows-Funktion, die `msftconnecttest.com` abfragt, um festzustellen, ob das Gerät über einen Internetzugang verfügt oder sich hinter einem Captive Portal befindet. Definiert in der Netzwerkdokumentation von Microsoft.

Wenn das Gateway diese Prüfung blockiert, meldet Windows "Kein Internetzugriff" und löst die Captive Portal-WebView niemals aus. Die Lösung besteht darin, die NCSI-URL zur Pre-Authentication-Zulassungsliste hinzuzufügen.

HSTS (HTTP Strict Transport Security)

Eine in RFC 6797 definierte Websicherheitsrichtlinie, die Browser anweist, reine HTTP-Verbindungen abzulehnen und alle Zertifikate zurückzuweisen, die nicht exakt mit der Domain übereinstimmen.

Verhindert, dass Gateways HTTPS-Anfragen für die Weiterleitung zum Captive Portal abfangen. Wichtige Domains wie google.com stehen in allen gängigen Browsern auf der HSTS-Preload-Liste.

HTTP 302 redirect

Ein Standard-HTTP-Antwortcode, der angibt, dass sich die angeforderte Ressource vorübergehend unter einer anderen URI befindet, die im Location-Header angegeben ist.

Der Mechanismus, den Gateways verwenden, um die Verbindungsprüfung eines Geräts auf die Login-Seite des Captive Portals umzuleiten. Einige Gateways verwenden stattdessen HTTP 303 oder HTTP 200 mit einem Redirect-Body.

RADIUS (Remote Authentication Dial-In User Service)

Ein Netzwerkprotokoll für die zentrale Verwaltung von Authentifizierung, Autorisierung und Accounting (AAA), das über UDP auf den Ports 1812 (Authentifizierung) und 1813 (Accounting) arbeitet.

Die Cloud-Plattform von Purple fungiert als RADIUS-Server. Das lokale Gateway (Meraki, Aruba usw.) sendet Authentifizierungsanfragen an die RADIUS-Server von Purple und reagiert auf die Antwort Access-Accept oder Access-Reject.

MAC address caching

Der Prozess der Speicherung der eindeutigen Hardware-ID eines Geräts, um wiederkehrende Geräte zu erkennen und den Sitzungsstatus ohne erneute Authentifizierung beizubehalten.

Ermöglicht Sitzungspersistenz bei kurzen Verbindungsabbrüchen und wiederholten Besuchen innerhalb des Sitzungsfensters. Unverzichtbar für Hospitality-Umgebungen, in denen sich Gäste zwischen verschiedenen Bereichen bewegen.

Identity-Based Networks

Das Architekturmodell von Purple, bei dem Zugriffsrichtlinien, VLAN-Zuweisung und Analysen basierend auf der authentifizierten Identität des Benutzers und nicht nur auf der IP- oder MAC-Adresse des Geräts angewendet werden.

Ermöglicht granulare Zugriffskontrolle, personalisierte Erlebnisse und eine präzise Zuordnung des Netzwerkverhaltens zu einzelnen Benutzern über Hardware von Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet hinweg.

DHCP exhaustion

Ein Zustand, in dem alle verfügbaren IP-Adressen in einem DHCP-Pool zugewiesen wurden, was verhindert, dass neue Geräte eine Adresse erhalten und somit das Captive Portal erreichen können.

Häufig in Umgebungen mit hoher Dichte während Spitzenzeiten. Äußert sich identisch mit einem Ausfall des Captive Portals - das Gerät zeigt an, dass es mit der SSID verbunden ist, hat aber kein Internet. Diagnose durch Überprüfung der DHCP-Lease-Auslastung auf dem Server.

Ausgearbeitete Beispiele

Ein Hotel mit 200 Zimmern, das HPE Aruba Access Points nutzt, berichtet, dass Gäste auf Android-Geräten nicht auf das Captive Portal zugreifen können, während iOS-Nutzer sich problemlos verbinden. Das IT-Team hat bestätigt, dass die Portal-URL vom Management-VLAN aus erreichbar ist.

Das IT-Team sollte den Pre-Authentication Walled Garden auf dem HPE Aruba Controller überprüfen. iOS-Geräte testen captive.apple.com, was wahrscheinlich bereits auf der Whitelist steht. Android-Geräte testen connectivitycheck.gstatic.com und clients3.google.com/generate_204. Diese Google-Domains fehlen fast sicher im Walled Garden. Das Hinzufügen dieser Domains zur Pre-Authentication-Erlaubnisliste löst das Problem. Das Team sollte auch connectivitycheck.android.com als sekundäre Android-Test-URL hinzufügen. Starten Sie nach der Aktualisierung des Walled Garden die betroffenen SSIDs neu und testen Sie auf einem auf Werkseinstellungen zurückgesetzten Android-Gerät, um die Behebung zu bestätigen, da ein zwischengespeicherter Netzwerkstatus auf einem zuvor verbundenen Gerät das Ergebnis maskieren kann.

Kommentar des Prüfers: Dieses Szenario veranschaulicht die betriebssystemspezifische Natur der Captive Portal Erkennung. Jede Plattform nutzt andere Test-URLs, und ein Walled Garden, der nur für ein Betriebssystem konfiguriert ist, führt genau zu diesem asymmetrischen Fehlermuster. Das wichtigste Diagnosesignal ist, dass der Fehler gerätetypspezifisch ist und nicht sporadisch auf allen Geräten auftritt. Sporadische Fehler auf allen Geräten würden stattdessen auf RADIUS- oder DHCP-Probleme hindeuten.

Eine Einzelhandelskette mit 150 Cisco Meraki MX-Geräten berichtet, dass sich Gäste auf der Purple Splash Page authentifizieren - das Purple Dashboard zeigt erfolgreiche Logins an - aber die Gäste nach dem Ausfüllen des Formulars immer noch keinen Internetzugang haben. Das Problem betrifft alle Standorte gleichzeitig.

Da die Purple Cloud-Plattform erfolgreiche Logins anzeigt, funktioniert der Authentifizierungsschritt selbst. Der Fehler liegt im Autorisierungsschritt - das Meraki-Gerät empfängt oder verarbeitet die RADIUS Access-Accept-Nachricht von den RADIUS-Servern von Purple nicht. Das Team sollte nacheinander drei Dinge überprüfen: Erstens, verifizieren Sie, dass das gemeinsame RADIUS-Geheimnis (Shared Secret) im Meraki-Dashboard exakt mit dem Geheimnis im Purple Portal übereinstimmt (schon eine Abweichung von einem einzelnen Zeichen führt zu einem unbemerkten Fehler); zweitens, bestätigen Sie, dass ausgehender UDP-Verkehr auf den Ports 1812 und 1813 vom Meraki-Gerät zu den RADIUS-Server-IP-Adressen von Purple zugelassen ist; drittens, prüfen Sie, ob eine kürzliche Netzwerkänderung eine Firewall-Regel oder NAT-Richtlinie eingeführt hat, die diesen Verkehr blockiert. Da das Problem alle 150 Standorte gleichzeitig betrifft, ist die Ursache wahrscheinlich eine zentralisierte Firewall-Richtlinienänderung oder eine Änderung der Purple RADIUS-Server-IP-Adresse, die nicht in die Meraki-Konfigurationen übernommen wurde.

Kommentar des Prüfers: Die entscheidende Diagnoseerkenntnis hierbei ist, dass das Purple Dashboard, welches erfolgreiche Logins anzeigt, bedeutet, dass der Cloud-Authentifizierungsschritt abgeschlossen wurde. Der Fehler liegt daher im lokalen Durchsetzungsschritt - der RADIUS-Nachricht von der Cloud zum Gateway. Diese Unterscheidung zwischen cloudseitiger Authentifizierung und lokalseitiger Autorisierung ist grundlegend für die Fehlerbehebung bei jeder Captive Portal Bereitstellung, die eine Cloud-Overlay-Architektur nutzt.

Übungsfragen

Q1. Während einer großen Konferenz in einem Veranstaltungsort mit 5.000 Sitzplätzen erhält das IT-Team Berichte, dass Hunderte von Teilnehmern nicht auf das Gäste-WiFi-Portal zugreifen können. Access Points zeigen normale Verbindungszahlen. Das Problem begann 45 Minuten nach Beginn der Veranstaltung. Was ist die wahrscheinlichste Ursache und was ist die sofortige Lösung?

Hinweis: Das Problem begann nach dem Start der Veranstaltung, nicht zu Beginn. Überlegen Sie, welche Ressource knapp wird, wenn sich mehr Geräte anmelden.

Musterlösung anzeigen

Die wahrscheinlichste Ursache ist die Erschöpfung des DHCP-Pools. Als die Besucher eintrafen und sich mit der SSID verbanden, füllte sich der DHCP-Pool. Neue Geräte verbinden sich zwar mit dem Access Point, können aber keine IP-Adresse abrufen. Daher senden sie niemals den HTTP-Probe, der zum Auslösen des Captive Portal erforderlich ist. Die sofortige Lösung besteht darin, die DHCP-Lease-Time auf 15 Minuten zu verkürzen (um IP-Adressen von abgereisten Geräten schneller freizugeben) und, falls möglich, den Pool durch Hinzufügen eines zweiten Subnetzes zu erweitern. Die langfristige Lösung besteht darin, den DHCP-Pool für die maximale Anzahl gleichzeitiger Geräte beim nächsten Event zu dimensionieren, nicht für den Durchschnitt.

Q2. Sie haben Purple auf Ubiquiti UniFi Access Points in einer Einzelhandelskette implementiert. Die Splash Page lädt auf allen Geräten korrekt. Gäste füllen das Formular zur E-Mail-Erfassung aus und sehen eine Erfolgsmeldung. Wenn sie jedoch versuchen zu surfen, haben sie keinen Internetzugang. Das Purple Dashboard zeigt die Logins als erfolgreich an. Was prüfen Sie zuerst?

Hinweis: Die Cloud-Plattform hat die Authentifizierung registriert. Der Fehler liegt beim lokalen Autorisierungsschritt.

Musterlösung anzeigen

Da das Dashboard von Purple erfolgreiche Logins anzeigt, wurde der Cloud-Authentifizierungsschritt korrekt abgeschlossen. Der Fehler liegt beim RADIUS-Autorisierungsschritt - der UniFi-Controller empfängt die Access-Accept-Nachricht der RADIUS-Server von Purple nicht oder reagiert nicht darauf. Prüfen Sie dies in folgender Reihenfolge: (1) Der gemeinsame RADIUS-Schlüssel (Shared Secret) auf dem UniFi-Controller stimmt exakt mit dem Schlüssel im Purple Dashboard überein; (2) ausgehender UDP-Verkehr auf den Ports 1812 und 1813 ist vom Controller zu den RADIUS-Server-IP-Adressen von Purple zugelassen; (3) die auf dem UniFi-Controller konfigurierten RADIUS-Server-IP-Adressen sind aktuell (Purple hat diese möglicherweise aktualisiert). Ein Packet Capture auf dem Controller bestätigt, ob die Access-Accept-Nachricht ankommt.

Q3. Der IT-Manager eines Hotels berichtet, dass Gäste, die ein VPN auf ihren Geräten nutzen, überhaupt nicht auf das Captive Portal zugreifen können. Gäste ohne VPN verbinden sich normal. Das Hotel nutzt Cisco Meraki MX-Appliances. Sollte das IT-Team die Konfiguration des Captive Portal ändern, um VPN-Nutzer zu unterstützen?

Hinweis: Bedenken Sie, was ein VPN mit dem Netzwerkverkehr des Geräts macht, bevor das Captive Portal diesen abfangen kann.

Musterlösung anzeigen

Nein - die Konfiguration des Captive Portal muss nicht geändert werden. Ein VPN-Client verschlüsselt den gesamten Datenverkehr des Geräts, bevor er das Gerät verlässt, einschließlich des HTTP-Verbindungstests (HTTP-Probe). Das Gateway kann verschlüsselten VPN-Verkehr nicht abfangen und gibt daher niemals den 302-Redirect aus. Der Gast muss sein VPN deaktivieren, die Authentifizierung am Captive Portal abschließen und das VPN anschließend wieder aktivieren. Dies ist eine grundlegende architektonische Einschränkung von Captive Portals und VPNs, kein Konfigurationsfehler. Das IT-Team sollte den Anweisungen für das Gäste-WiFi einen Hinweis hinzufügen, der VPN-Nutzer dazu auffordert, ihr VPN vor dem Verbinden zu deaktivieren.

Weiterlesen in dieser Reihe

Fehlerbehebung bei öffentlichem WiFi: Behebung von „Verbunden, kein Internet“ und Fehlern bei der Splash-Page-Weiterleitung

Dieser maßgebliche technische Leitfaden erklärt die grundlegenden Mechanismen der Erkennung von Captive Portals und beschreibt detailliert die sechs primären Fehlermodi, die eine Verbindung mit dem Gäste-WiFi verhindern. Er bietet IT-Managern und Netzwerkarchitekten ein praktisches Framework zur Fehlerbehebung bei HTTP-Weiterleitungsproblemen, DNS-Konflikten und Herausforderungen bei der MAC-Randomisierung.

Top 10 Ursachen für DHCP-Timeouts in High-Density Wireless Networks

Dieser maßgebliche technische Leitfaden identifiziert die zehn Hauptursachen für DHCP-Timeouts in High-Density Wireless Networks und bietet praxisnahe, herstellerneutrale Lösungsstrategien. Entwickelt für IT-Leiter, Netzwerkarchitekten und Betriebsleiter von Veranstaltungsorten, deckt er tiefgehende technische Prinzipien, schrittweise Implementierungs-Workflows und messbare Geschäftsergebnisse ab. Erfahren Sie, wie Sie Verbindungsengpässe beseitigen und Ihre Wireless-Infrastruktur optimieren, um eine nahtlose Konnektivität in anspruchsvollen Enterprise-Umgebungen zu gewährleisten.

Nutzung von Packet Capture (PCAP) zur Diagnose langsamer WiFi-Leistung

Dieser technische Leitfaden bietet IT-Managern, Netzwerkarchitekten und Venue Operations Directors eine strukturierte Methodik auf Paketebene zur Diagnose und Behebung langsamer Enterprise-WiFi-Performance mithilfe der Packet Capture (PCAP)-Analyse. Durch die Analyse nackter 802.11-Frames – einschließlich Retransmission-Rates, Airtime-Auslastung und Metadaten des Physical Layers – können Teams Engpässe auf der RF-Schicht präzise von kabelgebundenen oder anwendungsbezogenen Problemen isolieren. Dieser Leitfaden ist auf High-Density-Veranstaltungsorte wie Hotels, Einzelhandelsketten, Stadien und Konferenzzentren anwendbar und liefert praxisnahe Diagnose-Workflows, reale Fallstudien und Schritte zur Konfigurationsbehebung, um Netzwerkkapazitäten zurückzugewinnen und das Gästeerlebnis zu schützen.