Fehlerbehebung bei öffentlichem WiFi: Behebung von "Verbunden, kein Internet" und Fehlern bei der Weiterleitung zur Splash Page

Willkommen zu diesem technischen Briefing von Purple. Heute widmen wir uns einem der hartnäckigsten und am meisten missverstandenen Probleme in drahtlosen Netzwerken für Unternehmen: dem Captive Portal für das Gäste-WiFi, das einfach nicht geladen wird. Sie kennen das sicherlich. Ein Gast kommt in Ihr Hotel, Ihr Ladengeschäft, Ihr Stadion oder Ihr Konferenzzentrum. Er verbindet sich mit dem WiFi-Netzwerk. Nichts passiert. Keine Anmeldeseite. Kein Internet. Nur ein sich drehendes Lade-Symbol und wachsende Frustration. Für Betriebsleiter und IT-Manager ist dieser Moment nicht nur eine kleine Unannehmlichkeit. Er bedeutet ein direktes Scheitern Ihres Gästeerlebnisses, einen sprunghaften Anstieg von Support-Anfragen am Empfang und eine verpasste Gelegenheit zur Erfassung von First-Party-Daten, die Ihre Investitionen in die drahtlose Infrastruktur rechtfertigen. In diesem Briefing blicken wir hinter die Kulissen. Wir erklären genau, wie die Erkennung von Captive Portalen auf Betriebssystemebene funktioniert, identifizieren die sechs Hauptursachen, die für die überwiegende Mehrheit der Verbindungsprobleme verantwortlich sind, und an die Hand Ihrer IT-Abteilung geben können. Beginnen wir mit der Funktionsweise. Die meisten Menschen halten ein Captive Portal für eine einfache Anmeldeseite. In Wirklichkeit handelt es sich jedoch um einen Mechanismus zum Abfangen des Datenverkehrs auf Netzwerkebene - und dieser Unterschied ist von enormer Bedeutung, wenn Probleme auftreten. Der Ablauf sieht wie folgt aus: Das Gerät eines Gastes verbindet sich mit Ihrer Gäste-SSID und erhält über DHCP eine IP-Adresse. Zu diesem Zeitpunkt 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 vom Hersteller kontrollierte 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 einen eigenen Probe unter detectportal.firefox.com. Wenn das Netzwerk über einen offenen Internetzugang verfügt, liefern diese Probes die erwarteten Antworten, und das Betriebssystem geht davon aus, dass alles in Ordnung ist. In einem Gästenetzwerk fängt Ihr Wireless-Gateway oder -Controller diese HTTP-Probe 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 isoliertes Browserfenster - oft auch als Captive Network Assistant bezeichnet -, um die Anmeldeseite anzuzeigen. Das ist der Idealfall. Kommen wir nun zu den sechs Gründen, warum dieser Prozess scheitern kann. Hauptursache Nummer eins: Erschöpfung des DHCP-Pools. Dies ist der stille Killer bei Events 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-Time 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-Times für Gäste in Umgebungen mit hoher Fluktuation auf 15 bis 30 Minuten ein und dimensionieren Sie Ihre Subnetze passend für Spitzenwerte bei den gleichzeitigen Nutzern, nicht nur für die Gesamtteilnehmerzahl. Hauptursache Nummer zwei: Fehler bei der DNS-Abfangung. Die Weiterleitung zum Captive Portal hängt davon ab, dass das Gateway den HTTP-Probe abfängt. Der Probe erfordert jedoch zuerst eine DNS-Abfrage. Wenn Ihre DNS-Konfiguration es nicht authentifizierten Clients nicht erlaubt, externe Domainnamen aufzulösen, wird der Probe gar nicht erst ausgelöst. Stellen Sie sicher, dass Ihre Firewall-Richtlinie DNS-Anfragen von nicht authentifizierten Clients explizit zulässt, und überprüfen Sie das Abfangen von DNS-Anfragen, indem Sie ein Packet Capture auf einem Testgerät durchführen. Hauptursache Nummer drei: Unvollständiger Walled Garden. Der Walled Garden - auch bekannt als Pre-Authentication Access Control List - definiert, welche externen Domains nicht authentifizierte Gäste erreichen können. Wenn die Splash-Page Ihres Portals Assets von einem CDN lädt, das sich nicht im Walled Garden befindet, wird die Seite als leerer Bildschirm dargestellt. Wenn Sie Social Login über Google, Apple oder Facebook anbieten, muss jede von diesen Anbietern genutzte OAuth-Domain auf die Whitelist gesetzt werden. Und hier ist der entscheidende Punkt: Social-Identity-Provider aktualisieren ihre CDN-IP-Bereiche und Authentifizierungsdomains 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. Bei Cisco Meraki, HPE Aruba, Ruckus und Juniper Mist ist dies nativ verfügbar. Hauptursache Nummer vier: Blockieren der Weiterleitung durch HSTS. HTTP Strict Transport Security - oder 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 HSTS-vorgeladene 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 einen Zertifikatskonflikt. Es wird eine nicht umgehbare Sicherheitswarnung angezeigt und die Weiterleitung komplett blockiert. Die richtige Lösung besteht darin, niemals zu versuchen, HTTPS-Verbindungen abzufangen. Ihr Gateway sollte nur die unverschlüsselten HTTP-Canary-Probes weiterleiten. Die langfristige, standardbasierte Lösung ist RFC 8910, der die DHCP-Option 114 definiert. Diese Option ermöglicht es Ihrem DHCP-Server, die Captive Portal-URL direkt an das Client-Gerät zu senden, wodurch eine HTTP-Weiterleitung vollständig überflüssig wird. iOS 14 und Android 11 und höher unterstützen dies nativ. Fehlerquelle Nummer fünf: Ein aktives VPN auf dem Endgerät des Gastes. Ein VPN verschlüsselt den gesamten Datenverkehr des Geräts und leitet ihn durch einen externen Tunnel, bevor er Ihr Gateway erreicht. Ihr Gateway sieht die HTTP-Abfrage somit nie. Die Erkennungssequenz für das Captive Portal wird nicht ausgelöst. Der Gast sieht weder eine Anmeldeseite noch hat er 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 Ihre Mitarbeiter an der Rezeption oder dem Empfang sollte dies die erste Frage sein, wenn ein Gast ein Verbindungsproblem meldet. Fehlerquelle Nummer sechs: MAC-Adressen-Randomisierung, die die Sitzungsstabilität beeinträchtigt. 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 Portals anhand der MAC-Adresse nachverfolgt wird, kann ein Gast, der sich vor einer Stunde authentifiziert hat, nach der Änderung der MAC-Adresse seines Geräts erneut zur Anmeldeseite weitergeleitet werden. Die gastseitige Lösung besteht darin, die Option "Private WLAN-Adresse" für Ihre spezifische SSID in den Netzwerkeinstellungen zu deaktivieren. Die betreiberseitige Lösung ist die Implementierung einer profilbasierten Authentifizierung - wie OpenRoaming über Passpoint und 802.1X -, die auf Layer 2 mithilfe von Zugangsdaten 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. Für jeden Standort, 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 legt die Leases auf 8 Stunden fest. Ein Stadion stellt die Leases auf 3 Stunden ein. Ein Einkaufszentrum wählt 90 Minuten. Ein Konferenzzentrum setzt die Leases auf 30 Minuten. Prüfen Sie als Nächstes Ihre Walled Garden-Einstellungen vor jeder größeren Veranstaltung. Die erforderlichen Mindesteinträge sind: der vollqualifizierte Domänenname (FQDN) Ihres Portals und alle zugehörigen CDN-Domänen, die URLs zur Erkennung des Captive Portals für Apple, Google, Windows und Firefox sowie die OAuth-Domänen 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 cloud-managed Service, was Ihr Team von der manuellen Wartung entlastet. 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 Ausfälle des Portals. 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 fälschlicherweise annehmen, dass alles funktioniert. Testen Sie immer mit einem Gerät in einem frischen, unauthentifizierten Zustand - entweder mit einem neuen Gerät oder einem, bei dem Sie das Netzwerk gelöscht und das WiFi Profil bereinigt haben.Lassen Sie mich Ihnen zwei Szenarien aus der Praxis vorstellen, die diese Prinzipien veranschaulichen. Szenario eins: Ein Hotel mit 350 Zimmern im Zentrum von London. Das Anwesen betrieb ein einzelnes Slash-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 erschöpft. Gäste meldeten, dass sie zwar verbunden waren, aber das Captive Portal oder das Internet nicht erreichen konnten. Die Sofortmaßnahme bestand darin, das Subnetz auf Slash-22 zu erweitern, was 1.022 nutzbare Adressen bereitstellte, und die Lease-Zeit von 24 Stunden auf 8 Stunden zu verkürzen. Die langfristige Lösung war die Implementierung des cloud-gesteuerten Captive Portal von Purple, das die Auslastung des DHCP-Pools in Echtzeit überwacht und das Netzwerkteam alarmiert, bevor eine Erschöpfung eintritt. Die Ausfallrate des Portals sank innerhalb von 48 Stunden nach der Änderung auf nahezu Null. Szenario zweit: 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. Die Behebung dauerte nach der Identifizierung nur 10 Minuten. Die Lektion: Codieren Sie niemals IP-Adre ssen fest in Ihrem Walled Garden für Cloud-basierte OAuth-Anbieter. Verwenden Sie Wildcard-Domain-Einträge und überprüfen Sie diese vierteljährlich. Nun zu einigen schnellen Fragen, die wir regelmäßig von IT-Teams in Veranstaltungsorten hören. Warum funktioniert das Portal auf iPhones, aber nicht auf Android-Geräten? Android verwendet connectivitycheck.gstatic.com als Test-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 sagt, das Portal wurde geladen, aber er kommt nach dem Login nicht online. Dies ist fast immer ein RADIUS-Autorisierungsfehler. Überprüfen Sie, ob Ihr RADIUS-Server vom Wireless Controller aus erreichbar ist, verifizieren Sie, 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 ausgeloggt 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 Ruhezustand wechseln, viel zu aggressiv ist. Stellen Sie das Idle-Timeout für Hotellerie- und Einzelhandelsumgebungen auf mindestens 30 Minuten ein. Um die wichtigsten Punkte des heutigen Briefings zusammenzufassen. Ausfälle von Gäste-WiFi Captive Portals lassen sich in sechs Kategorien einteilen: DHCP-Pool-Erschöpfung, DNS-Interzeptionsfehler, unvollständiger Walled Garden, HSTS-Weiterleitungsblockierung, aktives VPN auf dem Client-Gerät und MAC-Adressen-Randomisierung. Jedes Problem hat eine spezifische, testbare Lösung. Für Ihr IT-Team sind die sofortigen Maßnahmen: Überprüfen Sie Ihre DHCP-Lease-Zeiten und Subnetz-Größen, validieren Sie Ihren Walled Garden mit den aktuellen OAuth-Domains Ihrer Social-Login-Anbieter und testen Sie Ihr Portal nach jeder Konfigurationsänderung von einem neuen, nicht authentifizierten Gerät aus. Bewerten Sie für Ihre längerfristige Roadmap OpenRoaming als Nachfolger der Captive Portal-Reauthentifizierung für wiederkehrende Besucher. Die Technologie ist ausgereift, die Standards sind unter IEEE 802.1X und WPA3-Enterprise etabliert, und Purple stellt sie im Rahmen des Connect-Tarifs ohne zusätzliche Softwarekosten zur Verfügung. Purple ist an über 80.000 Standorten im Einsatz und hat allein im Jahr 2024 über 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 Infrastruktur von Cisco Meraki, HPE Aruba, Ruckus oder Juniper Mist integrieren lässt, besuchen Sie purple.ai oder sprechen Sie mit Ihrem Account Manager. Vielen Dank für Ihre Aufmerksamkeit.