Captive Portal for Cisco Meraki

Bienvenue dans la série de briefings techniques de Purple. Je suis votre hôte, et aujourd'hui nous allons aborder un sujet qui revient dans presque tous les déploiements de WiFi invités en entreprise sur lesquels nous travaillons : la configuration d'un Captive Portal sur les points d'accès Cisco Meraki MR, et plus particulièrement son intégration avec la plateforme cloud de Purple via l'authentification RADIUS. Que vous soyez un MSP intégrant un nouveau client dans le secteur de l'hôtellerie ou un architecte réseau interne pour une chaîne de magasins, cet épisode vous fournira les étapes de configuration précises et les explications associées. Plantons le décor. Vous disposez d'un site — qu'il s'agisse d'un hôtel, d'un centre de conférences, d'un stade ou d'un parc commercial — équipé de points d'accès Cisco Meraki MR gérés via le tableau de bord Meraki. L'objectif est de déployer une expérience WiFi invité personnalisée aux couleurs de la marque, qui collecte des données de première main, impose l'acceptation des conditions d'utilisation et transmet les données analytiques à une plateforme marketing. C'est précisément pour cela que Purple a été conçu, et Meraki représente l'un de nos déploiements matériels les plus courants à l'échelle mondiale. Maintenant, le point d'architecture essentiel à comprendre avant de modifier le moindre paramètre est le suivant : sur Cisco Meraki, l'authentification RADIUS pour un portail d'accès n'est pas traitée localement par le point d'accès. La requête RADIUS Access-Request provient du cloud Meraki — de l'infrastructure du tableau de bord — et non de l'AP sur votre réseau local. Il s'agit d'une distinction cruciale qui piège de nombreux ingénieurs lors de leur premier déploiement Meraki. Cela signifie que votre serveur RADIUS, en l'occurrence le point de terminaison RADIUS cloud de Purple, doit être accessible depuis Internet, et que vos règles de pare-feu doivent autoriser le trafic provenant des plages d'adresses IP du tableau de bord Meraki, et pas seulement de votre sous-réseau AP local. Vous trouverez les plages d'adresses IP actuelles du tableau de bord sous Aide, puis Informations sur le pare-feu dans votre tableau de bord Meraki. Passons maintenant à la configuration. Je vais vous guider dans l'ordre dans lequel vous procéderiez réellement lors d'un déploiement réel. Étape 1 : Configuration du SSID. Dans le tableau de bord Meraki, accédez à Sans fil, puis Configurer, puis SSIDs. Sélectionnez l'emplacement du SSID que vous souhaitez utiliser pour l'accès invité. Donnez-lui un nom clair — par exemple GuestWiFi ou NomDuSite_Guest. Sous les exigences d'association, définissez la sécurité sur Ouvert, sans chiffrement. C'est tout à fait normal et intentionnel — la couche de sécurité pour les invités est gérée par le Captive Portal et l'authentification RADIUS, et non par le chiffrement WPA. Si vous effectuez un déploiement dans un environnement PCI DSS, vous devrez vous assurer que le trafic invité est isolé sur son propre VLAN, ce que nous aborderons sous peu. Étape deux : Splash page et authentification. Toujours sur la page Access Control de votre SSID, faites défiler vers le bas jusqu'à la section Splash page. Définissez-la sur Sign-on with, et dans le menu déroulant, sélectionnez my RADIUS server. C'est le paramètre critique qui indique à Meraki d'authentifier les utilisateurs auprès d'un serveur RADIUS externe avant d'autoriser l'accès au réseau. En dessous, vous verrez l'option Captive portal strength. Définissez-la sur Block all access until sign-on is complete. C'est ce qui applique le walled garden — sans cela, les invités pourraient contourner complètement le Captive Portal. Étape trois : Configuration du serveur RADIUS. Dans la section RADIUS, cliquez sur Add server. Vous aurez besoin de trois informations provenant de votre compte Purple : l'adresse IP ou le FQDN du serveur RADIUS, le port d'authentification qui est UDP 1812, et le secret partagé. Purple fournit ces informations dans la section de configuration du site du portail. Pour assurer la redondance dans les déploiements de production, vous devez ajouter un serveur RADIUS secondaire — Purple fournit un point de terminaison de basculement. Définissez le port de comptabilité (accounting) sur UDP 1813 si vous souhaitez que les données de session soient renvoyées vers le moteur d'analyse de Purple, ce que je recommande vivement pour tout site où le temps de séjour et la durée des sessions sont des indicateurs significatifs. Une note rapide sur les attributs RADIUS. Meraki respecte l'attribut Session-Timeout renvoyé dans la réponse RADIUS Access-Accept. Purple utilise cet attribut pour contrôler la durée d'une session invité avant qu'une réauthentification ne soit requise. Pour un hôtel, vous pouvez le configurer sur 86 400 secondes — soit 24 heures. Pour un café, une valeur de 3 600 secondes, soit une heure, est plus appropriée. L'attribut Idle-Timeout est également respecté, mais uniquement si la comptabilité RADIUS est activée. Cela déconnecte les sessions inactives, ce qui est important pour la gestion de la capacité dans les sites à haute densité. Étape quatre : URL de la Splash page. Accédez à Wireless, puis Configure, puis Splash page. Sélectionnez votre SSID invité dans le menu déroulant. Définissez l'URL Custom splash URL sur l'URL du portail Purple de votre site. C'est l'URL vers laquelle Meraki redirigera les clients non authentifiés. Meraki ajoute des paramètres de requête à cette URL — y compris un paramètre login_url — que Purple utilise pour finaliser le processus d'authentification. Ne modifiez pas et ne supprimez pas ces paramètres. Étape cinq : le walled garden. C'est ici que la plupart des déploiements rencontrent des difficultés. Le walled garden est la liste des domaines et des plages d'adresses IP qu'un appareil invité peut atteindre avant de s'être authentifié. Sans les entrées correctes, la page du Captive Portal elle-même ne se chargera pas, car le navigateur sera bloqué et ne pourra pas atteindre le CDN de Purple ni les fournisseurs de connexion sociale.Revenez à la section Access Control pour votre SSID invité. Définissez le Walled garden sur Walled garden is enabled. Dans le champ Walled garden ranges, vous devez ajouter les éléments suivants. Premièrement, les domaines de la plateforme Purple : star dot purple dot ai et star dot venuewifi dot com. Deuxièmement, les domaines CDN que Purple utilise pour diffuser les ressources du portail : star dot cloudfront dot net et star dot akamaihd dot net. Troisièmement, l'infrastructure de redirection Meraki : star dot network-auth dot com. Quatrièmement, si vous proposez des options de connexion via les réseaux sociaux, vous devez ajouter les domaines OAuth correspondants. Pour Google : accounts dot google dot com, star dot googleapis dot com, star dot gstatic dot com. Pour Facebook : star dot facebook dot com, star dot fbcdn dot net et connect dot facebook dot net. Pour Twitter ou X : star dot twitter dot com et star dot twimg dot com. Une remarque importante sur la façon dont Meraki gère les domaines génériques (wildcards) dans le walled garden. Meraki prend en charge les entrées génériques à l'aide du préfixe astérisque, par exemple star dot cloudfront dot net. Cependant, il s'agit d'une correspondance basée sur le DNS — Meraki résout le domaine et autorise les adresses IP qui en résultent. Cela signifie que pour les fournisseurs de CDN comme CloudFront ou Akamai, où les adresses IP résolues peuvent changer fréquemment, vous devez utiliser le domaine générique plutôt que des plages d'adresses IP statiques. Les entrées d'IP statiques conviennent parfaitement pour les points de terminaison RADIUS de Purple, qui sont stables, mais pas pour le trafic CDN. Parlons maintenant de deux scénarios réels sur lesquels j'ai travaillé directement. Le premier concerne un hôtel de 350 chambres au Royaume-Uni. Le client utilisait des points d'accès Meraki MR46 répartis sur trois bâtiments, avec environ 400 appareils invités connectés simultanément aux heures de pointe. Le déploiement initial utilisait une page d'accueil de type clic-clic — sans RADIUS, juste une acceptation des conditions d'utilisation. Le problème était qu'ils n'avaient aucune visibilité sur l'identité des personnes connectées, aucune collecte d'e-mails et aucun moyen de mener des campagnes marketing après le séjour. Nous les avons migrés vers Purple avec une authentification basée sur RADIUS. La configuration était simple, mais le piège résidait dans le fait que leur pare-feu en amont bloquait le trafic UDP sortant sur le port 1812 vers tout ce qui se trouvait en dehors du sous-réseau local. Une fois que nous avons ajouté les plages d'adresses IP du tableau de bord Meraki à la liste d'autorisation du pare-feu, l'authentification a fonctionné immédiatement. Après le déploiement, l'hôtel a collecté les adresses e-mail d'environ 68 % des invités connectés au cours du premier mois, et leur équipe marketing a mené une campagne de réengagement qui a généré une hausse mesurable des réservations directes. Le second scénario concerne une chaîne de vente au détail de 45 magasins, chacun équipé de points d'accès Meraki MR33. Le défi résidait ici dans l'échelle et la cohérence. Configurer manuellement 45 SSID avec les paramètres RADIUS et les listes de walled garden appropriés aurait été source d'erreurs et chronophage. La solution a consisté à utiliser la configuration basée sur les modèles de Meraki. Nous avons créé un modèle de réseau unique avec les paramètres de SSID, RADIUS et walled garden appropriés, puis nous avons lié les réseaux des 45 magasins à ce modèle. Tout changement — par exemple, l'ajout d'un nouveau fournisseur de connexion sociale au walled garden — est effectué une seule fois dans le modèle et se propage automatiquement à tous les magasins. Les analyses de Purple ont ensuite agrégé les données de fréquentation et de temps de séjour de tous les magasins, offrant à l'équipe des opérations de vente au détail une vue unique sur tableau de bord du comportement des visiteurs par magasin, par région et par heure de la journée. Laissez-moi vous donner trois règles d'or qui vous feront gagner du temps sur chaque déploiement de Captive Portal Meraki. Règle numéro un : vérifiez toujours les plages d'adresses IP du tableau de bord Meraki avant de configurer RADIUS. Ces plages changent occasionnellement, et si votre pare-feu les bloque, l'authentification échouera de manière invisible pour l'utilisateur — il verra simplement la page du portail se figer. Utilisez l'outil de test RADIUS intégré dans le tableau de bord sous Contrôle d'accès pour vérifier la connectivité avant la mise en service. Règle numéro deux : utilisez des domaines génériques (wildcards) dans le walled garden, et non des plages d'adresses IP, pour tout contenu hébergé sur un CDN. Les plages d'adresses IP des CDN sont vastes et changent fréquemment. Une entrée de domaine générique est plus facile à maintenir et plus fiable. Règle numéro trois : activez la comptabilité RADIUS sur le port 1813, même si vous pensez ne pas en avoir encore besoin. Les données de session sont précieuses pour résoudre les problèmes de déconnexion et pour alimenter votre plateforme d'analyse avec des mesures précises du temps de séjour. Cela ne coûte rien à activer et est très difficile à intégrer après coup. À présent, voici quelques questions rapides que l'on me pose régulièrement. Puis-je utiliser la page d'accueil intégrée de Meraki au lieu de Purple ? Oui, mais vous perdez la capture de données, les analyses, l'automatisation du marketing et la gestion des consentements conforme au GDPR. La page d'accueil intégrée convient pour un simple clic d'accès, mais ce n'est pas une plateforme d'intelligence client. Cette configuration fonctionne-t-elle sur les pare-feux Meraki MX ainsi que sur les points d'accès MR ? La configuration de la page d'accueil RADIUS est prise en charge sur les points d'accès MR. Les appliances MX gèrent l'authentification VPN client différemment. Pour le WiFi invité spécifiquement, vous configurez les SSID MR. Qu'en est-il du WPA3 ? Les points d'accès Meraki MR prennent en charge le WPA3 sur les SSID d'entreprise. Pour les déploiements de Captive Portal invités, le SSID est généralement ouvert (Open), le WPA3 ne s'applique donc pas directement. Cependant, si vous déployez un SSID Passpoint ou OpenRoaming aux côtés de votre SSID de Captive Portal — ce que Purple prend en charge — ce SSID utilise le WPA3-Enterprise avec 802.1X, et c'est là que le WPA3 devient pertinent. Pour résumer : l'intégration de Cisco Meraki et Purple est éprouvée et fiable, mais elle nécessite une attention particulière sur trois points : le routage IP source RADIUS, l'exhaustivité du walled garden et la configuration de l'expiration de session. Maîtrisez ces trois aspects et le déploiement se fera sans encombre. L'intérêt commercial est évident : les établissements qui déploient une plateforme de guest WiFi correctement configurée avec capture de données constatent systématiquement des retours mesurables en matière d'engagement marketing et d'analyse opérationnelle. Si vous souhaitez approfondir le sujet, consultez le guide de Purple sur l'implémentation de l'authentification 802.1X avec cloud RADIUS, ainsi que notre guide de déploiement des AP Cisco Wireless sur le blog de Purple. Les deux liens figurent dans les notes de l'émission. Merci pour votre écoute. Si vous avez un scénario de déploiement spécifique que vous aimeriez nous voir aborder, contactez l'équipe technique de Purple. À bientôt pour le prochain épisode.