Captive Portal for Cisco Meraki

Willkommen zur Purple Technical Briefing Series. Ich bin Ihr Moderator, und heute behandeln wir ein Thema, das bei fast jeder Enterprise-Gast-WiFi-Bereitstellung aufkommt, an der wir arbeiten: die Konfiguration eines Captive Portals auf Cisco Meraki MR Access Points, und insbesondere, wie man dieses über RADIUS-Authentifizierung in die Cloud-Plattform von Purple integriert. Egal, ob Sie ein MSP sind, der einen neuen Kunden aus dem Gastgewerbe anbindet, oder ein interner Netzwerkarchitekt bei einer Einzelhandelskette – diese Episode liefert Ihnen die präzisen Konfigurationsschritte und die Logik hinter jedem einzelnen Schritt. Stellen wir uns das Szenario vor. Sie haben einen Standort – das kann ein Hotel, ein Konferenzzentrum, ein Stadion oder ein Fachmarktzentrum sein –, an dem Cisco Meraki MR Access Points betrieben werden, die über das Meraki Dashboard verwaltet werden. Der Auftrag lautet, ein gebrandetes Gast-WiFi-Erlebnis bereitzustellen, das First-Party-Daten erfasst, die Zustimmung zu den Nutzungsbedingungen erzwingt und Analysen an eine Marketingplattform zurückmeldet. Genau dafür ist Purple entwickelt worden, und Meraki ist weltweit eine unserer häufigsten Hardware-Bereitstellungen. Der wichtigste architektonische Punkt, den Sie verstehen müssen, bevor Sie auch nur eine einzige Einstellung ändern, ist folgender: Bei Cisco Meraki wird die RADIUS-Authentifizierung für eine Splash-Page nicht lokal vom Access Point verarbeitet. Der RADIUS-Access-Request wird von der Meraki-Cloud – also von der Dashboard-Infrastruktur – initiiert, nicht vom AP in Ihrem LAN. Dies ist ein entscheidender Unterschied, der viele Techniker bei ihrer ersten Meraki-Bereitstellung überrascht. Das bedeutet, dass Ihr RADIUS-Server, in diesem Fall der Cloud-RADIUS-Endpunkt von Purple, aus dem Internet erreichbar sein muss und Ihre Firewall-Regeln den Datenverkehr aus den IP-Bereichen des Meraki-Dashboards zulassen müssen, nicht nur aus Ihrem lokalen AP-Subnetz. Die aktuellen Dashboard-IP-Bereiche finden Sie in Ihrem Meraki Dashboard unter „Help“ und dann „Firewall Info“. Gut, gehen wir in die Konfiguration. Ich führe Sie in der Reihenfolge durch, in der Sie dies auch bei einer Live-Bereitstellung tun würden. Schritt eins: SSID-Konfiguration. Navigieren Sie im Meraki Dashboard zu „Wireless“, dann „Configure“ und schließlich „SSIDs“. Wählen Sie den SSID-Slot aus, den Sie für den Gastzugang nutzen möchten. Geben Sie ihm einen eindeutigen Namen – etwa „GuestWiFi“ oder „Standortname_Guest“. Stellen Sie unter „Association requirements“ die Option „Security“ auf „Open, no encryption“. Das ist so korrekt und beabsichtigt – die Sicherheitsebene für Gäste wird durch das Captive Portal und die RADIUS-Authentifizierung geregelt, nicht durch eine WPA-Verschlüsselung. Wenn Sie in einer PCI-DSS-Umgebung bereitstellen, sollten Sie sicherstellen, dass der Gast-Datenverkehr in einem eigenen VLAN isoliert ist, worauf wir gleich noch eingehen werden. Schritt zwei: Splash-Page und Authentifizierung. Scrollen Sie auf der Seite „Access Control“ für Ihre SSID nach unten zum Bereich „Splash page“. Stellen Sie diesen auf „Sign-on with“ ein und wählen Sie aus dem Dropdown-Menü „my RADIUS server“ aus. Dies ist die entscheidende Einstellung, die Meraki anweist, Benutzer vor dem Gewähren des Netzwerkzugriffs an einem externen RADIUS-Server zu authentifizieren. Darunter sehen Sie die Option „Captive portal strength“. Stellen Sie diese auf „Block all access until sign-on is complete“ ein. Dies erzwingt den Walled Garden – ohne diese Einstellung könnten Gäste das Captive Portal komplett umgehen. Schritt drei: RADIUS-Server-Konfiguration. Klicken Sie im Bereich „RADIUS“ auf „Add server“. Sie benötigen drei Informationen aus Ihrem Purple-Konto: die IP-Adresse oder den FQDN des RADIUS-Servers, den Authentifizierungsport (UDP 1812) und das Shared Secret. Purple stellt diese im Bereich für die Standortkonfiguration des Portals bereit. Für Redundanz in Produktivumgebungen sollten Sie einen sekundären RADIUS-Server hinzufügen – Purple bietet hierfür einen Failover-Endpunkt. Stellen Sie den Accounting-Port auf UDP 1813 ein, wenn Sie möchten, dass Sitzungsdaten in die Analytics-Engine von Purple zurückfließen. Dies wird für jeden Standort, an dem Verweildauer und Sitzungsdauer wichtige Kennzahlen sind, dringend empfohlen. Ein kurzer Hinweis zu RADIUS-Attributen. Meraki berücksichtigt das in der RADIUS-Antwort „Access-Accept“ zurückgegebene Attribut „Session-Timeout“. Purple nutzt dieses, um zu steuern, wie lange eine Gastsitzung dauert, bevor eine erneute Authentifizierung erforderlich ist. Für ein Hotel können Sie dies auf 86.400 Sekunden festlegen – das entspricht 24 Stunden. Für ein Café ist ein Wert von 3.600 Sekunden (eine Stunde) angemessener. Das Attribut „Idle-Timeout“ wird ebenfalls berücksichtigt, jedoch nur, wenn das RADIUS-Accounting aktiviert ist. Dies trennt inaktive Sitzungen, was für das Kapazitätsmanagement an Standorten mit hoher Dichte wichtig ist. Schritt vier: Splash-Page-URL. Navigieren Sie zu „Wireless“, dann „Configure“ und schließlich „Splash page“. Wählen Sie Ihre Gäste-SSID aus dem Dropdown-Menü aus. Stellen Sie die „Custom splash URL“ auf die Purple-Portal-URL für Ihren Standort ein. Dies ist die URL, an die Meraki nicht authentifizierte Clients weiterleitet. Meraki hängt Abfrageparameter an diese URL an – einschließlich des Parameters „login_url“ –, die Purple verwendet, um den Authentifizierungs-Handshake abzuschließen. Diese Parameter dürfen nicht geändert oder entfernt werden. Schritt fünf: Der Walled Garden. Hier treten bei den meisten Implementierungen Probleme auf. Der Walled Garden ist die Liste von Domains und IP-Bereichen, die ein Gästegerät erreichen kann, bevor es authentifiziert ist. Ohne die korrekten Einträge wird die Captive Portal-Seite selbst nicht geladen, da der Browser daran gehindert wird, das Purple-CDN und die Social-Login-Anbieter zu erreichen. Navigieren Sie zurück zu Access Control für Ihre Gäste-SSID. Stellen Sie Walled Garden auf Walled Garden ist aktiviert. In das Feld für die Walled Garden-Bereiche müssen Sie Folgendes eintragen. Erstens, die Domänen der Purple-Plattform: star dot purple dot ai und star dot venuewifi dot com. Zweitens, die CDN-Domänen, die Purple zur Bereitstellung von Portal-Assets verwendet: star dot cloudfront dot net und star dot akamaihd dot net. Drittens, die Meraki-Redirect-Infrastruktur: star dot network-auth dot com. Viertens, wenn Sie Social-Login-Optionen anbieten, benötigen Sie die entsprechenden OAuth-Domänen. Für Google: accounts dot google dot com, star dot googleapis dot com, star dot gstatic dot com. Für Facebook: star dot facebook dot com, star dot fbcdn dot net und connect dot facebook dot net. Für Twitter oder X: star dot twitter dot com und star dot twimg dot com. Ein wichtiger Hinweis dazu, wie Meraki mit Wildcard-Domänen im Walled Garden umgeht. Meraki unterstützt Wildcard-Einträge mit dem Sternchen-Präfix, zum Beispiel star dot cloudfront dot net. Dies ist jedoch ein DNS-basierter Abgleich — Meraki löst die Domäne auf und lässt die resultierenden IP-Adressen zu. Das bedeutet, dass Sie für CDN-Anbieter wie CloudFront oder Akamai, bei denen sich die aufgelösten IPs häufig ändern können, die Domänen-Wildcard anstelle von statischen IP-Bereichen verwenden sollten. Statische IP-Einträge sind für die RADIUS-Endpunkte von Purple, die stabil sind, völlig in Ordnung, nicht jedoch für den CDN-Traffic. Lassen Sie uns nun über zwei Praxisbeispiele sprechen, an denen ich direkt gearbeitet habe. Das erste ist ein Hotel mit 350 Zimmern in Großbritannien. Der Kunde betrieb Meraki MR46 Access Points in drei Gebäuden mit etwa 400 gleichzeitigen Gäste-Geräten in Spitzenzeiten. Die ursprüngliche Bereitstellung nutzte eine Click-Through-Splash-Page — kein RADIUS, nur die Akzeptanz der Nutzungsbedingungen. Das Problem war, dass sie keinerlei Einblick hatten, wer sich verbindet, keine E-Mail-Erfassung stattfand und es keine Möglichkeit gab, Marketingkampagnen nach dem Aufenthalt durchzuführen. Wir haben sie auf Purple mit RADIUS-basierter Anmeldung migriert. Die Konfiguration war unkompliziert, aber der Haken war, dass ihre vorgeschaltete Firewall ausgehenden UDP-Traffic auf Port 1812 zu Zielen außerhalb des lokalen Subnetzes blockierte. Sobald wir die IP-Bereiche des Meraki Dashboards zur Allow-List der Firewall hinzugefügt hatten, funktionierte die Authentifizierung sofort. Nach der Bereitstellung erfasste das Hotel im ersten Monat E-Mail-Adressen von etwa 68 Prozent der sich verbindenden Gäste, und das Marketingteam startete eine Reaktivierungskampagne, die zu einer messbaren Steigerung der Direktbuchungen führte. Das zweite Szenario ist eine Einzelhandelskette mit 45 Filialen, in denen jeweils Meraki MR33 Access Points im Einsatz sind. Die Herausforderung lag hier in der Skalierung und Konsistenz. Die manuelle Konfiguration von 45 SSIDs mit den korrekten RADIUS-Einstellungen und Walled-Garden-Listen wäre fehleranfällig und zeitraubend gewesen. Die Lösung bestand darin, die vorlagenbasierte Konfiguration von Meraki zu nutzen. Wir haben eine einzige Netzwerkvorlage mit den korrekten SSID-, RADIUS- und Walled-Garden-Einstellungen erstellt und dann alle 45 Filialnetzwerke an diese Vorlage gebunden. Jede Änderung – wie beispielsweise das Hinzufügen eines neuen Social-Login-Anbieters zum Walled Garden – wird einmal in der Vorlage vorgenommen und automatisch auf alle Filialen übertragen. Die Analytics von Purple aggregierten anschließend die Besucherzahlen und Verweildaten über alle Filialen hinweg und boten dem Retail-Operations-Team ein einziges Dashboard zur Analyse des Gastverhaltens nach Filiale, Region und Tageszeit. Hier sind drei Faustregeln, die Ihnen bei jeder Bereitstellung eines Meraki Captive Portals Zeit sparen werden. Regel eins: Überprüfen Sie immer die IP-Bereiche des Meraki Dashboards, bevor Sie RADIUS konfigurieren. Die Bereiche ändern sich gelegentlich. Wenn Ihre Firewall diese blockiert, schlägt die Authentifizierung aus Sicht des Nutzers geräuschlos fehl – die Portal-Seite bleibt einfach hängen. Nutzen Sie das integrierte RADIUS-Testtool im Dashboard unter „Access Control“, um die Konnektivität vor dem Live-Gang zu überprüfen. Regel zwei: Verwenden Sie im Walled Garden Domain-Wildcards anstelle von IP-Bereichen für alle über CDNs gehosteten Inhalte. CDN-IP-Bereiche sind groß und ändern sich häufig. Ein Wildcard-Domain-Eintrag ist wartungsfreundlicher und zuverlässiger. Regel drei: Aktivieren Sie das RADIUS-Accounting auf Port 1813, selbst wenn Sie glauben, dass Sie es noch nicht benötigen. Sitzungsdaten sind wertvoll für die Behebung von Verbindungsproblemen und für die Bereitstellung präziser Verweildaten in Ihrer Analytics-Plattform. Die Aktivierung kostet nichts und ist im Nachhinein nur sehr schwer nachzurüsten. Nun zu einigen kurzen Fragen, die mir regelmäßig gestellt werden. Kann ich die integrierte Splash-Page von Meraki anstelle von Purple verwenden? Ja, aber Sie verlieren die Datenerfassung, die Analytics, die Marketing-Automatisierung und das GDPR-konforme Einwilligungsmanagement. Die integrierte Splash-Page ist für ein einfaches Click-Through in Ordnung, aber sie ist keine Plattform für Guest Intelligence. Funktioniert diese Konfiguration sowohl auf Meraki MX Firewalls als auch auf MR Access Points? Die RADIUS-Splash-Page-Konfiguration wird auf MR Access Points unterstützt. MX-Appliances handhaben die Client-VPN-Authentifizierung anders. Speziell für das Gäste-WiFi konfigurieren Sie die MR SSIDs. Wie sieht es mit WPA3 aus? Meraki MR Access Points unterstützen WPA3 auf Enterprise-SSIDs. Bei Bereitstellungen von Captive Portals für Gäste ist die SSID in der Regel „Open“, sodass WPA3 nicht direkt anwendbar ist. Wenn Sie jedoch eine Passpoint- oder OpenRoaming-SSID parallel zu Ihrer Captive Portal-SSID bereitstellen – was von Purple unterstützt wird –, verwendet diese SSID WPA3-Enterprise mit 802.1X, und genau dort wird WPA3 relevant. Zusammenfassend lässt sich sagen: Die Integration von Cisco Meraki und Purple ist bewährt und zuverlässig, erfordert jedoch Aufmerksamkeit in drei Bereichen: RADIUS-Quell-IP-Routing, Vollständigkeit des Walled Gardens und Konfiguration des Session-Timeouts. Wenn Sie diese drei Punkte richtig umsetzen, ist die Bereitstellung unkompliziert. Der Business Case ist eindeutig – Standorte, die eine ordnungsgemäß konfigurierte Gäste-WiFi-Plattform mit Datenerfassung implementieren, verzeichnen durchgehend messbare Erfolge beim Marketing-Engagement und bei den operativen Erkenntnissen. Wenn Sie tiefer in das Thema einsteigen möchten, lesen Sie den Leitfaden von Purple zur Implementierung der 802.1X-Authentifizierung mit Cloud-RADIUS sowie unseren Cisco Wireless AP-Bereitstellungsleitfaden im Purple-Blog. Beide sind in den Show Notes verlinkt. Vielen Dank fürs Zuhören. Wenn Sie ein bestimmtes Bereitstellungsszenario haben, das wir behandeln sollen, wenden Sie sich an das technische Team von Purple. Wir sehen uns in der nächsten Folge.