Fehlerbehebung beim Cisco Meraki Captive Portal: Checkliste für Splash-Page, Walled Garden und RADIUS

Ein Meraki Captive Portal, das nicht funktioniert, hat in der Regel einen von vier Fehlern. Der Splash-Page-Typ ist falsch oder im Walled Garden fehlen die Domains und Assets des Portals. Die Weiterleitung der Grant-URL ist möglicherweise unterbrochen oder die Access Points können RADIUS mit einem übereinstimmenden Shared Secret nicht erreichen. Das Meraki-Ereignisprotokoll zeigt Ihnen, welcher Fehler vorliegt.

Wie sieht ein nicht funktionierendes Meraki Captive Portal aus?

Drei Symptome decken die meisten Support-Tickets ab. Jedes davon weist auf ein anderes Glied in der Login-Kette hin.

• Die Splash-Page erscheint nie. Das Gerät verbindet sich mit der SSID und erhält eine IP-Adresse, aber es öffnet sich keine Aufforderung zur Anmeldung.
• Das Portal befindet sich in einer Endlosschleife. Der Gast füllt das Formular aus, tippt auf Verbinden und landet wieder auf der Login-Seite.
• Das Portal akzeptiert die Daten, gewährt aber keinen Zugriff. Die Seite meldet Erfolg, aber das Gerät bleibt im Captive Portal gefangen.

Ein viertes Symptom ist unauffälliger. Wiederkehrende Gäste werden viel häufiger als erwartet aufgefordert, sich anzumelden. Das ist selten ein Portal-Fehler. Es liegt meistens an der Einstellung für die Splash-Häufigkeit.

Bevor Sie Änderungen vornehmen, überprüfen Sie, wie die Kette funktionieren sollte. Bei einer Purple-Bereitstellung leitet der Meraki Access Point das Gerät an die Splash-Page-Server von Purple weiter. Die Splash-Page erfasst die Daten des Gasts und erteilt ein einmaliges Login. Der Access Point leitet dieses Login dann an den RADIUS-Server von Purple weiter, um die Authentifizierung abzuschließen. Der Support-Artikel zum Purple Captive Portal beschreibt diesen Ablauf. Jedes Symptom weist darauf hin, dass eine dieser drei Weiterleitungen fehlgeschlagen ist.

Dieses Handbuch setzt voraus, dass die SSID bereits eingerichtet ist. Es ergänzt die Einrichtungsanleitung für das Meraki Captive Portal und wiederholt nicht die Einrichtungsschritte.

Was führt normalerweise dazu, dass eine Meraki-Splash-Page nicht angezeigt wird oder in einer Endlosschleife hängen bleibt?

Der Splash-Page-Typ stimmt nicht mit dem Portal überein

Meraki bietet Click-Through, Anmeldung mit einem RADIUS-Server und Optionen für ein externes Captive Portal. Das Portal und die SSID müssen dieselbe Methode erwarten.

Ein externes Click-Through-Portal gibt das Gerät durch den Aufruf einer Grant-URL frei. Ein externes Anmelde-Portal sendet Anmeldedaten, die der Access Point mit RADIUS abgleicht. Wenn die SSID und das Portal nicht übereinstimmen, schlägt die Weiterleitung fehl und der Gast befindet sich in einer Endlosschleife.

Der Walled Garden ist unvollständig

Der Walled Garden listet die Ziele auf, die ein Gerät erreichen kann, bevor es sich authentifiziert. Meraki akzeptiert Einträge als Domains oder IP-Bereiche. Wenn die eigene Domain des Portals fehlt, kann die Splash-Page überhaupt nicht geladen werden.

Fehlende Assets verursachen subtilere Fehler. Stylesheets, Bilder, Schriftarten, Content Delivery Networks und Social-Login-Anbieter laden alle von ihren eigenen Hosts. Wenn einer davon blockiert ist, wird die Seite fehlerhaft dargestellt oder die Login-Schaltfläche bleibt ohne Funktion.

Der Walled Garden kann auch zu großzügig konfiguriert sein. Geräte führen einen Captive Network Assistant (CNA) aus, der eine vordefinierte Domain abfragt, um den Internetzugang zu testen. Wenn diese Test-Domain vor dem Login erreichbar ist, geht das Gerät davon aus, dass es online ist. Die Aufforderung zur Anmeldung wird dann nie angezeigt.

Die Grant-URL oder Continue-URL ist verloren gegangen

Mit einem externen Captive Portal hängt Meraki Parameter an die Weiterleitung an. Dazu gehören eine Basis-Freigabe-URL (Grant-URL) und die ursprüngliche Ziel-URL, die der Gast angefordert hat. Das Portal muss das Gerät an die Freigabe-URL zurücksenden, um den Zugriff freizuschalten.

Wenn das Portal diese Parameter verwirft, umschreibt oder im Cache speichert, erhält der Access Point die Freigabe nie. Der Gast sieht eine Erfolgsmeldung, wird aber beim Laden der nächsten Seite erneut zur Anmeldeseite weitergeleitet.

RADIUS ist nicht erreichbar oder das Shared Secret ist falsch

Die Anmeldung über RADIUS setzt voraus, dass die Access Points den RADIUS-Server erreichen können. RADIUS ist das Remote Authentication Dial-In User Service-Protokoll, definiert in RFC 2865. Der Server behandelt jeden Absender als RADIUS-Client und überprüft bei jeder Anfrage ein Shared Secret.

Zwei Fehler treten besonders häufig auf. Eine Firewall blockiert den RADIUS-Datenverkehr von den Access Points oder das Shared Secret unterscheidet sich zwischen Dashboard und Server. In beiden Fällen erfasst das Portal zwar die Daten, die Authentifizierung wird jedoch nie abgeschlossen.

NAT-Modus und Bridge-Modus ändern die Prüfpunkte

Im NAT-Modus weist der Access Point den Clients die IP-Adressen selbst zu. Vorgelagerte Geräte sehen den Datenverkehr vom Access Point und nicht vom Client. Im Bridge-Modus beziehen Clients ihre Adressen von Ihrem DHCP-Server in Ihrem LAN oder VLAN.

Der Bridge-Modus bringt zusätzliche potenzielle Fehlerquellen in Ihrem eigenen Netzwerk mit sich. Dazu gehören ein erschöpfter DHCP-Bereich, ein nicht zum Access Point getruntes VLAN sowie vorgelagerte DNS- oder Firewall-Regeln, die die Portal-Hosts blockieren.

Wie finden Sie heraus, um welche Ursache es sich handelt?

Arbeiten Sie sich vom Client nach außen vor. Testen Sie mit einem einzelnen Gerät und löschen Sie das Netzwerk zwischen den Versuchen aus den Einstellungen, damit jeder Test sauber startet.

Symptom	Was das Ereignisprotokoll anzeigt	Wahrscheinlichste Ursache	Erste Prüfung
Keine Splash-Page erscheint	Zuordnung (Association), aber keine Splash-Weiterleitung	CNA-Probe-Domain erreichbar oder DHCP- bzw. DNS-Fehler	Bestätigen Sie, dass das Gerät eine IP-Adresse und DNS hat, und öffnen Sie dann neverssl.com
Splash-Page leer oder unformatiert	Splash-Weiterleitung, Seite unvollständig	Walled Garden ohne Asset-Hosts	Entwicklertools des Browsers öffnen, blockierte Hosts auflisten
Schleife nach dem Absenden	Wiederholte Splash-Weiterleitungen, keine Freigabe	Parameter der Freigabe-URL verloren oder falscher Splash-Typ	Vergleichen Sie den Redirect-Query-String mit dem, was das Portal zurückgibt
Erfolgsmeldung, kein Internet	Fehlgeschlagene Authentifizierungsversuche oder Timeout	RADIUS blockiert oder Shared-Secret-Fehler	RADIUS-Serverprotokolle auf Anfragen von den Access Points prüfen
Wiederkehrende Gäste müssen sich neu anmelden	Neue Splash-Ereignisse für bekannte Geräte	Splash-Häufigkeit zu kurz eingestellt	Einstellung für die Splash-Häufigkeit auf der SSID
Desktop-Zertifikatswarnung	Weiterleitung wird abgeschlossen	Anmeldeseite wird über HTTP bereitgestellt	Zertifikat auf dem Portal-Host

Das Meraki-Ereignisprotokoll lesen

Öffnen Sie das Netzwerk-Ereignisprotokoll im Meraki-Dashboard und filtern Sie nach der MAC-Adresse des Testgeräts. Filtern Sie anschließend nach den Ereignistypen für Splash und Authentifizierung. Lesen Sie die Ereignisse in chronologischer Reihenfolge: Assoziierung, Adresszuweisung, Splash-Weiterleitung, Authentifizierung. Der Punkt, an dem die Sequenz stoppt, markiert den Fehler. Kein Splash-Ereignis bedeutet, dass die Weiterleitung nie ausgelöst wurde. Ein Splash-Ereignis ohne Authentifizierungsereignis deutet auf das Portal oder die Freigabe-URL hin. Ein fehlgeschlagenes Authentifizierungsereignis weist auf RADIUS hin.

Wie beheben Sie das Problem auf Meraki MR-Netzwerken und Client-Geräten?

Befolgen Sie die Schritte des Herstellers im Purple Captive Portal Support-Artikel. Die folgenden Lösungen erklären Ihnen, was Sie ändern müssen und warum.

Walled Garden korrigieren

Laden Sie die Splash-Seite auf einem Gerät außerhalb des Gastnetzwerks mit geöffneten Entwickler-Tools. Erfassen Sie jeden Host, den die Seite aufruft, einschließlich der Social-Login-Anbieter. Fügen Sie jeden einzelnen als Domain oder IP-Bereich zum Walled Garden hinzu. Entfernen Sie alles, was einer CNA-Probe-Domain entspricht.

Übergabe der Freigabe-URL korrigieren

Erfassen Sie die vollständige Weiterleitungs-URL von einem fehlerhaften Gerät. Stellen Sie sicher, dass das Portal das Gerät mit intakten Parametern an die Basis-Freigabe-URL zurückleitet. Prüfen Sie, dass kein Proxy, Link-Verkürzer oder Cache zwischen dem Portal und dem Gerät geschaltet ist.

RADIUS korrigieren

Stellen Sie sicher, dass die Access Points den RADIUS-Server über die konfigurierten Ports erreichen können. Geben Sie das Shared Secret auf beiden Seiten gleichzeitig aus derselben Kopie erneut ein. Überprüfen Sie anschließend das Server-Protokoll auf eingehende Anfragen von den Adressen der Access Points.

Client-Verhalten korrigieren

Android zeigt eine Benachrichtigung "Möglicherweise müssen Sie sich anmelden", die den CNA öffnet. Einige Gerätehersteller ändern dieses Verhalten, testen Sie daher mit den Modellen, die Ihre Gäste nutzen. Wenn ein Gast den Hinweis übersieht, empfiehlt Purple, einen Browser zu öffnen und neverssl.com aufzurufen. Diese Website vermeidet SSL-Weiterleitungsprobleme, da sie niemals HTTPS verwendet.

Desktop-Browser warnen, wenn eine Anmeldeseite über einfaches HTTP bereitgestellt wird. Der Cisco WLC Zertifikats-Artikel von Purple behandelt den entsprechenden Fehler auf Cisco WLCs. Die Lösung dort ist ein öffentlich vertrauenswürdiges Zertifikat, dessen Common Name mit dem Portal-Hostnamen übereinstimmt. Das gleiche Prinzip gilt für jeden Portal-Host.

Andere Hersteller

Purple ist hardwareunabhängig. Die gleichen Prüfungen gelten für Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks und Fortinet. Lediglich die Menünamen unterscheiden sich.

Zwei Fallbeispiele aus der Praxis

Ein 200-Zimmer-Hotel nach einem Portal-Redesign

Situation. Ein Hotel im Stadtzentrum aus dem Bereich Hospitality hat seine Splash-Seite mit neuen Schriftarten und einem Social-Login-Button aktualisiert. Danach sahen die Gäste nur noch eine leere Seite ohne Anmeldebutton.

Was getan wurde. Das IT-Team lud die neue Seite mit geöffneten Entwickler-Tools und fand zwei blockierte Hosts. Einer war ein Netzwerk zur Bereitstellung von Schriftarten, der andere der Social-Login-Anbieter. Beide wurden in den Walled Garden aufgenommen.

Ergebnis. Die Seite wurde beim nächsten Test vollständig geladen. Die Beschwerden an der Rezeption über den Gastzugang hörten noch am selben Tag auf.

Eine Einzelhandelskette mit 40 Filialen nach einer Firewall-Änderung

Situation. Eine Einzelhandelskette verschärfte ihre Firewall in der Hauptgeschäftsstelle. Am nächsten Morgen sahen Kunden in allen Filialen die Erfolgsseite, konnten jedoch nicht im Internet surfen.

Maßnahme. Das Ereignisprotokoll zeigte Authentifizierungs-Timeouts an jedem Standort. Die neue Regel hatte den RADIUS-Datenverkehr von den Access Points der Filialen blockiert. Das Team stellte die Regel ausschließlich für die RADIUS-Ports wieder her.

Ergebnis. Die Authentifizierungsereignisse normalisierten sich an allen 40 Standorten innerhalb einer Stunde nach der Änderung wieder.

Wie verhindern Sie, dass Fehler im Captive Portal von Meraki erneut auftreten?

• Walled Garden an Portal-Änderungen koppeln. Jede Designänderung löst vor dem Go-Live eine Überprüfung des Walled Garden aus.
• Die SSID offen halten. Purple empfiehlt ein offenes Netzwerk für den Gastzugang, da diese Konvention bekannt ist und Hürden abbaut.
• Shared Secrets paarweise rotieren. Ändern Sie das Dashboard und den RADIUS-Server in einem einzigen Wartungsfenster.
• Auf vier Plattformen testen. Android, iOS, Windows und macOS gehen jeweils unterschiedlich mit dem CNA um.
• Ein vertrauenswürdiges Zertifikat verwenden. Stellen Sie die Anmeldeseite über HTTPS mit einem öffentlich vertrauenswürdigen Zertifikat bereit.
• Mitarbeiter von Gästen trennen. Mitarbeiter sollten sich über ihre Identität authentifizieren und nicht über eine Gast-Anmeldeseite. Siehe How to Enable Single Sign On.

Purple betreibt Guest WiFi an über 80.000 Live-Standorten und hat im Jahr 2024 440 Millionen Logins verarbeitet (eigene Daten von Purple). Dieselbe Checkliste gilt auch für Transportknotenpunkte, die Passagiere bedienen, und für Standorte im Gesundheitswesen, die Patienten und Besucher versorgen.

Häufig gestellte Fragen

Funktioniert Purple mit meinen vorhandenen Cisco Meraki Access Points?

Ja, Purple läuft als Cloud-Overlay auf Ihren vorhandenen Cisco Meraki MR Access Points. Sie verweisen mit der Splash Page der SSID auf Purple und konfigurieren die RADIUS-Details von Purple im Meraki-Dashboard. Es ist keine neue Hardware erforderlich. Der Purple Support-Artikel zum Captive Portal beschreibt die Konfigurationsschritte. Derselbe Ansatz funktioniert auch für den Rest einer gemischten Infrastruktur.

Kann Purple Guest WiFi in einer Umgebung mit verschiedenen Hardware-Herstellern betreiben?

Ja, Purple ist hardwareunabhängig und unterstützt Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme und Fortinet. Sie verwalten eine einzige Splash Page und einen einzigen Anmeldefluss für alle Anbieter über eine einzige Plattform. Dies eignet sich hervorragend für Unternehmensgruppen, die Standorte mit unterschiedlicher Hardware übernommen haben. Es eignet sich auch für Infrastrukturen, bei denen die Access Points schrittweise und nicht in einem einzigen Projekt ausgetauscht werden sollen.

Sollte der Gastzugang über eine offene oder eine gesicherte SSID laufen?

Purple empfiehlt eine offene SSID für den Gastzugang, da dies mittlerweile der Standard ist und Gäste dies gewohnt sind. Das Captive Portal übernimmt den Anmeldeschritt, sodass Gäste vor dem Verbindungsaufbau kein Passwort benötigen. Ein offenes Netzwerk minimiert Hürden beim Verbindungsaufbau. Halten Sie die Geräte der Mitarbeiter in einem separaten, identitätsbasierten Netzwerk, anstatt die Guest-SSID gemeinsam zu nutzen.

Sind die über die Splash-Page erfassten Gästedaten GDPR-konform?

Ja, Purple ist nach ISO 27001 und Cyber Essentials zertifiziert und arbeitet im Einklang mit GDPR und CCPA. Gäste geben auf der Splash-Page eine bewusste Einwilligung (Opt-in), sodass das Marketing-Einverständnis ausdrücklich erfolgt. Die von Ihnen erhobenen Daten sind First-Party-Daten im Besitz Ihres Unternehmens. Purple ist zudem als B Corp zertifiziert. Stellen Sie sicher, dass Ihre eigene Datenschutzerklärung mit den Feldern übereinstimmt, die Ihre Splash-Page erfasst.

Warum zeigen Desktop-Browser vor der Login-Seite eine Zertifikatswarnung an?

Desktop-Browser zeigen eine Warnung an, wenn das Portal über einfaches HTTP auf eine Login-Seite weiterleitet. Moderne Browser erwarten, dass Login-Seiten HTTPS verwenden, und markieren die Verbindung daher als nicht privat. Die Lösung ist ein öffentlich vertrauenswürdiges SSL/TLS-Zertifikat auf dem Portal-Host. Der Common Name des Zertifikats muss mit dem vom Redirect verwendeten Hostnamen übereinstimmen. Die Warnung blockiert den Zugriff nicht, mindert aber das Vertrauen der Gäste.

Wer übernimmt die RADIUS-Authentifizierung, wenn Purple das Portal betreibt?

Der RADIUS-Server von Purple schließt die Anmeldung ab. Die Splash-Page gibt einen einmaligen Login aus, und der Meraki Access Point leitet diesen an den RADIUS-Server von Purple weiter. Sie tragen die RADIUS-Details und das Shared Secret von Purple im Meraki Dashboard ein. Ihre Firewall muss RADIUS-Traffic von den Access Points zu Purple zulassen. Wenn sich das Shared Secret auf einer der beiden Seiten unterscheidet, schlägt die Authentifizierung fehl.

Wie hoch ist der Aufwand für den Wechsel von der Meraki Splash-Page zu Purple?

Der Wechsel ist eine Konfigurationsänderung auf jeder SSID, kein Hardware-Projekt. Sie ändern den Typ der Splash-Page, fügen die Walled-Garden-Einträge hinzu und geben die RADIUS-Details von Purple ein. Der größte Aufwand fließt in das Testen auf Android, iOS, Windows und macOS vor dem Go-Live. Planen Sie zuerst einen Pilot-Standort und rollen Sie die getesteten Einstellungen dann auf die restlichen Standorte aus.