Fortinet FortiAP et WiFi invité : configuration du Captive Portal avec Purple

Bienvenue dans cette présentation de l'architecture de Purple. Aujourd'hui, nous plongeons au cœur d'une intégration essentielle pour les réseaux d'entreprise : le déploiement de Purple WiFi aux côtés de l'infrastructure Fortinet, plus précisément avec les points d'accès FortiAP et les pare-feu FortiGate. Que vous soyez responsable informatique, architecte réseau ou CTO gérant un site - qu'il s'agisse d'une chaîne de magasins, d'un stade ou d'un hôpital - cette session est conçue pour vous fournir le plan d'action concret permettant de faire fonctionner ces deux puissantes plateformes en parfaite synergie. Situons le contexte. Fortinet est réputé pour sa posture de sécurité robuste. Les appliances FortiGate de gestion unifiée des menaces offrent une inspection approfondie du trafic de couche 7. Cependant, lorsqu'il s'agit de WiFi invité, vous ne recherchez pas seulement la sécurité, vous voulez de la valeur commerciale. Vous voulez capturer des données démographiques, comprendre le comportement des visiteurs et stimuler le retour sur investissement marketing. C'est là que Purple intervient. En intégrant Purple en tant que Captive Portal externe, vous déléguez la gestion complexe de l'identité des invités, du consentement GDPR et des connexions sociales au RADIUS cloud de Purple, tout en laissant le FortiGate faire ce qu'il fait de mieux : sécuriser le périmètre. Alors, comment cela fonctionne-t-il concrètement sous le capot ? Passons à l'analyse technique approfondie. L'architecture repose sur les protocoles standards RADIUS et la redirection HTTP. Lorsqu'un appareil invité s'associe à votre SSID invité ouvert diffusé par le FortiAP, le FortiGate intercepte cette requête web initiale. Au lieu de proposer une page de portail basique stockée localement, le FortiGate redirige le client vers la page de démarrage hébergée sur le cloud de Purple. Voici maintenant le concept clé : le Walled Garden. Durant cette phase de pré-authentification, l'invité n'a pas accès à internet. Cependant, il doit charger les éléments graphiques du portail et peut avoir besoin de rejoindre Facebook ou Google pour s'authentifier. Le Walled Garden est une liste d'autorisation stricte configurée sur le FortiGate qui autorise le trafic vers ces domaines spécifiques. Une fois que l'utilisateur s'est authentifié, la plateforme de Purple renvoie un message RADIUS Access-Accept au FortiGate. Le FortiGate bascule alors l'état de la session en "authentifié" et applique à l'utilisateur vos règles de pare-feu post-authentification. Parlons plus en détail de la configuration RADIUS, car c'est ici que la précision est de rigueur. Purple vous fournit deux ensembles d'identifiants RADIUS : un pour l'authentification sur le port 1812, et un pour l'accounting sur le port 1813. Les deux doivent être configurés. Le serveur d'accounting n'est pas optionnel. C'est le mécanisme par lequel le FortiGate signale les données de session à Purple - durée, bande passante consommée et événements de fin de session. Sans données d'accounting précises, votre tableau de bord analytique Purple affichera des indicateurs de visiteurs incomplets ou inexacts. Configurez votre intervalle d'accounting intermédiaire sur 120 secondes. Cela offre un bon équilibre entre visibilité en temps réel et charge réseau.Un scénario très courant implique FortiAuthenticator. De nombreuses entreprises utilisent FortiAuthenticator pour le WiFi de leur personnel - en utilisant 802.1X et PEAP pour authentifier les appareils d'entreprise par rapport à Active Directory. La question est toujours : puis-je conserver mon FortiAuthenticator pour le personnel et utiliser Purple pour les invités ? La réponse est absolument oui, et la règle d'or ici est une ségrégation stricte. Vous conservez votre SSID pour le personnel pointant vers le FortiAuthenticator. Vous créez un SSID ouvert, complètement distinct pour les invités, pointant vers le Captive Portal externe et le cloud RADIUS de Purple. Le FortiGate achemine les demandes d'authentification en fonction du SSID. L'identité du personnel reste sur site avec le FortiAuthenticator. L'identité des invités va vers le cloud marketing de Purple. Zéro croisement, sécurité maximale. Cette architecture présente également un avantage de conformité important. Selon les exigences PCI-DSS, les réseaux WiFi invités doivent être complètement isolés de tout segment de réseau qui traite les données des titulaires de cartes. En plaçant le SSID invité sur un VLAN dédié et en appliquant des politiques de pare-feu strictes sur le FortiGate pour bloquer toutes les destinations d'espace IP privé RFC 1918, vous répondez proprement à cette exigence. Passons maintenant aux recommandations de mise en œuvre. Lorsque vous configurez cela, vous avez une décision cruciale à prendre concernant l'attribution des adresses IP : le mode NAT par rapport au mode Bridge. Si vous déployez une petite succursale de vente au détail avec peut-être cinquante à cent connexions d'invités simultanées, le mode NAT est parfaitement adéquat. Le FortiGate distribue des adresses DHCP aux invités à partir d'un sous-réseau interne dédié et les traduit lorsque le trafic sort du pare-feu. C'est simple et nécessite une infrastructure supplémentaire minimale. Mais si vous déployez un environnement à haute densité - par exemple, un hôtel de cinq cents chambres, un centre de conférence accueillant plusieurs événements simultanés ou un stade - vous devez utiliser le mode Bridge. En mode Bridge, le FortiAP envoie le trafic invité directement sur un VLAN dédié, permettant à vos serveurs DHCP d'entreprise principaux de gérer la charge. Cela évite que le FortiGate ne devienne un goulot d'étranglement DHCP lors des pics de connexion. Le mode Bridge garantit également que la plateforme Purple voit la véritable adresse IP du client, ce qui est vital pour des analyses et un dépannage précis. Parlons de la séquence de configuration étape par étape, car l'ordre est important ici. Commencez dans le portail Purple. Récupérez vos identifiants de serveur RADIUS - les adresses IP du serveur, les secrets partagés, l'URL du Captive Portal et l'URL de redirection. Ce sont les quatre informations critiques dont vous avez besoin avant de toucher à la configuration Fortinet. Ensuite, accédez au tableau de bord FortiCloud ou à votre interface de gestion FortiGate. Définissez d'abord vos serveurs RADIUS - authentification sur 1812, accounting sur 1813. Créez ensuite votre SSID invité, définissez l'authentification sur Ouvert, activez le Captive Portal externe et saisissez l'URL du portail Purple et l'URL de redirection. Configurez votre Walled Garden. Et enfin, définissez votre politique de pare-feu post-authentification avec vos profils UTM. Qu'en est-il des pièges à éviter ? Où les déploiements échouent-ils généralement ? Le problème numéro un, sans conteste, est un Walled Garden incomplet. Si un invité se connecte et obtient un écran vide ou un délai d'attente dépassé, cela signifie presque toujours que le FortiGate bloque l'accès aux fichiers CSS, aux scripts JavaScript ou aux API de connexion sociale de Purple avant l'authentification. Vous devez vous assurer que chaque domaine requis est explicitement autorisé dans cette politique de pré-authentification. Purple fournit une liste complète des domaines requis - utilisez-la dans son intégralité. De plus, n'oubliez pas le DNS. Les clients non authentifiés doivent être autorisés à résoudre les requêtes DNS, sinon la redirection ne fonctionnera pas. L'appareil doit résoudre le nom d'hôte du portail Purple avant même de tenter de charger la page. Le deuxième piège le plus courant concerne les erreurs de certificat. Assurez-vous que votre FortiGate présente un certificat SSL valide et publiquement approuvé pour l'interface de redirection. Si vous utilisez le certificat auto-signé par défaut, les iPhones et appareils Android récents afficheront d'importants avertissements de sécurité, et vos invités abandonneront complètement la connexion. C'est un problème particulièrement aigu dans les environnements hôteliers où l'expérience client est primordiale. Le troisième piège réside dans les erreurs de délai d'attente RADIUS. Si le portail se charge mais que l'authentification échoue systématiquement, vérifiez que les secrets partagés correspondent exactement entre votre configuration FortiGate et le portail Purple. Une différence d'un seul caractère entraînera l'échec silencieux de toutes les tentatives d'authentification. Vérifiez également qu'aucun pare-feu intermédiaire ne bloque les ports UDP 1812 et 1813 entre votre infrastructure Fortinet et les serveurs cloud RADIUS de Purple. Terminons par une session rapide de questions - réponses basée sur les questions les plus fréquentes de nos clients. Question un : l'utilisation de Purple contourne-t-elle mes politiques de sécurité FortiGate ? Absolument pas. Purple gère l'authentification et la capture d'identité. Une fois authentifié, tout le trafic invité passe par la politique post-authentification de votre FortiGate. C'est précisément là que vous appliquez le filtrage web FortiGuard, bloquez le trafic peer-to-peer et limitez la bande passante. Voyez les choses ainsi : la pré-authentification est permissive pour permettre la connexion ; la post-authentification est restrictive pour protéger le réseau. Question deux : dois-je déployer des serveurs RADIUS locaux ? Non. Purple fournit un service de RADIUS-as-a-Service. Vous configurez le FortiGate pour qu'il pointe directement vers les adresses IP cloud RADIUS de Purple. Il n'est pas nécessaire de déployer et de maintenir FreeRADIUS, Windows NPS ou toute autre infrastructure RADIUS locale pour le réseau WiFi invités. Question trois : Purple peut-il fonctionner avec FortiWLM ? Oui. L'approche d'intégration est cohérente - configurez l'URL du Captive Portal externe, les identifiants du serveur RADIUS et le walled garden au sein du contrôleur FortiWLM, en suivant la même séquence logique que la configuration du FortiGate. Quatrième question : qu'en est-il de la conformité au GDPR ? Purple recueille un consentement explicite au niveau du portail, en présentant vos conditions générales et vos avis de traitement des données avant l'authentification. Ces données de consentement sont stockées au sein de la plateforme Purple et sont auditables. Le rôle du FortiGate est purement d'appliquer les règles réseau - il n'a pas besoin de gérer directement les données de consentement. Pour résumer les points clés de la présentation d'aujourd'hui. Premièrement : ségréguez absolument vos SSIDs pour le personnel et les invités. Le personnel sur FortiAuthenticator avec 802.1X. Les invités sur Purple avec un Captive Portal externe. Deuxièmement : configurez méticuleusement votre Walled Garden. C'est le point de défaillance le plus courant et l'élément de configuration de pré-authentification le plus important. Troisièmement : utilisez le mode Bridge pour tout déploiement à haute densité afin d'éviter les goulots d'étranglement DHCP et de garantir une visibilité précise de l'adresse IP du client. Quatrièmement : configurez à la fois les serveurs d'authentification et de comptabilité (accounting) RADIUS. La comptabilité n'est pas facultative si vous souhaitez obtenir des analyses significatives. Cinquièmement : exploitez les fonctionnalités UTM de Fortinet après l'authentification. Le filtrage web, le contrôle des applications et la régulation de la bande passante doivent tous être appliqués dans la politique de pare-feu post-authentification. En exécutant correctement cette intégration, vous transformez le WiFi invité d'un centre de coûts en un actif conforme, sécurisé et générateur de revenus. La combinaison de la profondeur de sécurité de Fortinet et de l'intelligence marketing de Purple est véritablement puissante pour tout exploitant de site qui souhaite prendre au sérieux l'expérience de ses invités et sa stratégie de données. Merci d'avoir écouté la présentation de l'architecture Purple. Si vous souhaitez discuter de vos besoins de déploiement spécifiques, visitez purple.ai pour vous entretenir avec l'équipe des solutions.