Captive Portal for Cisco Meraki

Un guide de référence technique faisant autorité, de niveau intermédiaire, pour l'intégration des points d'accès Cisco Meraki MR avec le Captive Portal cloud de Purple. Couvre les configurations étape par étape du Meraki Dashboard, les paramètres du serveur RADIUS (ports 1812/1813), les exceptions de domaine génériques (wildcard) pour le walled garden, et les paramètres de délai d'expiration de session pour les déploiements WiFi invités haute performance.

📖 8 min de lecture📝 1,892 mots🔧 2 exemples concrets❓ 3 questions d'entraînement📚 8 définitions clés

Écouter ce guide

Voir la transcription du podcast

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: WiFi multi-tenant →

Résumé exécutif

Ce guide de référence faisant autorité fournit un cadre de configuration complet et étape par étape pour intégrer les réseaux sans fil Cisco Meraki au Captive Portal basé sur le cloud de Purple. Conçu pour les responsables informatiques, les architectes réseau et les fournisseurs de services gérés (MSP), ce document détaille les configurations exactes requises au sein du Meraki Dashboard pour déployer une solution WiFi invité sécurisée et performante [1].

En découplant la couche d'intelligence invité du matériel, les sites d'entreprise peuvent exploiter les plateformes certifiées Guest WiFi et WiFi Analytics de Purple pour capturer des données de première partie riches et conformes au GDPR, tout en garantissant l'intégrité du réseau et la conformité réglementaire [2]. Ce guide aborde les paramètres d'intégration critiques, notamment l'authentification RADIUS (ports 1812/1813), les exceptions de domaine de walled garden, la résolution wildcard CDN et les mécanismes de redirection des invités dans divers sites physiques tels que les hubs du Commerce de détail , de la Santé , de l' Hôtellerie et des Transports .

Analyse technique approfondie

Pour intégrer avec succès les points d'accès (AP) Cisco Meraki MR à un Captive Portal externe comme Purple, les ingénieurs réseau doivent comprendre l'architecture sous-jacente des plans de contrôle et de données. Contrairement aux contrôleurs sans fil sur site traditionnels où les requêtes d'authentification RADIUS proviennent du contrôleur physique ou des AP individuels, Cisco Meraki utilise une architecture gérée dans le cloud [1].

Séparation du plan de contrôle et du plan de données

Lorsqu'un client invité s'associe à un SSID ouvert configuré pour un Captive Portal externe, l'AP Meraki MR place le client dans un état de pré-authentification. Dans cet état, tout le trafic est bloqué à l'exception des requêtes DNS, du DHCP et du trafic destiné aux adresses IP ou aux noms d'hôte explicitement définis dans le Walled Garden [3].

Les messages RADIUS Access-Request réels ne sont pas générés par l'AP Meraki MR local. Ils proviennent plutôt de l'infrastructure cloud du Cisco Meraki Dashboard [1]. Il s'agit d'une distinction architecturale cruciale :

> "Les messages de demande d'accès RADIUS pour une page d'accueil proviendront du dashboard, et non des appareils Meraki locaux. Par conséquent, l'adresse IP LAN privée du serveur RADIUS ne peut pas être spécifiée ici." [1]

Par conséquent, les pare-feu en amont protégeant vos serveurs RADIUS doivent autoriser le trafic entrant provenant de l'ensemble du bloc de plages d'adresses IP sortantes du Meraki Dashboard, qui sont dynamiques et spécifiques à chaque région [1]. Ces plages peuvent être récupérées dynamiquement via le Meraki Dashboard sous Help > Firewall info [1].

Protocole d'authentification RADIUS (PAP)

Pour l'authentification sur la page d'accueil de connexion, Meraki utilise le protocole PAP (Password Authentication Protocol) [1]. Bien que le protocole PAP soit historiquement non chiffré, l'intégration Meraki-Purple atténue les risques de sécurité grâce à un chiffrement multicouche :

Chiffrement client-vers-cloud : Le client invité établit une session HTTPS (SSL/TLS) sécurisée directement avec le Captive Portal hébergé de Purple. Les identifiants (par exemple, les jetons de connexion sociale, les formulaires d'e-mail) sont chiffrés en transit depuis le navigateur du client vers les serveurs de Purple [1].
Chiffrement du secret partagé RADIUS : Lorsque le Cloud Meraki envoie la requête RADIUS Access-Request au serveur Cloud RADIUS de Purple, il chiffre le mot de passe de l'utilisateur à l'aide du secret partagé RADIUS configuré et d'une fonction XOR standard conformément à la norme RFC 2865 [1]. Cela garantit que les identifiants en clair ne sont jamais transmis sur l'internet public.

Attributs RADIUS pris en charge

Le Cloud Meraki et le Cloud RADIUS de Purple échangent plusieurs attributs clés lors de la phase d'authentification pour appliquer les paramètres et les politiques de session :

Attribut RADIUS	Type	Direction	Description et contexte pratique
User-Name	Chaîne	Requête	L'identifiant de l'utilisateur invité (ex. adresse e-mail, adresse MAC) [1].
User-Password	Chaîne	Requête	Le mot de passe utilisateur chiffré ou le jeton de session [1].
Called-Station-ID	Chaîne	Requête	Formaté comme `AP_MAC:SSID_NAME` (ex. `AA-BB-CC-DD-EE-FF:GuestWiFi`). Crucial pour le routage des politiques basé sur la localisation [1].
Calling-Station-ID	Chaîne	Requête	L'adresse MAC physique du client (ex. `11-22-33-44-55-66`). Utilisé pour le suivi des appareils et la reprise de session [1].
Session-Timeout	Entier	Acceptation	La durée maximale de la session en secondes. Après expiration, le client est redirigé vers le Captive Portal [1].
Idle-Timeout	Entier	Acceptation	Le temps d'inactivité maximal en secondes. Si aucune donnée n'est transférée, la session est interrompue. Nécessite l'accounting RADIUS [1].
Filter-Id	Chaîne	Acceptation	Transmet le nom d'une politique de groupe Meraki spécifique à appliquer au client (ex. limitation de la bande passante ou blocage de catégories spécifiques) [1].

Guide d'implémentation

Ce guide de configuration étape par étape décrit comment intégrer les points d'accès Cisco Meraki MR au Captive Portal externe de Purple.

Étape 1 : Configurer le contrôle d'accès au SSID

Accédez à Wireless > Configure > Access control dans le Meraki Dashboard [1]. Sélectionnez votre SSID invité cible et configurez les paramètres suivants :

Association Requirements : Définissez sur Open (no encryption) [1]. Cela garantit une expérience d'intégration fluide. Si vous avez besoin d'un transit invité chiffré, envisagez d'implémenting Passpoint / Hotspot 2.0 with Cloud RADIUS [4].
Splash Page : Sélectionnez Sign-on with et choisissez my RADIUS server dans le menu déroulant [1].
Serveurs RADIUS : Cliquez sur Add server et saisissez les points de terminaison principal et secondaire du Cloud RADIUS de Purple [1] :
- Host IP : 116.203.120.121 (Principal) et 195.201.123.149 (Secondaire)
- Port : 1812 (Authentification) [1]
- Secret : [Votre secret partagé Purple]
RADIUS Accounting : Définissez sur RADIUS accounting is enabled et ajoutez les serveurs de comptabilisation :
- Host IP : 116.203.120.121 (Principal) et 195.201.123.149 (Secondaire)
- Port : 1813 (Comptabilisation)
- Secret : [Votre secret partagé Purple]
Force du Captive Portal : Sélectionnez Block all access until sign-on is complete [1]. Cela impose strictement que les clients ne puissent pas accéder à Internet sans passer par la splash page.

Étape 2 : Configurer l'URL personnalisée de la Splash Page

Accédez à Wireless > Configure > Splash page [1]. Sélectionnez votre SSID invité et configurez :

Custom Splash URL : Sélectionnez Or point to a custom URL et saisissez l'URL de redirection Purple :
- https://login.venuewifi.com/ip/v2/meraki
Splash Page Redirect : Définissez sur The URL they were trying to fetch ou redirigez-les vers une page de destination spécifique (par exemple, la page d'accueil de votre établissement) [3].

Étape 3 : Configurer les exceptions de noms de domaine du Walled Garden

Pour garantir que les clients invités puissent charger le Captive Portal, télécharger des ressources à partir de réseaux de diffusion de contenu (CDN) et effectuer l'authentification sociale (par exemple, Google ou Facebook OAuth), vous devez activer et configurer le Walled Garden [3].

Retournez dans Wireless > Configure > Access control et localisez la section Walled Garden [1].

Définissez Walled Garden sur Walled garden is enabled [1].
Dans le champ Walled garden ranges, saisissez les FQDN et les domaines génériques (wildcards) requis [1].

Comment Meraki gère les wildcards et le trafic CDN

Les points d'accès Cisco Meraki MR prennent en charge les domaines génériques dans le walled garden en utilisant le préfixe astérisque (par exemple, *.purple.ai) [1]. Cependant, il est essentiel de comprendre les mécanismes sous-jacents :

Mise sur liste autorisée basée sur le DNS : Le point d'accès Meraki intercepte les requêtes DNS du client. Lorsque le client demande un domaine correspondant à une entrée du walled garden, le point d'accès résout le domaine avec son adresse IP actuelle et autorise temporairement le client à communiquer avec cette IP [3].
Adresses IP CDN dynamiques : Les CDN comme Amazon CloudFront (*.cloudfront.net) et Akamai (*.akamaihd.net) se résolvent en adresses IP hautement dynamiques et géographiquement distribuées qui changent fréquemment. La mise sur liste autorisée basée sur le DNS de Meraki gère cela de manière transparente en résolvant les domaines en temps réel. N'utilisez jamais d'adresses IP statiques pour les ressources CDN dans votre walled garden, car cela entraînera des échecs de chargement intermittents des ressources du portail.

Bonnes pratiques

Pour garantir une haute disponibilité, une sécurité accrue et une expérience utilisateur optimale, respectez ces bonnes pratiques de déploiement conformes aux normes de l'industrie :

1. Segmentation du réseau et isolation VLAN

Ne pontez jamais le trafic invité directement sur votre réseau local d'entreprise (LAN). Configurez vos points d'accès Meraki MR pour étiqueter le trafic invité avec un VLAN invité dédié (par exemple, VLAN 30) [4]. Assurez-vous que ce VLAN se termine sur une DMZ ou une instance de routage et de transfert virtuel (VRF) distincte sur votre pare-feu en amont. Cela atténue les risques de déplacement latéral et garantit la conformité avec les normes de sécurité telles que PCI DSS et la GDPR [2] [4].

2. Configurer le basculement et la résilience des sessions

Les liaisons réseau peuvent échouer. Pour éviter que les invités ne soient bloqués sans accès à Internet lors d'une panne du serveur d'authentification, configurez la politique de basculement RADIUS (RADIUS Failover Policy) dans le tableau de bord Meraki :

Failover Policy : Définissez sur Deny access pour une sécurité maximale, ou Allow access si le maintien de la connectivité des invités est prioritaire sur la collecte de données lors d'une panne.
Serveurs secondaires : Configurez toujours les serveurs RADIUS principal et secondaire pour répartir la charge et assurer un basculement automatique [1].

3. Implémenter des délais d'expiration de session et d'inactivité

Gerez votre spectre sans fil et vos baux de pool DHCP en configurant des paramètres de délai d'expiration appropriés [1] :

Session Timeout : Définissez sur 1440 minutes (24 heures) pour les environnements hôteliers, permettant aux invités de rester connectés tout au long de leur séjour sans réauthentification constante [1]. Pour le commerce de détail ou les transports publics, réduisez cette valeur à 120 minutes (2 hours) pour encourager un nouvel engagement et libérer des baux DHCP.
Idle Timeout : Définissez sur 15 minutes. Si un appareil client se met en veille ou quitte l'établissement, le point d'accès met fin à la session, récupérant ainsi les ressources réseau [1].

Dépannage et atténuation des risques

Lors du déploiement de Captive Portals externes sur Cisco Meraki, les ingénieurs rencontrent généralement trois principaux modes de défaillance. Utilisez cette matrice de diagnostic pour isoler et résoudre rapidement les problèmes :

Symptôme	Cause racine	Étape de diagnostic	Résolution
La splash page ne se charge pas ; le navigateur affiche « Connection Timed Out ».	Le pare-feu en amont bloque le trafic DNS ou HTTP/HTTPS sortant vers le CDN de Purple [1].	Essayez de résoudre `login.venuewifi.com` depuis un appareil câblé sur le même VLAN.	Assurez-vous que le VLAN invité dispose d'un accès sortant vers le DNS public (UDP 53) et HTTP/HTTPS (TCP 80/443).
La splash page se charge, mais l'authentification des identifiants utilisateur échoue.	Le pare-feu en amont bloque le trafic RADIUS provenant du cloud Meraki [1].	Utilisez l'utilitaire RADIUS Test dans le tableau de bord Meraki sous Access Control [1].	Ajoutez les plages d'adresses IP sortantes du tableau de bord Meraki (accessibles sous Help > Firewall info) à la liste d'autorisation de sortie de votre pare-feu pour les ports UDP 1812 et 1813 [1].
La connexion via les réseaux sociaux (par exemple, Google OAuth) échoue avec une erreur de redirection.	Domaines d'assistance OAuth requis manquantsns dans le Walled Garden Meraki [1].	Vérifiez la console du navigateur sur l'appareil client pour détecter les chargements de ressources bloqués.	Ajoutez les domaines OAuth obligatoires (par ex. `.googleapis.com`, `.gstatic.com`) à la liste du Walled Garden [1].

ROI et impact commercial

L'intégration de Cisco Meraki avec Purple transforme le WiFi invité d'un centre de coûts en un actif commercial stratégique. En s'appuyant sur du matériel de qualité professionnelle et des analyses avancées, les organisations obtiennent des rendements mesurables dans plusieurs dimensions :

Monétisation des données et portée marketing : En capturant des adresses e-mail vérifiées et des profils sociaux, les établissements constituent une base de données propre et conforme de données clients de première main [2]. Ces données alimentent directement les systèmes de gestion de la relation client (CRM) et d'automatisation du marketing, permettant des campagnes marketing hautement ciblées et hyper-locales.
Efficacité opérationnelle : L'intégration automatisée via Purple allège la charge de travail du personnel d'accueil et du support informatique. Dans le secteur de l'hôtellerie, cela se traduit par moins de plaintes des clients concernant la connectivité WiFi et une réduction des coûts opérationnels.
Analyses avancées de fréquentation : En combinant les API de localisation de Meraki avec le moteur d'analyse de Purple, les exploitants de sites obtiennent des informations approfondies sur le comportement des visiteurs, notamment la fréquentation, les temps de séjour, les taux de retour et les heures de pointe [2]. Ces données permettent de prendre des décisions éclairées concernant le personnel, l'agencement des magasins et la valorisation immobilière.

Références

Définitions clés

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.

Exemples concrets

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.

Commentaire de l'examinateur : 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.

Commentaire de l'examinateur : 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.

Questions d'entraînement

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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.

Continuer la lecture de cette série

Intégration de CommScope Ruckus avec Purple WiFi : Guide d'installation et de configuration

Ce guide de référence technique fournit un manuel de configuration faisant autorité pour l'intégration des architectures CommScope Ruckus avec Purple WiFi. Il détaille les déploiements étape par étape pour les Captive Portals de WiFi invité, le WiFi personnel sécurisé via 802.1X et l'isolation réseau multi-locataire à l'aide de Ruckus Dynamic PSK.

Allied Telesis Access Points Integration with Purple WiFi

Ce guide fournit un manuel de configuration complet pour intégrer les points d'accès Allied Telesis de la série TQ avec Purple WiFi. Il couvre la redirection vers un Captive Portal externe, l'authentification RADIUS 802.1X et le routage dynamique des VLAN à l'aide de clés pré-partagées privées (PPSK) pour des déploiements multi-locataires sécurisés.

Grandstream GWN Access Points Integration with Purple WiFi

Ce guide de référence technique faisant autorité détaille comment intégrer les points d'accès Grandstream GWN avec la plateforme de Guest WiFi et d'analyse de Purple. Il couvre la configuration du Captive Portal Grandstream, les paramètres RADIUS AAA, la configuration du walled garden, l'authentification sécurisée du personnel en 802.1X avec routage VLAN dynamique, et la segmentation PPSK multi-tenant - fournissant des instructions pratiques, étape par étape, pour les MSP et les équipes informatiques déployant du WiFi pour les invités et le personnel à grande échelle.