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

Willkommen zu diesem technischen Briefing von Purple. Heute befassen wir uns mit einem der hartnäckigsten und am meisten missverstandenen Probleme in drahtlosen Unternehmensnetzwerken: dem Captive Portal für Gäste-WiFi, das sich einfach nicht laden lässt. Sie kennen das bestimmt. Ein Gast kommt in Ihr Hotel, Ihr Einzelhandelsgeschäft, Ihr Stadion oder Ihr Konferenzzentrum. Er verbindet sich mit dem WiFi-Netzwerk. Nichts passiert. Keine Anmeldeseite. Kein Internet. Nur ein Ladesymbol und eine wachsende Frustration. Für Standortleiter und IT-Manager ist dieser Moment nicht nur eine kleine Unannehmlichkeit. Er stellt ein direktes Scheitern Ihres Gasterlebnisses dar, sorgt für einen sprunghaften Anstieg der Support-Anrufe am Empfang und bedeutet eine verpasste Gelegenheit, First-Party-Daten zu erfassen, die Ihre Investition in die drahtlose Infrastruktur rechtfertigen. In diesem Briefing blicken wir hinter die Kulissen. Wir erklären genau, wie die Erkennung von Captive Portals auf Betriebssystemebene funktioniert, identifizieren die sechs Hauptursachen, die für die überwiegende Mehrheit der Verbindungsausfälle verantwortlich sind, und geben Ihnen ein praktisches, sofort umsetzbares Troubleshooting-Framework an die Hand, das Sie noch heute an Ihr IT-Team weitergeben können. Beginnen wir mit der Funktionsweise. Die meisten Menschen halten ein Captive Portal einfach für eine Anmeldeseite. In Wirklichkeit handelt es sich um einen Mechanismus zum Abfangen von Datenverkehr auf Netzwerkesbene, und dieser Unterschied ist von enormer Bedeutung, wenn Fehler auftreten. Hier ist der Ablauf. Das Gerät eines Gasts verbindet sich mit Ihrer Gäste-SSID und erhält über DHCP eine IP-Adresse. In diesem Moment wartet das Betriebssystem nicht darauf, dass der Benutzer einen Browser öffnet. Im Hintergrund sendet ein Systemdienst sofort eine unverschlüsselte HTTP-GET-Anfrage an eine herstellergesteuerte Probe-URL. Apple-Geräte fragen captive.apple.com ab. Android-Geräte fragen connectivitycheck.gstatic.com ab. Windows-Geräte fragen msftconnecttest.com ab. Firefox hat seine eigene Abfrage unter detectportal.firefox.com. Wenn das Netzwerk über einen offenen Internetzugang verfügt, geben diese Abfragen die erwarteten Antworten zurück, und das Betriebssystem geht davon aus, dass alles in Ordnung ist. In einem Gästenetzwerk fängt Ihr Wireless-Gateway oder -Controller diese HTTP-Abfrage jedoch ab, bevor sie das Internet erreicht. Anstelle der erwarteten Antwort gibt das Gateway eine HTTP-307-Weiterleitung zurück, die auf die Splash-Page Ihres Captive Portals verweist. Das Betriebssystem erkennt die unerwartete Weiterleitung, stellt fest, dass es sich hinter einem Captive Portal befindet, und öffnet ein Sandbox-Browserfenster – oft als "Captive Network Assistant" bezeichnet –, um die Anmeldeseite anzuzeigen. Das ist der Optimalfall. Lassen Sie uns nun über die sechs Wege sprechen, wie dieser Prozess fehlschlagen kann. Hauptursache Nummer eins: Erschöpfung des DHCP-Pools. Dies ist der stille Killer bei Veranstaltungen mit hoher Dichte. Wenn Sie eine Konferenz mit zweitausend Teilnehmern in einem Standard-Slash-24-Subnetz durchführen, stehen Ihnen 254 nutzbare IP-Adressen zur Verfügung. Wenn Ihre DHCP-Lease-Zeit auf den Standardwert von 24 Stunden eingestellt ist, ist dieser Pool innerhalb von Minuten nach Türöffnung erschöpft. Jeder nachfolgende Verbindungsversuch schlägt fehl, noch bevor die Captive Portal-Sequenz überhaupt beginnt. Die Lösung ist einfach: Stellen Sie die DHCP-Lease-Zeiten für Gäste in Umgebungen mit hohem Durchsatz auf 15 bis 30 Minuten ein und dimensionieren Sie Ihre Subnetze angemessen für die maximale Anzahl gleichzeitiger Benutzer, nicht nur für die Gesamtzahl der Personen. Hauptursache Nummer zwei: DNS-Abfangfehler. Die Weiterleitung zum Captive Portal hängt davon ab, dass das Gateway den HTTP-Probe abfängt. Der Probe erfordert jedoch zunächst eine DNS-Abfrage. Wenn Ihre DNS-Konfiguration es nicht authentifizierten Clients nicht erlaubt, externe Domainnamen aufzulösen, wird der Probe niemals ausgelöst. Stellen Sie sicher, dass Ihre Firewall-Richtlinie DNS-Abfragen von nicht authentifizierten Clients explizit zulässt, und überprüfen Sie, ob Ihr DNS-Abfangen funktioniert, indem Sie eine Paketaufzeichnung auf einem Testgerät durchführen. Hauptursache Nummer drei: Unvollständiger Walled Garden. Der Walled Garden – auch als Pre-Authentication Access Control List bezeichnet – definiert, welche externen Domains nicht authentifizierte Gäste erreichen können. Wenn Ihre Portal-Splash-Page Assets von einem CDN lädt, das sich nicht im Walled Garden befindet, wird die Seite als leerer Bildschirm gerendert. Wenn Sie Social Login über Google, Apple oder Facebook anbieten, muss jede OAuth-Domain, die diese Anbieter nutzen, auf der Whitelist stehen. Und hier ist der entscheidende Punkt: Social-Identity-Anbieter aktualisieren ihre CDN-IP-Bereiche und Authentifizierungsdomänen regelmäßig. Ein Walled Garden, der vor sechs Monaten perfekt funktionierte, kann heute unbemerkt fehlerhaft sein. Planen Sie vierteljährliche Walled Garden-Audits ein und nutzen Sie Wildcard-Domain-Snooping, sofern Ihre Hardware dies unterstützt. Auf Cisco Meraki, HPE Aruba, Ruckus und Juniper Mist ist dies nativ verfügbar. Hauptursache Nummer vier: HSTS blockiert die Weiterleitung. HTTP Strict Transport Security (HSTS) ist eine Sicherheitsrichtlinie für Browser, die Verbindungen zu bestimmten Domains ausschließlich über HTTPS erzwingt. Wenn das Gerät eines Gasts versucht, eine vorab in HSTS geladene Domain zu kontaktieren – und das betrifft praktisch jede größere Website – und Ihr Gateway versucht, diese HTTPS-Anfrage abzufangen, um sie zum Portal weiterzuleiten, erkennt der Browser eine Zertifikatsabweichung. Er zeigt eine nicht umgehbare Sicherheitswarnung an und blockiert die Weiterleitung vollständig. Die richtige Lösung besteht darin, niemals zu versuchen, HTTPS abzufangen. Ihr Gateway sollte nur die unverschlüsselten HTTP-Canary-Probes weiterleiten. Die langfristige, auf Standards basierende Lösung ist RFC 8910, das die DHCP-Option 114 definiert. Mit dieser Option kann Ihr DHCP-Server die URL des Captive Portal direkt an das Client-Gerät übermitteln, wodurch eine HTTP-Weiterleitung vollständig überflüssig wird. iOS 14 und Android 11 und höher unterstützen dies nativ. Fehlerursache Nummer fünf: Ein aktives VPN auf dem Gastgerät. Ein VPN verschlüsselt den gesamten Datenverkehr des Geräts und leitet ihn über einen externen Tunnel um, bevor er Ihr Gateway erreicht. Ihr Gateway sieht den HTTP-Probe-Aufruf nie. Die Captive Portal-Erkennung wird gar nicht erst ausgelöst. Der Gast sieht weder die Anmeldeseite noch das Internet. Die Lösung für den Gast ist einfach: VPN deaktivieren, mit dem Portal verbinden und das VPN anschließend wieder aktivieren. Für Ihr Servicepersonal sollte dies die erste Frage sein, wenn ein Gast ein Verbindungsproblem meldet. Fehlerursache Nummer sechs: Die Randomisierung von MAC-Adressen beeinträchtigt die Sitzungspermanenz. Moderne iOS- und Android-Geräte verwenden standardmäßig randomisierte MAC-Adressen als Datenschutzfunktion. Jedes Mal, wenn sich ein Gerät mit einem Netzwerk verbindet, präsentiert es möglicherweise eine andere MAC-Adresse. Da der Sitzungsstatus des Captive Portal über die MAC-Adresse nachverfolgt wird, sieht ein Gast, der sich vor einer Stunde authentifiziert hat, nach dem Wechsel der MAC-Adresse seines Geräts eventuell erneut die Anmeldeseite. Die Lösung auf Gastseite besteht darin, die Option „Private Adresse“ für Ihre spezifische SSID in den Netzwerkeinstellungen zu deaktivieren. Die Lösung auf Betreiberseite ist die Implementierung einer profilbasierten Authentifizierung – wie OpenRoaming über Passpoint und 802.1X –, die auf Layer 2 mit Anmeldedaten anstelle von MAC-Adressen authentifiziert, wodurch die Randomisierung hinfällig wird. Sprechen wir nun über die Implementierung. Wie sieht eine gut konfigurierte Captive Portal-Bereitstellung in der Praxis tatsächlich aus? Beginnen Sie mit Ihrer DHCP-Architektur. Bei jedem Veranstaltungsort, an dem mehr als 200 Geräte gleichzeitig erwartet werden, sollten Sie von einem einzelnen /24-Subnetz absehen. Verwenden Sie ein /22-Subnetz oder größer und passen Sie die Lease-Zeiten an das Verweildauerprofil Ihres Standorts an. Ein Hotel setzt Leases auf 8 Stunden. Ein Stadion setzt Leases auf 3 Stunden. Ein Einkaufszentrum setzt Leases auf 90 Minuten. Ein Konferenzzentrum setzt Leases auf 30 Minuten. Als Nächstes sollten Sie Ihren Walled Garden vor jeder größeren Veranstaltung validieren. Die minimal erforderlichen Einträge sind: der vollqualifizierte Domainname (FQDN) Ihres Portals und alle zugehörigen CDN-Domains, die Captive Portal-Erkennungs-URLs für Apple, Google, Windows und Firefox sowie die OAuth-Domains für jeden von Ihnen unterstützten Social-Login-Anbieter. Auf der Plattform von Purple pflegen und aktualisieren wir diese Walled-Garden-Einträge automatisch als Teil unseres cloudbasierten Service, was Ihrem Team den manuellen Pflegeaufwand abnimmt. Verwenden Sie für Ihr Portal-Zertifikat ein öffentlich vertrauenswürdiges TLS-Zertifikat einer anerkannten Zertifizierungsstelle. Selbstsignierte Zertifikate führen auf jedem Gerät zu Browser-Warnungen. Erneuern Sie Zertifikate vor dem Ablaufdatum – ein abgelaufenes Zertifikat ist eine der häufigsten Ursachen für plötzliche, standortweite Portal-Ausfälle. Eine Falle, in die viele IT-Teams tappen: das Testen des Portals mit einem Gerät, das sich bereits zuvor authentifiziert hat. Die Sitzung Ihres Geräts ist noch aktiv, sodass Sie das Portal vollständig umgehen und daraus schließen, dass alles funktioniert. Testen Sie immer mit einem Gerät in einem frischen, unauthentifizierten Zustand – entweder mit einem neuen Gerät oder mit einem, bei dem Sie das Netzwerk ignoriert und das WiFi-Profil gelöscht haben. Lassen Sie mich Ihnen zwei praktische Szenarien vorstellen, die diese Prinzipien veranschaulichen. Szenario eins: Ein Hotel mit 350 Zimmern im Zentrum von London. Das Hotel betrieb ein einzelnes /24-Subnetz für das Gäste-WiFi. Während einer großen Konferenz trafen 400 Delegierte gleichzeitig ein. Innerhalb von 20 Minuten war der DHCP-Pool war erschöpft. Gäste meldeten, dass sie zwar verbunden waren, das Portal oder das Internet jedoch nicht erreichen konnten. Die sofortige Lösung bestand darin, das Subnetz auf /22 zu erweitern, was 1.022 nutzbare Adressen ermöglichte, und die Lease-Zeit von 24 Stunden auf 8 Stunden zu reduzieren. Die langfristige Lösung war die Implementierung des Cloud-managed Captive Portal von Purple, das die Auslastung des DHCP-Pools in Echtzeit überwacht und das Netzwerkteam alarmiert, bevor eine Erschöpfung eintritt. Die Portal-Ausfallrate sank innerhalb von 48 Stunden nach der Änderung auf fast Null. Szenario zwei: Eine große Einzelhandelskette mit 200 Filialen. Die Kette nutzte Social-Login über Google und Facebook auf ihrem Gästeportal. Nachdem Google seine OAuth-Infrastruktur aktualisiert hatte, befanden sich die neuen Authentifizierungsdomänen nicht im Walled Garden. Gäste konnten die Portalseite erreichen, aber die Social-Login-Buttons zeigten nur leere Bildschirme an. Das IT-Team der Kette verbrachte zwei Tage mit der Diagnose des Problems, bevor es die Lücke im Walled Garden identifizierte. Nach der Identifizierung dauerte die Behebung 10 Minuten. Die Lehre daraus: Codieren Sie niemals IP-Adressen für Cloud-basierte OAuth-Anbieter fest in Ihren Walled Garden ein. Verwenden Sie Wildcard-Domain-Einträge und überprüfen Sie diese vierteljährlich. Nun zu einigen kurzen Fragen, die wir regelmäßig von IT-Teams von Veranstaltungsorten hören. Warum funktioniert das Portal auf iPhones, aber nicht auf Android-Geräten? Android verwendet connectivitycheck.gstatic.com als Probe-URL. Wenn diese Domain von Ihrer Firewall blockiert wird oder sich nicht in Ihrem Walled Garden befindet, lösen Android-Geräte das Portal niemals aus. Fügen Sie sie explizit hinzu. Ein Gast berichtet, dass das Portal geladen wurde, er aber nach dem Login nicht online gehen kann. Dies ist fast immer ein RADIUS-Autorisierungsfehler. Überprüfen Sie, ob Ihr RADIUS-Server vom Wireless-Controller aus erreichbar ist, stellen Sie sicher, dass das Shared Secret auf beiden Seiten übereinstimmt, und überprüfen Sie die RADIUS-Protokolle auf Access-Reject-Meldungen. Wie gehen wir mit Gästen um, die nach wenigen Minuten immer wieder abgemeldet werden? Überprüfen Sie Ihre Idle-Timeout-Einstellung. Viele Controller sind standardmäßig auf ein Idle-Timeout von 5 Minuten eingestellt, was für Mobilgeräte, die zwischen Interaktionen in den Ruhemodus wechseln, viel zu aggressiv ist. Stellen Sie das Idle-Timeout für das Hotel- und Gastgewerbe sowie den Einzelhandel auf mindestens 30 Minuten ein. Zusammenfassend die wichtigsten Punkte des heutigen Briefings. Ausfälle des Gäste-WiFi-Captive-Portals lassen sich in sechs Kategorien einteilen: Erschöpfung des DHCP-Pools, Fehler beim DNS-Abfangen, unvollständiger Walled Garden, Blockierung durch HSTS-Weiterleitung, aktives VPN auf dem Client-Gerät und MAC-Adressen-Randomisierung. Für jede Kategorie gibt es eine spezifische, testbare Lösung. Für Ihr IT-Team sind die sofortigen Maßnahmen: Überprüfen Sie Ihre DHCP-Lease-Zeiten und Subnetzgrößen, validieren Sie Ihren Walled Garden anhand der aktuellen OAuth-Domains Ihrer Social-Login-Anbieter und testen Sie Ihr Portal nach jeder Konfigurationsänderung von einem neuen, nicht authentifizierten Gerät aus. Für Ihre längerfristige Roadmap sollten Sie OpenRoaming als Nachfolger der Captive Portal-Reauthentifizierung für wiederkehrende Besucher evaluieren. Die Technologie ist ausgereift, die Standards sind unter IEEE 802.1X und WPA3-Enterprise etabliert, und Purple stellt sie ohne zusätzliche Softwarekosten im Rahmen des Connect-Tarifs zur Verfügung. Purple ist an über 80.000 Standorten im Einsatz und hat allein im Jahr 2024 440 Millionen Logins verarbeitet. Wir haben jedes in diesem Briefing beschriebene Fehlerszenario erlebt – und die Tools entwickelt, um sie zu verhindern. Wenn Sie erfahren möchten, wie sich das Cloud-Overlay von Purple in Ihre bestehende Cisco Meraki-, HPE Aruba-, Ruckus- oder Juniper Mist-Infrastruktur integrieren lässt, besuchen Sie purple.ai oder sprechen Sie mit Ihrem Account Manager. Vielen Dank für Ihre Aufmerksamkeit.