Fehlerbehebung bei Weiterleitungen des Captive Portals: Problemlösung bei Verbindungsproblemen im Gäste-WiFi

Wenn bei einem Gäste-WiFi „Verbunden“ angezeigt wird, aber kein Internet vorhanden ist, ist das Gerät zwar dem Netzwerk beigetreten, die Weiterleitung zum Captive Portal ist jedoch fehlgeschlagen. Die häufigsten Ursachen sind eine blockierte Betriebssystem-Prüfung, fehlende Walled-Garden-Einträge oder ein fehlgeschlagenes DNS. Weitere Gründe sind ein erschöpfter DHCP-Pool oder ein Access-Accept von RADIUS, das das Gateway nie erreicht. Jede dieser Ursachen lässt sich über die Konfiguration beheben.

Wie äußert sich das Problem „Gäste-WiFi verbunden, aber kein Internet“?

Das Gerät stellt eine Verbindung zum Netzwerknamen (SSID) her und zeigt volle Signalstärke an, es wird jedoch nichts geladen. Jede Plattform meldet dies anders:

• iOS zeigt „Keine Internetverbindung“ unter dem Netzwerknamen an.
• Android zeigt „Verbunden, kein Internet“ oder die Aufforderung „Im Netzwerk anmelden“ an, die ins Leere führt.
• Windows markiert das Netzwerk als „Kein Internet“.

Der Besucher sieht ein funktionierendes WiFi-Symbol und einen inaktiven Browser, weshalb er die Schuld beim Veranstaltungsort sucht.

Ein einziges Symptom kann verschiedene Fehlerursachen verbergen. In der Regel tritt eines der folgenden Muster auf:

• Die Anmeldeseite erscheint auf keinem Gerät.
• Die Anmeldeseite erscheint auf iPhones, aber nicht auf Android-Smartphones oder umgekehrt.
• Der Browser zeigt anstelle der Anmeldeseite eine Zertifikats- oder Datenschutzwarnung an.
• Der Besucher füllt das Formular aus, sieht eine Erfolgsmeldung und hat trotzdem kein Internet.
• Zu ruhigen Zeiten funktioniert alles, in Spitzenzeiten schlägt es fehl.

Jedes Muster deutet auf eine andere Ebene des Netzwerks hin. Beginnen Sie mit der Analyse des Musters und nicht mit dem Neustart von Access Points.

Funktionsweise der Captive-Portal-Erkennung

Ein Captive Portal ist die Webseite, die ein Gateway anzeigt, bevor es den Internetzugang gewährt. Bei dem Gateway handelt es sich je nach Architektur um Ihren Controller, Ihre Firewall oder Ihren Access Point.

Jedes gängige Betriebssystem prüft sofort nach dem Beitritt zu einem Netzwerk, ob ein Captive Portal vorhanden ist. Es sendet eine einfache HTTP-Anfrage an eine bekannte Adresse und vergleicht die Antwort mit dem erwarteten Ergebnis. Jedes Ergebnis hat eine andere Bedeutung:

• Die Antwort stimmt überein. Das Gerät geht von einem offenen Internetzugang aus.
• Das Gateway gibt eine HTTP-302-Weiterleitung zurück. Das Gerät erkennt, dass es sich hinter einem Portal befindet. Es öffnet ein reduziertes Browserfenster, häufig als Captive Network Assistant bezeichnet, und lädt Ihre Anmeldeseite.
• Die Anfrage erhält keine Antwort. Das Gerät meldet „Kein Internet“ und öffnet nichts.

Microsoft dokumentiert, dass sein Network Connectivity Status Indicator (NCSI) zur DNS-Prüfung auch dns.msftncsi.com auflöst. Ein Windows-Laptop kann daher auch dann „Kein Internet“ melden, wenn das DNS vor der Authentifizierung fehlerhaft ist, selbst wenn HTTP funktioniert.

Was führt gewöhnlich zum Fehlschlagen einer Captive-Portal-Weiterleitung?

Sieben Ursachen sind für die meisten Fälle verantwortlich. Sie liegen auf verschiedenen Ebenen, von der Adressierung bis hin zur Authentifizierung.

Die Betriebssystem-Sonde wird blockiert

Die Pre-Authentication Access Control List (ACL) des Gateways verwirft die Sonde, anstatt sie umzuleiten. Das Gerät erhält keine Rückmeldung und geht davon aus, dass kein Internet vorhanden ist. Es öffnet das Portal nicht.

Ein DNS-Filterdienst, der die Hostnamen der Sonden blockiert, hat dieselbe Wirkung. Dies ist der häufigste Grund, warum ein Portal gar nicht erst erscheint.

HTTPS und HSTS unterbrechen die Abfangung

HTTP Strict Transport Security (HSTS), definiert in RFC 6797, weist Browser an, eine Domain ausschließlich über HTTPS aufzurufen. Browser werden mit einer Preload-Liste von HSTS-Domains ausgeliefert, darunter die von Google und den meisten Banken. Wenn ein Besucher google.com eingibt, führt der Browser ein Upgrade auf HTTPS durch, bevor die Anfrage das Gerät verlässt.

Das Gateway kann diese Anfrage nicht umleiten, ohne ein Zertifikat für google.com vorzulegen, das es nicht besitzt. Der Browser zeigt eine strenge Sicherheitswarnung an, die nicht umgangen werden kann.

Die Lösung besteht darin, nur die einfachen HTTP-Sonden in der obigen Tabelle umzuleiten, die genau zu diesem Zweck existieren. Fangen Sie HTTPS niemals für eine Portal-Umleitung ab.

Das Walled Garden ist zu stark eingeschränkt

Das Walled Garden ist die Liste der Domains und IP-Adressen, die ein Gerät vor der Authentifizierung erreichen kann. Wenn ein Eintrag fehlt, wird die Anmeldeseite nur teilweise geladen oder der Anmeldeschritt schlägt fehl. Typische Lücken sind:

• Endpunkte von Identitätsanbietern für Social Logins oder Single Sign-On, wie z. B. Microsoft Entra ID, Okta oder Google Workspace.
• Content Delivery Network-Domains, die Schriftarten, Skripte und Stylesheets Ihrer Anmeldeseite bereitstellen.
• Domains von Zahlungsdienstleistern, falls Sie gebührenpflichtigen Zugang anbieten.
• Die Endpunkte für das Captive Portal und RADIUS von Purple, die im Integrationshandbuch von Purple für Ihre Hardware aufgeführt sind.

DNS schlägt vor der Authentifizierung fehl

Das Gerät muss den Hostnamen des Portals auflösen, bevor es die Seite laden kann. Die Umleitung führt in zwei Fällen ins Leere:

• Das Gateway blockiert DNS im Status vor der Authentifizierung.
• DHCP weist einen DNS-Server zu, den das Gerät nicht erreichen kann.

Android sorgt für eine zusätzliche Besonderheit. Wenn ein Besucher einen spezifischen privaten DNS-Hostnamen eingerichtet hat, erwartet Android DNS over TLS auf Port 853. Im automatischen Modus fällt es auf normales DNS zurück.

Der DHCP-Pool ist erschöpft

Wenn der Adresspool erschöpft ist, verbindet sich ein neues Gerät zwar mit dem Access Point, erhält jedoch keine IP-Adresse. Windows weist sich dann selbst eine verbindungslokale Adresse aus dem Bereich 169.254.x.x zu, und andere Systeme zeigen einen ähnlichen selbst zugewiesenen Status an.

Ohne eine gültige Adresse kann das Gerät keine Sonde senden. Es sieht so aus, als ob eine Verbindung besteht, es ist jedoch kein Internet verfügbar. Dies ist der klassische Ausfall zu Spitzenzeiten in Stadien, Konferenzzentren und Verkehrsknotenpunkten.

RADIUS stellt das Access-Accept nie zu

RADIUS (Remote Authentication Dial-In User Service) übermittelt die Anmeldeentscheidung vom Authentifizierungsserver an Ihr Gateway. Der Server antwortet mit Access-Accept oder Access-Reject, wie in RFC 2865 definiert. Das Gateway gibt den Zugriff daraufhin frei oder hält ihn geschlossen.

Wenn ein Besucher das Formular ausfüllt, aber offline bleibt, bedeutet dies fast immer, dass das Gateway die Access-Accept-Nachricht verpasst hat. Die drei häufigsten Ursachen sind:

• Ein nicht übereinstimmendes Shared Secret.
• Eine Firewall, die UDP 1812 (Authentifizierung) oder UDP 1813 (Accounting) blockiert. Diese Ports sind in RFC 2865 und RFC 2866 definiert.
• Eine falsche Serveradresse auf dem Controller.

Das eigene Zertifikat des Portals ist abgelaufen

Ihre Anmeldeseite wird über HTTPS bereitgestellt. Wenn ihr TLS-Zertifikat ablauft, blockiert jeder moderne Browser die Seite mit einer Sicherheitswarnung. Die Weiterleitung funktioniert einwandfrei, dennoch kann sich der Besucher nicht anmelden.

Wie finden Sie heraus, welche Ursache vorliegt?

Arbeiten Sie sich im Protokollstapel der Reihe nach nach oben. Jede Prüfung schließt eine Schicht aus. Stoppen Sie daher beim ersten Fehler.

1. Hat das Gerät eine gültige IP-Adresse? Führen Sie ipconfig /all unter Windows aus oder überprüfen Sie die Netzwerkdetails auf einem Smartphone. Eine 169.254.x.x-Adresse oder gar keine Adresse deutet auf ein DHCP-Problem hin. Überprüfen Sie die Pool-Auslastung auf dem DHCP-Server. Liegt sie über 90 %, steht der Pool kurz vor der Erschöpfung.
2. Wird die DNS aufgelöst? Rufen Sie von einem Gerät im Gäste-VLAN (VLAN) - einem logisch getrennten Netzwerksegment - den Hostnamen des Portals auf. Schlägt die Abfrage fehl, ist das Pre-Authentication-DNS blockiert oder der vom DHCP zugewiesene DNS-Server ist falsch.
3. Erhält die Überprüfung einen HTTP 302? Erstellen Sie ein Packet Capture auf dem Gäste-VLAN oder rufen Sie eine der HTTP-Prüf-URLs auf. Sie sollten die Anfrage sehen, gefolgt von einem HTTP 302, der auf das Portal verweist. Eine Anfrage ohne Antwort bedeutet, dass die ACL sie verwirft. Wird gar keine Anfrage gesendet, geht das Gerät davon aus, dass es bereits online ist, oft aufgrund eines zwischengespeicherten Status. Ignorieren Sie das Netzwerk und verbinden Sie sich erneut.
4. Wird die Anmeldeseite vollständig geladen? Öffnen Sie die Entwicklertools des Browsers (F12) und beobachten Sie die Registerkarte „Netzwerk“. Blockierte Anfragen an Drittanbieter-Domains deuten auf Lücken im Walled Garden hin.
5. Empfängt das Gateway ein Access-Accept? Überprüfen Sie die RADIUS-Protokolle des Controllers. Nach einer erfolgreichen Anmeldung folgt ein Accounting-Request mit dem Status Start. Wenn nach der Anmeldung kein Accounting-Datensatz erscheint, ist der RADIUS-Pfad unterbrochen.

Vergleichen Sie anschließend Ihre Beobachtungen mit dieser Tabelle.

Praxisszenario: Ein Konferenzzentrum mit 1.500 Plätzen zu Spitzenzeiten

Situation. Ein Konferenzzentrum betrieb sein Teilnehmernetzwerk auf einem einzelnen /24-Subnetz mit einer achtstündigen DHCP-Lease-Zeit. Die Keynotes am Morgen verliefen reibungslos. Nach dem Mittagessen erhielten Besucher, die zu den Nachmittagssitzungen eintrafen, die Meldung „verbunden, kein Internet“. Der Helpdesk stufte dies als Portalfehler ein und startete den Controller zweimal neu.

Was getan wurde. Schritt 1 der Diagnose ergab, dass neue Geräte 169.254.x.x-Adressen hielten. Ein /24-Subnetz bietet 254 nutzbare Adressen, und die achtstündige Lease-Zeit hielt jede Adresse vom Morgen reserviert. Das Team verschob die Teilnehmer-VLAN auf ein /21-Subnetz und verkürzte die Lease-Zeit auf 30 Minuten.

Ergebnis. Die Zahl der nutzbaren Adressen stieg von 254 auf 2.046, was etwa der achtfachen bisherigen Kapazität entspricht. Eine Adresse, die von einem abreisenden Teilnehmer hinterlassen wird, kehrt nun innerhalb von 30 Minuten statt acht Stunden in den Pool zurück. Die Behebung erforderte ein einziges Wartungsfenster und keine neue Hardware.

Praxisszenario: Ein Hotel mit 200 Zimmern, in dem sich Android-Gäste nicht anmelden konnten

Situation. Nach einer Neugestaltung der Anmeldeseite erhielt ein Hotel mit 200 Zimmern Beschwerden von Android-Gästen an der Rezeption. Die meisten von ihnen wählten die Option für die Google-Anmeldung. Das Portal erschien, aber die Schaltfläche zeigte keine Reaktion.

Was getan wurde. Der IT-Manager testete den Ablauf auf einem iPhone, einem Android-Smartphone und einem Windows-Laptop. Entwickler-Tools auf dem Laptop zeigten blockierte Anfragen an ein Netzwerk zur Bereitstellung von Schriftarten und an die Anmeldedomänen von Google. Durch die Neugestaltung waren beide hinzugefügt worden. Das Team fügte sie dem Walled Garden hinzu.

Ergebnis. Die Google-Anmeldung wurde beim ersten erneuten Test auf allen drei Testgeräten erfolgreich abgeschlossen. Die Behebung erforderte zwei Walled-Garden-Einträge und keine Hardwareänderung.

Praxisszenario: Ein Filialnetz mit 40 Geschäften nach einer Firewall-Aktivierung

Situation. Ein Einzelhändler ersetzte an einem Wochenende die Firewalls in 40 Filialen. Am Montag konnten Käufer in jeder aktualisierten Filiale das Anmeldeformular ausfüllen, blieben jedoch offline. Filialen, die noch nicht aktualisiert wurden, funktionierten normal.

Was getan wurde. Schritt 5 ergab keine Accounting-Datensätze aus den aktualisierten Filialen. Die neue Firewall-Vorlage lehnte ausgehendes UDP standardmäßig ab und blockierte 1812 und 1813. Das Team fügte der Vorlage explizite ausgehende Regeln hinzu und spielte sie auf alle 40 Filialen ein.

Ergebnis. Nach dem Einspielen erschienen wieder Accounting-Datensätze aus allen Filialen. Da nur aktualisierte Filialen ausfielen, deutete das Muster direkt auf die Vorlage und nicht auf den WiFi hin.

Wie beheben Sie das Problem auf den einzelnen Betriebssystemen und Controllern?

Die Behebung auf dem Controller folgt auf jeder Plattform demselben Muster. Bei den Behebungen für die Betriebssysteme geht es hauptsächlich darum zu wissen, wie sich das jeweilige System verhält.

Auf Ihrem Controller

Purple läuft als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Das Muster zur Behebung ist auf allen acht Systemen identisch:

1. Leiten Sie das Gäste-SSID auf die externe Captive Portal-URL aus Ihrer Purple-Integrationsanleitung weiter und deaktivieren Sie lokale Anmeldeseiten.
2. Leiten Sie nicht authentifizierten HTTP-Datenverkehr, einschließlich der Probes, an diese URL weiter. Belassen Sie HTTPS unverändert.
3. Lassen Sie DNS und DHCP vor der Authentifizierung zu.
4. Fügen Sie die Walled-Garden-Einträge hinzu: Purple-Endpunkte, Identity-Provider-Endpunkte und Domains für Anmeldeseiten-Assets.
5. Geben Sie die RADIUS-Serveradressen und das Shared Secret aus Ihrem Purple-Dashboard ein. Bestätigen Sie anschließend, dass die Firewall ausgehendes UDP 1812 und 1813 zulässt.

Die Menübezeichnungen variieren je nach Anbieter und Firmware-Version. Befolgen Sie daher die Purple-Integrationsanleitung für Ihre Plattform. Die Community-Dokumentation von Fortinet zum FortiGate Captive Portal-Ablauf ist eine nützliche herstellerseitige Referenz für die Weiterleitungssequenz.

Auf iOS und macOS

Wenn sich der Captive-Network-Assistant nicht öffnet, entfernen Sie das Netzwerk in den Einstellungen und verbinden Sie sich erneut. Dies erzwingt eine neue Probe.

Neuere iOS- und macOS-Versionen unterstützen zudem den Captive Portal API. Dadurch kann das Netzwerk sein Portal über die in RFC 8910 definierte DHCP-Option 114 ankündigen, was die Abhängigkeit von Interception verringert. Wenn sich der Assistant öffnet, aber leer bleibt, überprüfen Sie den Walled Garden auf Asset-Domains.

Auf Android

Android zeigt die Benachrichtigung „Im Netzwerk anmelden“ an, wenn ein Portal erkannt wird. Wenn die Benachrichtigung nicht erscheint, stellen Sie sicher, dass das Gateway connectivitycheck.gstatic.com weiterleitet, anstatt die Verbindung zu trennen.

Wenn einem Besucher „Auf den privaten DNS-Server kann nicht zugegriffen werden“ angezeigt wird, ist auf seinem Smartphone ein strikter privater DNS-Hostname eingestellt. Sie haben zwei Optionen:

• Lassen Sie DNS over TLS auf Port 853 vor der Authentifizierung zu.
• Bitten Sie den Besucher, Privates DNS auf automatisch umzustellen.

Auf Windows

Windows stützt sich auf die NCSI-HTTP-Probe und deren DNS-Prüfung. Wenn sich das Portal nicht automatisch öffnet, rufen Sie eine beliebige reine HTTP-Website auf, um die Weiterleitung manuell auszulösen. Eine dauerhafte Anzeige von „Kein Internet“ nach dem Login bedeutet in der Regel, dass das Gateway die Probe weiterhin weiterleitet. In diesem Fall hat das Gateway das Access-Accept noch nicht angewendet.

Im Browser

Weisen Sie das Servicepersonal an, Besucher auf eine HTTP-Adresse zu verweisen, niemals auf eine HSTS-Domain wie google.com. Firefox führt eine eigene Probe gegen detectportal.firefox.com aus. Schließen Sie diesen Host daher in Ihre Weiterleitungstests ein.

Wie verhindern Sie erneute Weiterleitungsfehler beim Gäste-WiFi?

Die meisten wiederkehrenden Vorfälle entstehen durch Änderungen und nicht durch die ursprüngliche Einrichtung. Ein Firmware-Update, eine neue Firewall-Vorlage, ein Neudesign der Anmeldeseite oder ein ablaufendes Zertifikat werden bei Tests übersehen. Integrieren Sie diese Kontrollen in Ihren Change-Prozess:

• Testen Sie nach jeder Änderung auf drei Plattformen. Verwenden Sie ein iPhone, ein Android-Smartphone und einen Windows-Laptop. Wenn eine Plattform fehlschlägt, während die anderen erfolgreich sind, prüfen Sie zuerst, ob eine Lücke im Walled Garden vorliegt.
• Dimensionieren Sie für Spitzenzeiten, nicht für den Durchschnitt. Berechnen Sie die maximale Anzahl gleichzeitiger Geräte und planen Sie Puffer ein. Bei temporären Besuchernetzwerken sind Lease-Zeiten von 15 bis 30 Minuten üblich.
• Sitzungsdauer an den Besuch anpassen. Gastronomie- und Einzelhandelsstandorte richten häufig 24-Stunden-Sitzungen ein, sodass sich ein Gast nur einmal pro Aufenthalt oder Besuch anmeldet.
• Tägliche Anmeldezahlen überwachen. WiFi Analytics von Purple berichtet über Anmeldungen nach Standort. Ein plötzlicher Abfall an einem Standort warnt Sie vor einem Fehler beim RADIUS oder beim Walled Garden, oft bevor sich Besucher beschweren.
• Zertifikate und Shared Secrets unter Change Control stellen. Tragen Sie das Ablaufdatum des Portalzertifikats in den Kalender ein. Speichern Sie das shared secret des RADIUS so, dass sowohl Firewall- als auch Controller-Teams Zugriff darauf haben.
• Gästeverkehr segmentieren. Weisen Sie Gästen ein eigenes VLAN zu. PCI DSS betrachtet die Segmentierung als Methode, um ein Gästenetzwerk außerhalb des Geltungsbereichs Ihrer Karteninhaber-Datenumgebung zu halten.
• MAC-Randomisierung einplanen. Neuere Versionen von iOS und Android verwenden eine zufällige MAC-Adresse für jedes Netzwerk, und einige Modi rotieren diese im Laufe der Zeit. Wenn das Session-Caching auf der MAC-Adresse basiert, werden wiederkehrende Besucher aufgefordert, sich erneut anzumelden.
• Einwilligungen ordnungsgemäß einholen. Die GDPR erfordert eine transparente, aktive Einwilligung für Marketingdaten. Die Conscious-Choice-Opt-ins von Purple bieten für jeden Zweck eine separate Auswahlmöglichkeit.

Wiederkehrende Besucher nicht über das Captive Portal leiten

Die dauerhafteste Lösung entfernt die Weiterleitung bei wiederholten Besuchen vollständig.

• Passpoint ist die Branchenzertifizierung, die auf der Hotspot 2.0-Spezifikation aufbaut. Sie ermöglicht es einem Gerät, einem Netzwerk mithilfe eines gespeicherten Profils automatisch beizutreten.
• OpenRoaming, betrieben von der Wireless Broadband Alliance, verbindet Identitätsanbieter. Die vorhandenen Anmeldedaten eines Besuchers funktionieren dann an allen teilnehmenden Standorten.

Beide nutzen IEEE 802.1X, den Standard für portbasierte Netzwerzzugangskontrolle, sodass kein Portal vorhanden ist, das Fehler verursachen könnte.

Wo Purple ansetzt

Purple Gäste-WiFi läuft als hardwareunabhängiges Cloud-Overlay, sodass Sie Weiterleitungsfehler in der Konfiguration beheben und nicht durch neue Hardware. Purple bedient mehr als 80.000 aktive Standorte in über 90 Ländern und unterstützt 500 Millionen Nutzer und Anmeldungen pro Jahr. Die Plattform läuft mit einer Verfügbarkeit von 99,999 % und ist nach ISO 27001, Cyber Essentials sowie B Corp zertifiziert. Zudem ist sie GDPR- und CCPA-konform.

Wenn ein Portal fehlschlägt, liegt die Ursache fast immer lokal: eine Probe-Regel, ein Walled-Garden-Eintrag, ein DHCP-Pool oder eine Firewall-Regel.

Die Muster wiederholen sich über verschiedene Branchen hinweg:

• Hotels spüren Umleitungsfehler zu Peak-Zeiten beim Check-in.
• Filialisten spüren sie nach unternehmensweiten Firewall-Änderungen.
• Züge und Bahnhöfe stehen unter DHCP-Druck, wenn Passagiere schubweise einsteigen.
• Standorte im Gesundheitswesen benötigen ein Gäste-WiFi, das funktioniert, ohne dass das medizinische Personal in Support-Anrufe verwickelt wird.

Häufig gestellte Fragen

Funktioniert Purple mit den Access Points, die wir bereits besitzen?

Ja. Purple ist hardwareunabhängig und läuft als Cloud-Overlay auf Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Sie behalten Ihre bestehenden Access Points und Controller. Sie richten Ihr Gäste-SSID auf das Captive Portal von Purple aus, fügen die Walled-Garden-Einträge sowie RADIUS-Details aus der Integrationsanleitung von Purple hinzu und testen anschließend. Es ist kein Austausch von Hardware erforderlich.

Benötigen wir neue Hardware, um das Problem "Gäste-WiFi verbunden, aber kein Internet" zu beheben?

Nein. In fast allen Fällen liegt der Fehler in der Konfiguration: eine blockierte Probe, eine Lücke im Walled Garden, Pre-Authentication-DNS, ein erschöpfter DHCP-Pool oder eine RADIUS-Firewall-Regel. Sie beheben jeden einzelnen Punkt auf dem Controller, der Firewall oder dem DHCP-Server, den Sie bereits betreiben. Hardware wird erst dann zum Thema, wenn die Access-Point-Dichte Ihre maximale Geräteanzahl nicht mehr bedienen kann, was eine Standortanalyse zeigt.

Was ist erforderlich, um unser Gäste-WiFi zu Purple zu migrieren?

Der Wechsel zu Purple ist ein Konfigurationsprojekt, kein Installationsprojekt. Auf jedem Controller stellen Sie das Gäste-SSID auf das externe Portal von Purple ein und fügen die Walled-Garden- und RADIUS-Einstellungen hinzu. Anschließend bestätigen Sie die Firewall-Regeln für UDP 1812 und 1813. Als Nächstes erstellen Sie Ihre Anmeldeseite sowie die Einwilligungsoptionen in Purple und testen diese auf iOS, Android und Windows. Unternehmen mit mehreren Standorten können die Controller-Einstellungen als Vorlage nutzen.

Ist ein Captive Portal konform mit der GDPR?

Ja, sofern die Einwilligung informiert, spezifisch und freiwillig erfolgt. Die GDPR erfordert eine separate, aktive Zustimmung für jeden Zweck, wie z. B. Marketing-E-Mails, und schließt vorausgefüllte Kontrollkästchen aus. Die Opt-ins von Purple für bewusste Entscheidungen präsentieren jede Option separat. Purple ist ISO 27001-zertifiziert, hält Cyber Essentials und ist konform mit der GDPR sowie der CCPA. Das bietet Ihrem Datenschutzbeauftragten genau die Standards, nach denen er fragen wird.

Können wiederkehrende Besucher die Anmeldeseite überspringen?

Ja. Passpoint und OpenRoaming ermöglichen einem Gerät den automatischen Beitritt über ein gespeichertes Profil oder eine föderierte Identität. Beide nutzen die IEEE 802.1X-Authentifizierung mit WPA2- oder WPA3-Enterprise-Verschlüsselung, sodass bei wiederholten Besuchen keine Umleitung zum Captive Portal fehlschlagen kann. Viele Veranstaltungsorte nutzen beides: ein Captive Portal für Erstbesucher und die Datenerfassung sowie OpenRoaming für wiederkehrende Gäste, Passagiere und Studenten.

Woher wissen wir, wann Anmeldungen fehlschlagen?

Überwachen Sie das Anmeldeaufkommen nach Standort. Die Analysen von Purple für WiFi weisen die Anmeldungen für jeden Standort aus, sodass ein plötzlicher Rückgang an einem Standort im Vergleich zu seinem normalen Muster und Ihren anderen Standorten sofort auffällt. Dieser Rückgang deutet in der Regel auf ein RADIUS, ein Walled Garden oder einen DHCP-Fehler hin, der durch eine kürzliche Änderung verursacht wurde. Die Erkennung im Dashboard geht schneller als das Warten auf Beschwerden vom Empfang an die IT.

Sollten wir ein Captive Portal oder ein gemeinsam genutztes WiFi-Passwort verwenden?

Verwenden Sie ein Captive Portal, wenn Sie First-Party-Daten und Einwichtigungen erfassen möchten, und ein gemeinsam genutztes Passwort nur dann, wenn Sie beides nicht benötigen. Ein gemeinsam genutzter Pre-Shared Key verschlüsselt den Datenverkehr mit WPA2 oder WPA3-Personal. Er verrät Ihnen jedoch nichts darüber, wer sich verbunden hat, und das Passwort verbreitet sich. Ein Captive Portal erfasst eingewilligte First-Party-Daten, und Passpoint oder OpenRoaming fügt automatischen, verschlüsselten Zugang für wiederkehrende Besuche hinzu.