Captive Portal for Cisco Meraki

Ein maßgebliches technisches Referenzhandbuch auf mittlerem Niveau für die Integration von Cisco Meraki MR Access Points mit dem Cloud-basierten Captive Portal von Purple. Es behandelt Schritt-für-Schritt-Konfigurationen des Meraki Dashboards, RADIUS-Server-Einstellungen (Ports 1812/1813), Walled-Garden-Wildcard-Domain-Ausnahmen und Session-Timeout-Parameter für leistungsstarke Guest-WiFi-Bereitstellungen.

📖 8 Min. Lesezeit📝 1,892 Wörter🔧 2 ausgearbeitete Beispiele❓ 3 Übungsfragen📚 8 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

Welcome to the Purple Technical Briefing Series. I'm your host, and today we're covering something that comes up on almost every enterprise guest WiFi deployment we work on: configuring a captive portal on Cisco Meraki MR access points, and specifically how to integrate that with Purple's cloud platform using RADIUS authentication. Whether you're an MSP onboarding a new hospitality client or an in-house network architect at a retail chain, this episode will give you the precise configuration steps and the reasoning behind each one.

Let's set the scene. You've got a venue — could be a hotel, a conference centre, a stadium, or a retail park — running Cisco Meraki MR access points managed through the Meraki Dashboard. The brief is to deploy a branded guest WiFi experience that captures first-party data, enforces terms of service acceptance, and feeds analytics back into a marketing platform. That's exactly what Purple is built to do, and Meraki is one of our most common hardware deployments globally.

Now, the key architectural point to understand before you touch a single setting is this: on Cisco Meraki, RADIUS authentication for a splash page is not processed locally by the access point. The RADIUS Access-Request is sourced from the Meraki cloud — from the Dashboard infrastructure — not from the AP on your LAN. This is a critical distinction that catches out a lot of engineers on their first Meraki deployment. It means your RADIUS server, in this case Purple's cloud RADIUS endpoint, needs to be reachable from the internet, and your firewall rules need to permit traffic from Meraki's Dashboard IP ranges, not just from your local AP subnet. You'll find the current Dashboard IP ranges under Help, then Firewall Info in your Meraki Dashboard.

Right, let's get into the configuration. I'll walk you through this in the order you'd actually do it in a live deployment.

Step one: SSID configuration. In the Meraki Dashboard, navigate to Wireless, then Configure, then SSIDs. Select the SSID slot you want to use for guest access. Give it a clear name — something like GuestWiFi or VenueName underscore Guest. Under the Association requirements, set Security to Open, no encryption. This is correct and intentional — the security layer for guests is handled by the captive portal and the RADIUS authentication, not by WPA encryption. If you're deploying in a PCI DSS environment, you'll want to ensure guest traffic is isolated on its own VLAN, which we'll cover shortly.

Step two: Splash page and authentication. Still on the Access Control page for your SSID, scroll down to the Splash page section. Set it to Sign-on with, and from the dropdown, select my RADIUS server. This is the critical setting that tells Meraki to authenticate users against an external RADIUS server before granting network access. Below that, you'll see the Captive portal strength option. Set this to Block all access until sign-on is complete. This is what enforces the walled garden — without it, guests could bypass the portal entirely.

Step three: RADIUS server configuration. Under the RADIUS section, click Add server. You'll need three pieces of information from your Purple account: the RADIUS server IP address or FQDN, the authentication port which is UDP 1812, and the shared secret. Purple provides these in the venue configuration section of the portal. For redundancy in production deployments, you should add a secondary RADIUS server — Purple provides a failover endpoint. Set the accounting port to UDP 1813 if you want session data fed back into Purple's analytics engine, which I'd strongly recommend for any venue where dwell time and session duration are meaningful metrics.

A quick note on RADIUS attributes. Meraki honours the Session-Timeout attribute returned in the RADIUS Access-Accept response. Purple uses this to control how long a guest session lasts before re-authentication is required. For a hotel, you might set this to 86,400 seconds — that's 24 hours. For a coffee shop, something like 3,600 seconds, one hour, is more appropriate. The Idle-Timeout attribute is also honoured, but only if RADIUS accounting is enabled. This disconnects idle sessions, which is important for capacity management in high-density venues.

Step four: Splash page URL. Navigate to Wireless, then Configure, then Splash page. Select your guest SSID from the dropdown. Set the Custom splash URL to the Purple portal URL for your venue. This is the URL that Meraki will redirect unauthenticated clients to. Meraki appends query parameters to this URL — including a login_url parameter — which Purple uses to complete the authentication handshake. Do not modify or strip these parameters.

Step five: the walled garden. This is where most deployments run into trouble. The walled garden is the list of domains and IP ranges that a guest device can reach before they've authenticated. Without the correct entries, the captive portal page itself won't load, because the browser will be blocked from reaching the Purple CDN and the social login providers.

Navigate back to Access Control for your guest SSID. Set Walled garden to Walled garden is enabled. In the Walled garden ranges field, you need to add the following. First, the Purple platform domains: star dot purple dot ai, and star dot venuewifi dot com. Second, the CDN domains that Purple uses to serve portal assets: star dot cloudfront dot net, and star dot akamaihd dot net. Third, the Meraki redirect infrastructure: star dot network-auth dot com. Fourth, if you're offering social login options, you need the relevant OAuth domains. For Google: accounts dot google dot com, star dot googleapis dot com, star dot gstatic dot com. For Facebook: star dot facebook dot com, star dot fbcdn dot net, and connect dot facebook dot net. For Twitter or X: star dot twitter dot com and star dot twimg dot com.

One important note on how Meraki handles wildcard domains in the walled garden. Meraki does support wildcard entries using the asterisk prefix, for example star dot cloudfront dot net. However, this is a DNS-based match — Meraki resolves the domain and allows the resulting IP addresses. This means that for CDN providers like CloudFront or Akamai, where the resolved IPs can change frequently, you should use the domain wildcard rather than static IP ranges. Static IP entries are fine for Purple's RADIUS endpoints, which are stable, but not for CDN traffic.

Now let's talk about two real-world scenarios I've worked on directly.

The first is a 350-room hotel in the UK. The client was running Meraki MR46 access points across three buildings, with about 400 concurrent guest devices at peak. The initial deployment used a click-through splash page — no RADIUS, just terms acceptance. The problem was they had zero insight into who was connecting, no email capture, and no way to run post-stay marketing campaigns. We migrated them to Purple with RADIUS-based sign-on. The configuration was straightforward, but the gotcha was that their upstream firewall was blocking outbound UDP on port 1812 to anything outside the local subnet. Once we added the Meraki Dashboard IP ranges to the firewall allow-list, authentication worked immediately. Post-deployment, the hotel captured email addresses from approximately 68 percent of connecting guests in the first month, and their marketing team ran a re-engagement campaign that drove a measurable uplift in direct bookings.

The second scenario is a retail chain with 45 stores, each running Meraki MR33 access points. The challenge here was scale and consistency. Manually configuring 45 SSIDs with the correct RADIUS settings and walled garden lists would be error-prone and time-consuming. The solution was to use Meraki's template-based configuration. We built a single network template with the correct SSID, RADIUS, and walled garden settings, then bound all 45 store networks to that template. Any change — say, adding a new social login provider to the walled garden — is made once in the template and propagates to all stores automatically. Purple's analytics then aggregated footfall and dwell time data across all stores, giving the retail operations team a single dashboard view of guest behaviour by store, by region, and by time of day.

Let me give you three rules of thumb that will save you time on every Meraki captive portal deployment.

Rule one: Always check the Meraki Dashboard IP ranges before you configure RADIUS. The ranges change occasionally, and if your firewall is blocking them, authentication will fail silently from the user's perspective — they'll just see the portal page hang. Use the built-in RADIUS test tool in the Dashboard under Access Control to verify connectivity before you go live.

Rule two: Use domain wildcards in the walled garden, not IP ranges, for any CDN-hosted content. CDN IP ranges are large and change frequently. A wildcard domain entry is more maintainable and more reliable.

Rule three: Enable RADIUS accounting on port 1813 even if you think you don't need it yet. Session data is valuable for troubleshooting disconnection issues and for feeding accurate dwell time metrics into your analytics platform. It costs nothing to enable and is very hard to retrofit after the fact.

Now, a few rapid-fire questions I get asked regularly.

Can I use Meraki's built-in splash page instead of Purple? Yes, but you lose the data capture, the analytics, the marketing automation, and the GDPR-compliant consent management. The built-in splash is fine for a basic click-through, but it's not a guest intelligence platform.

Does this configuration work on Meraki MX firewalls as well as MR access points? The RADIUS splash page configuration is supported on MR access points. MX appliances handle client VPN authentication differently. For guest WiFi specifically, you're configuring the MR SSIDs.

What about WPA3? Meraki MR access points support WPA3 on enterprise SSIDs. For guest captive portal deployments, the SSID is typically Open, so WPA3 doesn't apply directly. However, if you're deploying a Passpoint or OpenRoaming SSID alongside your captive portal SSID — which Purple supports — that SSID uses WPA3-Enterprise with 802.1X, and that's where WPA3 becomes relevant.

To wrap up: the Cisco Meraki and Purple integration is well-tested and reliable, but it requires attention to three things: RADIUS source IP routing, walled garden completeness, and session timeout configuration. Get those three right and the deployment is straightforward. The business case is clear — venues that deploy a properly configured guest WiFi platform with data capture consistently see measurable returns in marketing engagement and operational insight.

If you want to go deeper, check out Purple's guide on implementing 802.1X authentication with cloud RADIUS, and our Cisco Wireless AP deployment guide on the Purple blog. Both are linked in the show notes.

Thanks for listening. If you've got a specific deployment scenario you'd like us to cover, get in touch with the Purple technical team. We'll see you in the next episode.

📚 Part of our core series: Multi-Tenant-WiFi →

Executive Summary

Dieses maßgebliche Referenzhandbuch bietet einen umfassenden, schrittweisen Konfigurationsrahmen für die Integration von drahtlosen Cisco Meraki-Netzwerken mit dem Cloud-basierten Captive Portal von Purple. Dieses Dokument wurde für IT-Manager, Netzwerkarchitekten und Managed Service Provider (MSPs) entwickelt und beschreibt die genauen Konfigurationen, die im Meraki Dashboard erforderlich sind, um eine sichere, leistungsstarke Guest-WiFi-Lösung bereitzustellen [1].

Durch die Entkopplung der Guest-Intelligence-Ebene von der Hardware können Unternehmen an ihren Standorten die zertifizierten Plattformen Guest WiFi und WiFi Analytics von Purple nutzen, um wertvolle, GDPR-konforme First-Party-Daten zu erfassen und gleichzeitig die Netzwerkintegrität und die Einhaltung gesetzlicher Vorschriften zu gewährleisten [2]. Dieses Handbuch behandelt kritische Integrationsparameter, einschließlich RADIUS-Authentifizierung (Ports 1812/1813), Walled-Garden-Domain-Ausnahmen, CDN-Wildcard-Auflösung und Mechanismen zur Weiterleitung von Gästen in verschiedenen physischen Umgebungen wie Einzelhandel , Gesundheitswesen , Gastgewerbe und Transportwesen .

Technischer Deep-Dive

Um Cisco Meraki MR Access Points (APs) erfolgreich in ein externes Captive Portal wie Purple zu integrieren, müssen Netzwerkingenieure die zugrunde liegende Control- und Data-Plane-Architektur verstehen. Im Gegensatz zu herkömmlichen On-Premise-Wireless-Controllern, bei denen RADIUS-Authentifizierungsanfragen vom physischen Controller oder von einzelnen APs stammen, nutzt Cisco Meraki eine Cloud-verwaltete Architektur [1].

Trennung von Control Plane und Data Plane

Wenn sich ein Gast-Client mit einer offenen SSID verbindet, die für ein externes Captive Portal konfiguriert ist, versetzt der Meraki MR AP den Client in einen Pre-Authentication-Status. In diesem Zustand wird der gesamte Datenverkehr blockiert, mit Ausnahme von DNS-Abfragen, DHCP und Datenverkehr, der an IP-Adressen oder Hostnamen gerichtet ist, die explizit im Walled Garden definiert sind [3].

Die eigentlichen RADIUS-Access-Request-Nachrichten werden nicht vom lokalen Meraki MR AP generiert. Stattdessen stammen sie aus der Cisco Meraki Dashboard Cloud-Infrastruktur [1]. Dies ist eine entscheidende architektonische Unterscheidung:

> "RADIUS-Access-Request-Nachrichten für eine Splash-Page stammen aus dem Dashboard, nicht von den lokalen Meraki-Geräten. Daher kann die private LAN-IP-Adresse des RADIUS-Servers hier nicht angegeben werden." [1]

Folglich müssen die vorgeschalteten Firewalls, die Ihre RADIUS-Server schützen, eingehenden Datenverkehr aus dem gesamten Block der ausgehenden IP-Bereiche des Meraki Dashboards zulassen, die dynamisch und regionsspezifisch sind [1]. Diese Bereiche können dynamisch über das Meraki Dashboard unter Hilfe > Firewall-Info abgerufen werden [1].

RADIUS-Authentifizierungsprotokoll (PAP)

Für die Authentifizierung auf der Sign-On-Splash-Page verwendet Meraki das Password Authentication Protocol (PAP) [1]. Obwohl PAP historisch unverschlüsselt ist, mindert die Meraki-Purple-Integration Sicherheitsrisiken durch eine mehrschichtige Verschlüsselung:

Client-to-Cloud-Verschlüsselung: Der Gast-Client stellt eine sichere HTTPS-Verbindung (SSL/TLS) direkt mit dem gehosteten Captive Portal von Purple her. Die Anmeldedaten (z. B. Social-Login-Token, E-Mail-Formulare) werden bei der Übertragung vom Browser des Clients zu den Servern von Purple verschlüsselt [1].
RADIUS Shared Secret-Verschlüsselung: Wenn die Meraki Cloud den RADIUS-Access-Request an den Cloud-RADIUS-Server von Purple sendet, verschlüsselt sie das Passwort des Benutzers unter Verwendung des konfigurierten RADIUS Shared Secret und einer Standard-XOR-Funktion gemäß RFC 2865 [1]. Dadurch wird sichergestellt, dass Anmeldedaten im Klartext niemals über das öffentliche Internet übertragen werden.

Unterstützte RADIUS-Attribute

Die Meraki Cloud und der Purple Cloud RADIUS tauschen während des Authentifizierungs-Handshakes mehrere Schlüsselattribute aus, um Sitzungsparameter und Richtlinien durchzusetzen:

RADIUS-Attribut	Typ	Richtung	Beschreibung & praktischer Kontext
User-Name	String	Request	Die Kennung des Gastbenutzers (z. B. E-Mail-Adresse, MAC-Adresse) [1].
User-Password	String	Request	Das verschlüsselte Benutzerpasswort oder Sitzungstoken [1].
Called-Station-ID	String	Request	Formatiert als `AP_MAC:SSID_NAME` (z. B. `AA-BB-CC-DD-EE-FF:GuestWiFi`). Entscheidend für standortbasiertes Richtlinien-Routing [1].
Calling-Station-ID	String	Request	Die physische MAC-Adresse des Clients (z. B. `11-22-33-44-55-66`). Wird für die Geräteverfolgung und Sitzungswiederaufnahme verwendet [1].
Session-Timeout	Integer	Accept	Die maximale Sitzungsdauer in Sekunden. Nach Ablauf wird der Client zurück zum Captive Portal weitergeleitet [1].
Idle-Timeout	Integer	Accept	Die maximale Inaktivitätszeit in Sekunden. Wenn keine Daten übertragen werden, wird die Sitzung beendet. Erfordert RADIUS-Accounting [1].
Filter-Id	String	Accept	Überträgt den Namen einer bestimmten Meraki-Gruppenrichtlinie, die auf den Client angewendet werden soll (z. B. zur Begrenzung der Bandbreite oder zum Blockieren bestimmter Kategorien) [1].

Implementierungsleitfaden

Diese schrittweise Konfigurationsanleitung beschreibt, wie Sie Cisco Meraki MR Access Points in das externe Captive Portal von Purple integrieren.

Schritt 1: SSID-Zugriffskontrolle konfigurieren

Navigieren Sie im Meraki Dashboard zu Wireless > Configure > Access control [1]. Wählen Sie Ihre Ziel-Gast-SSID aus und konfigurieren Sie die folgenden Parameter:

Association Requirements: Auf Open (no encryption) festlegen [1]. Dies sorgt für einen reibungslosen Onboarding-Prozess. Wenn Sie eine verschlüsselte Gastübertragung benötigen, erwägen Sie die Implementierung von Passpoint / Hotspot 2.0 mit Cloud RADIUS [4].
Splash Page: Wählen Sie Sign-on with und wählen Sie my RADIUS server aus dem Dropdown-Menü [1].
RADIUS-Server: Klicken Sie auf Add server und geben Sie die primären und sekundären Endpunkte von Purple Cloud RADIUS ein [1]:
- Host-IP: 116.203.120.121 (Primär) und 195.201.123.149 (Sekundär)
- Port: 1812 (Authentifizierung) [1]
- Secret: [Ihr Purple Shared Secret]
RADIUS-Accounting: Stellen Sie dies auf RADIUS accounting is enabled ein und fügen Sie die Accounting-Server hinzu:
- Host-IP: 116.203.120.121 (Primär) und 195.201.123.149 (Sekundär)
- Port: 1813 (Accounting)
- Secret: [Ihr Purple Shared Secret]
Captive Portal-Stärke: Wählen Sie Block all access until sign-on is complete [1]. Dies stellt strikt sicher, dass Clients nicht auf das Internet zugreifen können, ohne die Splash Page zu durchlaufen.

Schritt 2: Konfigurieren der benutzerdefinierten Splash Page-URL

Navigieren Sie zu Wireless > Configure > Splash page [1]. Wählen Sie Ihre Gäste-SSID aus und konfigurieren Sie Folgendes:

Custom Splash URL: Wählen Sie Or point to a custom URL und geben Sie die Purple-Weiterleitungs-URL ein:
- https://login.venuewifi.com/ip/v2/meraki
Splash Page Redirect: Stellen Sie dies auf The URL they were trying to fetch ein oder leiten Sie sie auf eine bestimmte Landingpage weiter (z. B. die Homepage Ihres Standorts) [3].

Schritt 3: Walled Garden-Domainnamen-Ausnahmen konfigurieren

Um sicherzustellen, dass Gäste-Clients das Captive Portal laden, Assets von Content Delivery Networks (CDNs) herunterladen und die Social-Media-Authentifizierung (z. B. Google- oder Facebook-OAuth) abschließen können, müssen Sie den Walled Garden aktivieren und konfigurieren [3].

Navigieren Sie zurück zu Wireless > Configure > Access control und suchen Sie den Bereich Walled Garden [1].

Stellen Sie Walled Garden auf Walled garden is enabled ein [1].
In dem Feld Walled garden ranges geben Sie die erforderlichen FQDNs und Wildcard-Domains ein [1].

Wie Meraki Wildcards und CDN-Traffic verarbeitet

Cisco Meraki MR Access Points unterstützen Wildcard-Domains im Walled Garden mithilfe des Asterisk-Präfixes (z. B. *.purple.ai) [1]. Es ist jedoch wichtig, die zugrunde liegende Funktionsweise zu verstehen:

DNS-basiertes Whitelisting: Der Meraki AP fängt die DNS-Anfragen des Clients ab. Wenn der Client eine Domain anfordert, die mit einem Eintrag im Walled Garden übereinstimmt, löst der AP die Domain in ihre aktuelle IP-Adresse auf und erlaubt dem Client vorübergehend, mit dieser IP zu kommunizieren [3].
Dynamische CDN-IPs: CDNs wie Amazon CloudFront (*.cloudfront.net) und Akamai (*.akamaihd.net) lösen in hochdynamische, geografisch verteilte IP-Adressen auf, die sich häufig ändern. Das DNS-basierte Whitelisting von Meraki bewältigt dies nahtlos, indem es die Domains in Echtzeit auflöst. Verwenden Sie niemals statische IP-Adressen für CDN-Ressourcen in Ihrem Walled Garden, da dies zu sporadischen Ladefehlern von Portal-Assets führt.

Best Practices

Um eine hohe Verfügbarkeit, Sicherheit und ein optimales Benutzererlebnis zu gewährleisten, sollten Sie diese branchenüblichen Best Practices für die Bereitstellung befolgen:

1. Netzwerksegmentierung und VLAN-Isolierung

Leiten Sie den Gästeverkehr niemals direkt per Bridge in Ihr Unternehmens-LAN weiter. Konfigurieren Sie Ihre Meraki MR APs so, dass sie den Gästeverkehr mit einem dedizierten Gäste-VLAN (z. B. VLAN 30) taggen [4]. Stellen Sie sicher, dass dieses VLAN auf einer DMZ oder einer separaten VRF-Instanz (Virtual Routing and Forwarding) auf Ihrer Upstream-Firewall endet. Dies minimiert die Risiken einer lateralen Bewegung und stellt die Einhaltung von Sicherheitsstandards wie PCI DSS und GDPR sicher [2] [4].

2. Failover und Sitzungsresilienz konfigurieren

Netzwerkverbindungen können ausfallen. Um zu verhindern, dass Gäste während eines Ausfalls des Authentifizierungsservers vom Internet ausgesperrt werden, konfigurieren Sie die RADIUS Failover Policy im Meraki-Dashboard:

Failover Policy: Stellen Sie dies auf Deny access ein, um maximale Sicherheit zu gewährleisten, oder auf Allow access, wenn die Aufrechterhaltung der Konnektivität für Gäste während eines Ausfalls Vorrang vor der Datenerfassung hat.
Secondary Servers: Konfigurieren Sie immer sowohl primäre als auch sekundäre RADIUS-Server, um die Last zu verteilen und ein automatisches Failover bereitzustellen [1].

3. Sitzungs- und Inaktivitäts-Timeouts implementieren

Verwalten Sie Ihr Funkspektrum und Ihre DHCP-Pool-Leases, indem Sie entsprechende Timeout-Parameter konfigurieren [1]:

Session Timeout: Stellen Sie dies auf 1440 minutes (24 hours) für das Gastgewerbe ein, damit Gäste während ihres gesamten Aufenthalts ohne ständige erneute Authentifizierung verbunden bleiben können [1]. Reduzieren Sie dies für den Einzelhandel oder den öffentlichen Nahverkehr auf 120 minutes (2 hours), um eine erneute Interaktion zu fördern und DHCP-Leases freizugeben.
Idle Timeout: Stellen Sie dies auf 15 minutes ein. Wenn ein Client-Gerät in den Ruhezustand wechselt oder den Standort verlässt, beendet der AP die Sitzung und gibt Netzwerkressourcen wieder frei [1].

Fehlerbehebung & Risikominderung

Bei der Bereitstellung externer Captive Portals auf Cisco Meraki treten bei Technikern häufig drei Hauptfehlerbilder auf. Verwenden Sie diese Diagnosematrix, um Probleme schnell zu isolieren und zu beheben:

Symptom	Ursache	Diagnoseschritt	Behebung
Splash Page lädt nicht; Browser zeigt „Connection Timed Out“ an.	Die Upstream-Firewall blockiert ausgehenden DNS- oder HTTP/HTTPS-Traffic zum CDN von Purple [1].	Versuchen Sie, `login.venuewifi.com` von einem kabelgebundenen Gerät im selben VLAN aufzulösen.	Stellen Sie sicher, dass das Gäste-VLAN ausgehenden Zugriff auf öffentliches DNS (UDP 53) und HTTP/HTTPS (TCP 80/443) hat.
Splash Page lädt, aber die Benutzeranmeldedaten können nicht authentifiziert werden.	Die Upstream-Firewall blockiert RADIUS-Traffic, der aus der Meraki Cloud stammt [1].	Verwenden Sie das Dienstprogramm RADIUS Test im Meraki-Dashboard unter Access Control [1].	Fügen Sie die ausgehenden IP-Bereiche des Meraki-Dashboards (zu finden unter Help > Firewall info) zur ausgehenden Zulassungsliste Ihrer Firewall für die UDP-Ports 1812 und 1813 hinzu [1].
Social Login (z. B. Google OAuth) schlägt mit einem Weiterleitungsfehler fehl.	Fehlende erforderliche OAuth-Helper-Domäns im Meraki Walled Garden [1].	Überprüfen Sie die Browserkonsole auf dem Client-Gerät auf blockierte Ladevorgänge von Ressourcen.	Fügen Sie die erforderlichen OAuth-Domains (z. B. `.googleapis.com`, `.gstatic.com`) zur Walled Garden-Liste hinzu [1].

ROI & geschäftliche Auswirkungen

Die Integration von Cisco Meraki mit Purple verwandelt das Gäste-WiFi von einem Kostenfaktor in ein strategisches Geschäftsgut. Durch die Nutzung von Hardware der Enterprise-Klasse in Kombination mit fortschrittlichen Analysen erzielen Unternehmen messbare Erträge in mehreren Dimensionen:

Datenmonetarisierung & Marketing-Reichweite: Durch die Erfassung verifizierter E-Mail-Adressen und Social-Media-Profile bauen Standorte eine saubere, datenschutzkonforme Datenbank mit First-Party-Kundendaten auf [2]. Diese fließen direkt in CRM- (Customer Relationship Management) und Marketing-Automatisierungssysteme ein und ermöglichen hochgradig zielgerichtete, hyperlokale Marketingkampagnen.
Operative Effizienz: Das automatisierte Onboarding über Purple entlastet das Personal an der Rezeption und im IT-Support. In der Hotellerie und Gastronomie führt dies zu weniger Gästebeschwerden bezüglich der WiFi-Konnektivität und zu einem geringeren operativen Aufwand.
Fortschrittliche Besucheranalysen: Durch die Kombination der Standort-APIs von Meraki mit der Analyse-Engine von Purple erhalten Standortbetreiber tiefe Einblicke in das Besucherverhalten, einschließlich Besucherzahlen, Verweilzeiten, Rückkehrraten und Spitzenzeiten [2]. Diese Daten bilden die Grundlage für fundierte Entscheidungen in Bezug auf Personalplanung, Ladenlayouts und Immobilienbewertung.

Referenzen

Schlüsseldefinitionen

Captive Portal

A web page that is displayed to newly connected users of a Wi-Fi network before they are granted broader access to network resources.

Used by venues to enforce terms of service, collect user data, and authenticate guests via RADIUS before allowing internet access.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management for users who connect and use a network service.

Meraki APs query Purple's Cloud RADIUS servers to verify guest credentials and authorize network access.

Walled Garden

A restricted set of IP addresses or domain names that unauthenticated guest clients are permitted to access before completing the captive portal sign-on process.

Crucial for allowing clients to reach the hosted splash page, download CSS/JS assets from CDNs, and communicate with social login OAuth endpoints.

Session-Timeout

An RFC 2865 RADIUS attribute that specifies the maximum number of seconds a user session can remain active before requiring re-authentication.

Returned by Purple RADIUS in the Access-Accept packet to control how long a guest remains logged in (e.g., 24 hours for hotel guests).

Idle-Timeout

A RADIUS attribute that defines the maximum period of inactivity (no data transferred) allowed before the user's session is terminated.

Used to disconnect stale devices and reclaim IP addresses in high-density environments like stadiums or retail stores.

PAP (Password Authentication Protocol)

A simple, unencrypted authentication protocol used by RADIUS to validate user credentials.

Required by Cisco Meraki for external splash page RADIUS authentication. Security is maintained by encrypting the client-to-portal transit via HTTPS and encrypting the RADIUS packet password field using the shared secret.

Passpoint (Hotspot 2.0)

An industry standard developed by the Wi-Fi Alliance that enables cellular-like automatic roaming and secure connection to Wi-Fi networks.

Supported by Meraki MR access points and Purple to enable seamless, certificate-based guest onboarding without captive portals.

CMX (Cisco Meraki Location APIs)

An API framework that allows Meraki access points to export real-time location and presence data (probe requests) to third-party analytics platforms.

Integrated with Purple to provide detailed footfall, dwell time, and return rate analytics for physical venues.

Ausgearbeitete Beispiele

A luxury 350-room hotel running Cisco Meraki MR46 access points needs to deploy a secure guest WiFi network. They want to capture guest emails, restrict bandwidth to 5 Mbps per guest, and ensure that guests only need to log in once every 7 days. How should the network architect configure the Meraki Dashboard and RADIUS settings?

SSID Setup: Configure an open SSID named 'Hotel_Guest' with the splash page set to 'Sign-on with' and 'my RADIUS server'.\n2. RADIUS Configuration: Enter Purple's primary (116.203.120.121) and secondary (195.201.123.149) RADIUS IPs. Set the authentication port to 1812 and the accounting port to 1813. Configure the shared secret.\n3. Timeout Parameters: In the RADIUS server profile or Purple dashboard, set the Session-Timeout attribute to 604800 seconds (7 days) and Idle-Timeout to 1800 seconds (30 minutes) to reclaim inactive DHCP leases.\n4. Traffic Shaping: In the Meraki Dashboard under Wireless > Configure > Firewall & traffic shaping, select the SSID, enable traffic shaping, and set a per-client limit to 5 Mbps downstream and 2 Mbps upstream.\n5. Walled Garden: Enable the walled garden and add *.purple.ai, *.venuewifi.com, and necessary CDN wildcards like *.cloudfront.net to allow the splash page to render pre-authentication.

Kommentar des Prüfers: This solution successfully balances user experience with network performance. Using a 7-day Session-Timeout prevents login fatigue for long-stay guests, while the 30-minute Idle-Timeout prevents IP address exhaustion in the DHCP pool. Configuring traffic shaping directly on the Meraki APs rather than relying on RADIUS attributes (like Maximum-Data-Rate-Downstream) is preferred as it reduces processing overhead on the APs and provides a more consistent enforcement mechanism.

A national retail chain with 45 stores wants to deploy guest WiFi across all locations using Meraki MR33 APs. They need to ensure consistent configuration, block corporate network access, and collect footfall analytics. How should this be implemented at scale?

Configuration Templates: Create a single Network Configuration Template in the Meraki Dashboard. Configure the guest SSID with Purple's RADIUS settings, walled garden domains, and the custom splash URL: https://login.venuewifi.com/ip/v2/meraki. Bind all 45 store networks to this template.\n2. VLAN Segmentation: On each store's local switch and firewall, configure a dedicated Guest VLAN (e.g., VLAN 50). In the Meraki SSID settings, set Client IP Assignment to 'External DHCP server' and specify VLAN 50. Ensure the firewall blocks all routing from VLAN 50 to corporate subnets.\n3. Location Analytics: Enable Meraki Scanning API (CMX) in the Meraki Dashboard under Network-wide > Configure > General. Enter the Purple Post URL and secret validator. This allows Meraki APs to stream real-time probe request data to Purple's analytics engine for footfall and dwell time reporting.

Kommentar des Prüfers: Deploying at scale requires automation and template-based management. By binding all networks to a single template, any future walled garden updates (such as adding a new social login provider) can be pushed to all 45 stores instantly, eliminating manual configuration errors. Enabling the Meraki Scanning API alongside RADIUS accounting ensures that the retailer captures both active guest session analytics and passive visitor footfall metrics, maximizing the business value of the deployment.

Übungsfragen

Q1. A network engineer deploys a new Meraki guest SSID with a Purple captive portal. Unauthenticated clients are successfully redirected to the login page, but when they attempt to use 'Log in with Google', the page spins and eventually fails with a DNS or timeout error. Other login methods (like email form) work perfectly. What is the most likely cause of this issue, and how should it be resolved?

Hinweis: Consider what external domains the client's browser must reach to complete the Google OAuth handshake before the RADIUS authentication is completed.

Musterlösung anzeigen

The most likely cause is that the Google OAuth helper domains are missing from the Meraki SSID's Walled Garden configuration. While the core Purple domains and CDN domains are allowed (which is why the splash page loads), the Google authentication servers are being blocked by the AP's pre-authentication firewall rules. To resolve this, navigate to Wireless > Configure > Access control, select the guest SSID, and append the following Google OAuth domains to the Walled Garden list: accounts.google.com, *.googleapis.com, *.gstatic.com, and *.googleusercontent.com. Once saved, the AP will permit the client to complete the Google authentication handshake and redirect back to Purple to complete the RADIUS login.

Q2. During a post-deployment audit of a high-density stadium WiFi network, the IT team notices that the DHCP pool for the guest VLAN (a /21 subnet with 2048 IPs) is completely exhausted within the first 2 hours of an event, even though active concurrent connections never exceed 800. RADIUS accounting is enabled. How can the network architect adjust the Meraki and RADIUS settings to mitigate this issue?

Hinweis: Analyze the relationship between client session timeouts, idle timeouts, and DHCP lease times in high-density transient environments.

Musterlösung anzeigen

The DHCP pool exhaustion is caused by transient clients (users walking past or entering the stadium briefly) connecting, obtaining an IP address, and then leaving the venue. Because the default Meraki Session-Timeout or DHCP lease time is too long, those IP addresses remain reserved even though the physical devices are no longer present. To resolve this, the architect should implement three coordinated changes: 1) Reduce DHCP Lease Time: On the DHCP server (or Meraki security appliance handling DHCP), reduce the lease time to 10 or 15 minutes. 2) Configure Idle Timeout: Ensure RADIUS accounting is enabled on port 1813 and configure an Idle-Timeout of 10 minutes (600 seconds) in the RADIUS Access-Accept profile. This tells the Meraki AP to terminate the session of any client inactive for 10 minutes. 3) Shorten Session Timeout: Reduce the global Session-Timeout for the stadium profile to 120 minutes (7200 seconds) to force periodic re-evaluation of active devices.

Q3. An MSP is configuring a Meraki guest SSID with a Purple captive portal. They have entered the correct Purple RADIUS server IPs and ports (1812/1813) in the Meraki Dashboard, but when testing with the built-in RADIUS 'Test' tool, all access points fail to reach the server. The MSP verifies that the RADIUS shared secret is correct and that the Purple cloud is online. What routing or firewall configuration did the MSP likely overlook?

Hinweis: Recall where RADIUS authentication requests are sourced from in a Cisco Meraki cloud-managed architecture.

Musterlösung anzeigen

The MSP likely configured their local network firewalls to allow outbound RADIUS traffic from the local AP subnets, but forgot that in a Meraki splash page deployment, RADIUS Access-Requests are sourced directly from the Cisco Meraki Dashboard Cloud Infrastructure, not from the local APs. To resolve this, the MSP must obtain the outbound IP ranges of the Meraki Dashboard (found in the Meraki Dashboard under Help > Firewall info) and configure their upstream corporate firewall to allow inbound and outbound UDP traffic on ports 1812 (Authentication) and 1813 (Accounting) between those Meraki Dashboard IP ranges and Purple's Cloud RADIUS servers. Additionally, they must ensure that the Meraki Dashboard IPs are added as valid RADIUS clients in the Purple portal configuration.

Weiterlesen in dieser Reihe

CommScope Ruckus Integration mit Purple WiFi: Einrichtungs- und Konfigurationshandbuch

Dieses technische Referenzhandbuch bietet einen maßgeblichen Konfigurationsleitfaden für die Integration von CommScope Ruckus-Architekturen mit Purple WiFi. Es beschreibt Schritt-für-Schritt-Bereitstellungen für Guest WiFi Captive Portals, sicheres Mitarbeiter-WiFi über 802.1X und mandantenfähige Netzwerkisolierung mithilfe von Ruckus Dynamic PSK.

Cisco WLC and Catalyst Integration with Purple WiFi: Step-by-Step Guest Access Guide

Diese Anleitung beschreibt die schrittweise Integration von Cisco WLC und Catalyst 9800 Wireless mit Purple. Sie umfasst die Weiterleitung zum Guest WiFi Captive Portal über Central Web Authentication, sicheres Mitarbeiter-WiFi mittels 802.1X EAP-TLS sowie Multi-Tenant-Segmentierung über Cisco Identity Pre-Shared Keys (iPSK) mit dynamischer VLAN-Zuweisung. Sie richtet sich an Netzwerkarchitekten in Unternehmen und IT-Sicherheitsverantwortliche, die Cisco-Infrastrukturen im Gastgewerbe, im Einzelhandel und in großen öffentlichen Veranstaltungsorten bereitstellen.

OpenWrt Custom Firmware Integration with Purple WiFi

Dieses Handbuch bietet das vollständige Integrations-Playbook für die Bereitstellung von OpenWrt Custom Firmware mit Purple WiFi. Es deckt die Konfiguration des CoovaChilli Captive Portal, die Verwaltung des iptables Walled Garden, sicheres Mitarbeiter-WiFi über 802.1X mit hostapd sowie die mandantenfähige PPSK-Segmentierung mit dynamischer VLAN-Zuweisung ab. Damit erhalten IT-Teams die genauen Konfigurationsschritte, die für den Aufbau eines identitätsbasierten Netzwerks auf jeder OpenWrt-fähigen Hardware erforderlich sind.