Redirection de port pour les contrôleurs WiFi : un guide de configuration
Ce guide fournit une référence technique pour les architectes réseau et les responsables informatiques sur la configuration de la redirection de port pour les contrôleurs WiFi sur site. Il aborde les cas où la redirection de port est nécessaire, les ports requis pour les principaux fournisseurs et la manière d'atténuer les risques de sécurité associés pour garantir un déploiement sécurisé et évolutif.
Video overview
Écouter ce guide
Voir la transcription du podcast
Fait partie de notre série principale : Guide de sécurité WiFi d'entreprise →
WiFi controller port forwarding & firewall rule architect
Generate vendor-specific firewall ACL rules and NAT port forward configurations for enterprise Wireless LAN Controllers (WLCs). Assess inbound exposure risks across CAPWAP and RADIUS, and evaluate zero-trust Cloud RADIUS migration.
Centralized Cisco Catalyst 9800 WLC in core data center terminating CAPWAP tunnels from remote campus buildings and external branches over WAN.
| Proto | Port | Service description | Direction | Risk |
|---|---|---|---|---|
| UDP | 5246 | CAPWAP Control Plane (RFC 5415) AP discovery, DTLS session setup, and controller keepalive heartbeats. | Bi-directional | Medium |
| UDP | 5247 | CAPWAP Data Plane (RFC 5416) Encapsulates client wireless payload when operating in centralized tunnel mode. | Bi-directional | Low |
| UDP | 1812 | RADIUS 802.1X Authentication (RFC 2865) Passes EAP authentication payloads between access points and internal RADIUS servers. | Inbound | Medium |
| UDP | 1813 | RADIUS Accounting (RFC 2866) Reports session start, stop, interim packet counters, and bandwidth consumption. | Inbound | Low |
| TCP | 8443 / 443 | External Captive Portal WebAuth Redirection Accepts captive portal splash page redirections and browser authentication callbacks. | Inbound | Low |
| UDP | 161 / 514 | SNMP Traps & Syslog Event Forwarding Transfers network health statistics and operational error alerts to centralized monitoring platforms. | Inbound | Medium |
! Cisco Catalyst 9800 IOS-XE / Perimeter Firewall Access Control ! ! Step 1: WAN access-list for inbound WLC services. ! The destination here is the PUBLIC address, not the controller's inside ! address: an inbound ACL on the outside interface is evaluated BEFORE the ! outside-to-inside NAT translation, so matching 10.100.20.10 drops exactly ! the traffic these lines mean to permit. ! Replace BRANCH-SUBNET with each remote site's public prefix wherever the ! remote APs have static addressing - 'any' is a last resort. ip access-list extended ACL-WAN-TO-WLC permit udp any host 198.51.100.25 eq 5246 ! CAPWAP control permit udp any host 198.51.100.25 eq 5247 ! CAPWAP data permit udp any host 198.51.100.25 eq 1812 ! RADIUS auth permit udp any host 198.51.100.25 eq 1813 ! RADIUS acct ! RadSec disabled permit tcp any host 198.51.100.25 eq 8443 ! Captive WebAuth ! Management GUI blocked from the public WAN deny ip any host 198.51.100.25 log-input ! Step 2: bind the list, or nothing above takes effect interface GigabitEthernet0/0/1 ip access-group ACL-WAN-TO-WLC in ! Step 3: static destination NAT (edge router / ASA) ip nat inside source static udp 10.100.20.10 5246 198.51.100.25 5246 extendable ip nat inside source static udp 10.100.20.10 5247 198.51.100.25 5247 extendable ip nat inside source static udp 10.100.20.10 1812 198.51.100.25 1812 extendable ip nat inside source static udp 10.100.20.10 1813 198.51.100.25 1813 extendable ! Step 4: MTU clamping on the WAN interface to prevent CAPWAP fragmentation interface GigabitEthernet0/0/1 ip mtu 1460 ip tcp adjust-mss 1360
Synthèse décisionnelle
Pour les entreprises gérant le WiFi sur plusieurs sites avec un contrôleur LAN sans fil (WLC) sur site, une connectivité sécurisée et fiable est une préoccupation opérationnelle majeure. Lorsque les points d'accès (AP) sont situés dans des filiales distantes, séparés du contrôleur central par internet, une méthode pour permettre leur communication est requise. Ce guide traite de l'utilisation de la redirection de port (NAT entrant) comme méthode de communication. Nous explorerons le cadre décisionnel essentiel pour savoir quand utiliser la redirection de port par rapport à des alternatives plus sécurisées comme les VPN ou les architectures gérées dans le cloud. Ce document fournit un aperçu indépendant des fournisseurs concernant les ports essentiels requis pour les tunnels CAPWAP, l'accès de gestion et les services d'authentification, y compris les listes de ports spécifiques pour les contrôleurs Cisco, Ruckus, et Ubiquiti. De plus, nous détaillons les risques de sécurité importants - de l'élargissement de la surface d'attaque aux violations de conformité sous PCI-DSS et GDPR - et fournissons des bonnes pratiques concrètes pour l'atténuation des risques. Cela comprend la configuration des règles de pare-feu, la segmentation du réseau dans une DMZ, et le principe du moindre privilège. L'objectif est de doter les architectes réseau et les directeurs informatiques des connaissances nécessaires pour mettre en œuvre une architecture WiFi multi-site robuste, sécurisée et performante qui soutient les objectifs de l'entreprise sans compromettre l'intégrité du réseau.
Analyse technique approfondie
Le protocole fondamental pour les architectures WiFi centralisées modernes est le protocole Control and Provisioning of Wireless Access Points (CAPWAP), normalisé dans l'RFC 5415 [1]. Le CAPWAP permet à un WLC de gérer et de contrôler un parc d'AP, créant ainsi une structure réseau unifiée. Le protocole est conçu pour traverser les routeurs et les pare-feu, ce qui le rend adapté aux déploiements multi-sites. La communication s'effectue via deux canaux UDP principaux :
- Contrôle CAPWAP (UDP 5246) : Ce canal est utilisé pour toutes les fonctions de gestion et de contrôle entre l'AP et le WLC. Cela inclut le déploiement des configurations, les mises à jour de firmware et la surveillance de l'état. Conformément à la norme, ce canal de contrôle est obligatoirement sécurisé à l'aide du chiffrement Datagram Transport Layer Security (DTLS), fournissant un tunnel sécurisé pour les commandes de gestion.
- Données CAPWAP (UDP 5247) : Dans les déploiements où le trafic client est acheminé par tunnel vers le contrôleur (par opposition à un pontage local au niveau de l'AP), ce canal transporte les données utilisateur encapsulées. Bien que le chiffrement de ce canal soit facultatif dans la norme, les bonnes pratiques exigent qu'il soit également sécurisé par DTLS afin de protéger les données des clients en transit.
Lorsqu'un AP est derrière un équipement NAT, il découvre l'adresse IP publique du WLC (souvent via DNS ou une option DHCP) et initie une connexion CAPWAP. Le pare-feu situé devant le WLC doit être configuré avec des règles de redirection de port pour diriger ces paquets UDP entrants vers l'adresse IP privée du contrôleur.
Au-delà du protocole CAPWAP de base, plusieurs autres ports sont nécessaires pour un déploiement entièrement fonctionnel :
- Accès de gestion : Les administrateurs ont besoin d'accéder à l'interface de gestion du contrôleur. Cela est généralement fourni via HTTPS (TCP 443 ou, sur certaines plateformes comme Ruckus et Ubiquiti, TCP 8443). Secure Shell (TCP 22) fournit un accès CLI. L'exposition de ces ports sur Internet est une préoccupation de sécurité majeure et l'accès doit être fortement restreint.
- Authentification (AAA) : Pour une sécurité de classe entreprise utilisant WPA2/WPA3-Enterprise, le WLC doit communiquer avec un serveur RADIUS. Cela nécessite le UDP 1812 (Authentification) et le UDP 1813 (Accounting). Si le serveur RADIUS est externe au réseau local, ces ports doivent être redirigés.
- Portails Invités & Captive Portals : Si un Captive Portal est utilisé pour l'accès invité, le WLC doit pouvoir communiquer avec lui. Pour les portails externes comme Purple, cela signifie souvent autoriser le trafic HTTPS entrant depuis les serveurs du portail vers le contrôleur pour traiter l'authentification et les informations de session.
Exigences de ports spécifiques aux constructeurs
Bien que CAPWAP soit un standard, les constructeurs implémentent des ports supplémentaires pour des fonctionnalités spécifiques. Le tableau ci-dessous résume les ports par défaut courants pour les principales plateformes de contrôleurs sur site. Il n'est pas exhaustif et vous devez consulter la documentation la plus récente de votre constructeur.
| Constructeur/Plateforme | Protocole | Port | Objectif |
|---|---|---|---|
| Cisco WLC | UDP | 5246/5247 | Contrôle/Données CAPWAP |
| TCP | 443 | Gestion HTTPS | |
| EoIP | 97 | Tunnels de Mobilité/Ancre | |
| UDP | 16666 | Mobilité (Non sécurisée) | |
| Ruckus SmartZone | UDP | 12223 | Découverte LWAPP |
| TCP | 91/443 | Mise à niveau du firmware de l'AP | |
| TCP | 8443 | Interface Web HTTPS | |
| TCP | 22 | Gestion SSH | |
| Ubiquiti UniFi | TCP | 8080 | Information de l'équipement (Device Inform) |
| TCP | 8443 | Interface Web HTTPS/API | |
| UDP | 3478 | STUN (Traversée NAT) | |
| UDP | 10001 | Découverte d'AP |
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.
Guide d'implémentation
L'implémentation de la redirection de port pour un WLC nécessite une approche méthodique axée sur la sécurité. L'objectif est de permettre la connectivité des AP à distance tout en exposant le strict minimum nécessaire sur Internet.
Étape 1 : Architecture & Placement Réseau
La décision la plus critique concerne l'emplacement du WLC. Il ne doit jamais être placé sur le LAN d'entreprise de confiance. La meilleure pratique consiste à créer un segment de réseau dédié, ou zone démilitarisée (DMZ), pour le contrôleur. Cela isole le WLC et garantit que même s'il était compromis, l'attaquant n'aurait pas d'accès direct au réseau interne de l'entreprise. La politique du pare-feu doit ensuite être configurée pour contrôler strictement le trafic entre la DMZ, internet et le LAN de confiance.
Étape 2 : Configuration du pare-feu
- Créer des règles de NAT et de redirection de port : Pour chaque port requis, créez une règle de NAT de destination (DNAT) qui traduit l'adresse IP publique du pare-feu et le port externe vers l'adresse IP privée du WLC dans la DMZ et le port interne correspondant.
- Créer des règles d'accès entrant : C'est l'étape de sécurité la plus importante. Créez des règles de pare-feu pour autoriser le trafic vers les ports redirigés, mais spécifiez toujours l'adresse IP source. Pour les ports CAPWAP, la source doit être les adresses IP publiques de vos sites distants. Pour les ports d'administration (HTTPS/SSH), la source doit être restreinte à une liste blanche d'adresses IP de confiance, comme votre bureau d'entreprise ou un serveur de rebond d'administration dédié.
Avertissement de sécurité : Une erreur courante et dangereuse consiste à laisser l'adresse source sur « Any » ou « 0.0.0.0/0 ». Cela expose l'interface d'administration de votre contrôleur à l'ensemble d'internet, invitant aux attaques par force brute.
- Bloquer les protocoles inutiles : Créez explicitement des règles qui refusent tout autre trafic vers l'IP publique du WLC. De plus, assurez-vous que les protocoles non sécurisés comme Telnet (TCP 23) et TFTP (UDP 69) sont désactivés sur le contrôleur lui-même et bloqués au niveau du pare-feu.
- Activer l'inspection d'état (Stateful Inspection) : Assurez-vous que votre pare-feu fonctionne en mode dynamique (stateful). Cela signifie qu'il suit l'état des connexions et refusera automatiquement les paquets entrants non sollicités qui ne font pas partie d'une session reconnue.
Étape 3 : Configuration du contrôleur
Sur le WLC, assurez-vous que l'adresse IP publique du pare-feu est configurée comme interface principale ou adresse NAT du contrôleur. Cela permet au contrôleur de construire correctement les réponses CAPWAP afin qu'elles puissent être routées vers les AP. Assurez-vous que les fonctionnalités telles que le chiffrement DTLS pour CAPWAP sont activées.
Bonnes pratiques
- Préférer les alternatives : L'approche la plus sécurisée consiste à éviter la redirection de port directe. Si possible, implémentez un VPN de site à site entre les sites distants et le centre de données du contrôleur. Cela encapsule tout le trafic dans un tunnel sécurisé, éliminant ainsi le besoin de ports exposés au public.
- Adoptez le Cloud : Pour les nouveaux déploiements ou les renouvellements de matériel, privilégiez fortement une solution WiFi gérée par le cloud (par exemple, Cisco Meraki, Ruckus One, Aruba Central). Ces plateformes sont conçues pour que les points d'accès initialisent des connexions sortantes vers le cloud, éliminant ainsi le besoin de règles de pare-feu entrantes et simplifiant la gestion.
- Audits réguliers : Comme l'exige la spécification PCI DSS 1.1.6, les ensembles de règles des pare-feu et des routeurs doivent être examinés au moins tous les six mois. Ce processus doit vérifier la justification commerciale de chaque règle et s'assurer qu'elles sont aussi restrictives que possible.
- Utilisez une authentification forte : Protégez les interfaces de gestion avec une authentification multifacteur (MFA) dans la mesure du possible. Utilisez des mots de passe forts et complexes, et changez-les régulièrement.
- Journalisation et surveillance : Transférez les journaux du pare-feu et du contrôleur vers un système SIEM (Security Information and Event Management) centralisé. Surveillez les tentatives de connexion anormales, les échecs de connexion répétés et les modèles de trafic inattendus.
Dépannage et atténuation des risques
Mode de défaillance courant : Les points d'accès ne parviennent pas à rejoindre le contrôleur
- Symptôme : Les points d'accès d'un site distant sont bloqués dans une boucle de découverte et n'apparaissent jamais dans le tableau de bord du contrôleur.
- Dépannage :
- Vérifiez la connectivité réseau de base entre le site distant et l'adresse IP publique du contrôleur (ping, traceroute).
- Consultez les journaux du pare-feu du côté du contrôleur. Voyez-vous les paquets UDP 5246 entrants provenant de l'IP publique du point d'accès ? Sont-ils autorisés ou rejetés ?
- Vérifiez que les règles de redirection de port/NAT sont correctement configurées pour l'IP privée du contrôleur.
- Assurez-vous qu'il n'y a pas un deuxième niveau de NAT sur le site distant (double NAT) qui pourrait interférer avec la connexion.
Risque : Compromission du contrôleur
- Scénario : Une vulnérabilité est découverte dans l'interface de gestion web du contrôleur, et votre règle de redirection de port pour TCP 443 a pour source « Tout ».
- Atténuation : Cela met en évidence l'importance critique de la restriction des IP sources. Si la source est limitée aux adresses IP de vos bureaux, la vulnérabilité n'est pas exploitable depuis l'internet public. C'est un exemple classique de défense en profondeur. D'autres mesures d'atténuation consistent à placer le contrôleur dans une DMZ pour limiter les déplacements latéraux de l'attaquant et à appliquer rapidement les correctifs de sécurité du fournisseur.
Risque : Non-conformité réglementaire
- Scénario : Un audit PCI DSS révèle que le contrôleur gère des points d'accès dans un magasin de détail qui traite les paiements par carte bancaire, et que le contrôleur n'est pas correctement segmenté de l'environnement des données de titulaires de cartes (CDE).
- Atténuation : La segmentation du réseau n'est pas négociable pour la conformité PCI DSS [2]. Le réseau sans fil utilisé par les terminaux de paiement doit être isolé de tous les autres réseaux, y compris le WiFi invité et le WiFi d'entreprise. Le contrôleur lui-même doit être considéré comme faisant partie du périmètre de l'audit s'il peut avoir un impact sur la sécurité du CDE. Pour le GDPR, les données du WiFi invité constituent des données personnelles, et la conception du réseau doit empêcher tout accès non autorisé à celles-ci [3].
ROI et impact commercial
Bien qu'il s'agisse d'un sujet technique, le choix de l'architecture WiFi a des implications commerciales directes. Un modèle de contrôleur sur site peut représenter des dépenses d'investissement importantes, mais il offre un contrôle granulaire et conserve toutes les données au sein de l'infrastructure de l'entreprise. Le coût opérationnel de ce modèle inclut le temps de personnel requis pour gérer, sécuriser et auditer la configuration du pare-feu et du contrôleur. Une faille de sécurité résultant d'un pare-feu mal configuré peut entraîner des pertes financières importantes, des dommages réputationnels et des amendes réglementaires.
En revanche, une solution gérée dans le cloud déplace le modèle de coût du CapEx vers l'OpEx (frais d'abonnement récurrents). Le ROI est réalisé grâce à la réduction des frais généraux informatiques - pas de matériel sur site à entretenir, pas de règles de pare-feu complexes à gérer pour l'accès au contrôleur, et un déploiement plus rapide des nouveaux sites. Pour de nombreuses entreprises distribuées comme les chaînes de vente au détail ou les groupes hôteliers, le coût total de possession (TCO) et l'amélioration de la posture de sécurité d'une plateforme gérée dans le cloud constituent un argument commercial convaincant, justifiant la migration depuis une architecture existante sur site.
-
Références
[1] IETF, RFC 5415: Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification, https://datatracker.ietf.org/doc/html/rfc5415 [2] PCI Security Standards Council, PCI DSS v4.0, https://www.pcisecuritystandards.org/document_library/ [3] Règlement Général sur la Protection des Données (GDPR), https://gdpr-info.eu/
Définitions clés
Redirection de port (NAT entrant)
Une configuration réseau qui redirige le trafic d'un port spécifique sur un pare-feu ou un routeur public vers un port spécifique sur un équipement privé au sein du réseau interne.
Les équipes informatiques utilisent cette méthode pour rendre un contrôleur WiFi sur site, qui possède une adresse IP privée, accessible aux points d'accès situés sur Internet.
CAPWAP (Control and Provisioning of Wireless Access Points)
Un protocole standard de l'IETF (RFC 5415) qui permet à un contrôleur central de gérer un ensemble de points d'accès sans fil. Il fonctionne via les ports UDP 5246 (contrôle) et 5247 (données).
Il s'agit du protocole fondamental qui facilite la communication entre les points d'accès et le contrôleur de réseau sans fil (WLC). Comprendre ses exigences en matière de ports est la première étape de la configuration du pare-feu.
DMZ (Zone démilitarisée)
Un segment de réseau périphérique isolé du réseau local interne de confiance d'une entreprise. Il est utilisé pour héberger des services accessibles au public et ajoute une couche de sécurité supplémentaire.
Placer un contrôleur WiFi dans une DMZ est une bonne pratique essentielle. Si le contrôleur est compromis, l'attaquant est confiné au sein de la DMZ et n'a pas d'accès direct au réseau de l'entreprise.
Pare-feu à inspection d'état (Stateful Firewall)
Un pare-feu qui suit l'état des connexions réseau actives et prend des décisions basées sur le contexte du trafic, et non uniquement sur des paquets individuels.
Un pare-feu à inspection d'état est essentiel pour une redirection de port sécurisée, car il n'autorisera le trafic de retour du WLC vers un point d'accès que s'il fait partie d'une session CAPWAP établie, empêchant ainsi le trafic entrant non sollicité.
PCI-DSS
La norme PCI-DSS (Payment Card Industry Data Security Standard) est un ensemble de normes de sécurité conçues pour garantir que toutes les entreprises qui acceptent, traitent, stockent ou transmettent des informations de carte de crédit maintiennent un environnement sécurisé.
Pour toute entreprise du secteur du commerce de détail ou de l'hôtellerie, s'assurer que l'architecture WiFi est conforme à la norme PCI-DSS est non négociable. Cela influence fortement les décisions relatives à la segmentation du réseau et à la configuration du pare-feu.
RADIUS (Remote Authentication Dial-In User Service)
Un protocole client/serveur qui fournit une gestion centralisée de l'authentification, de l'autorisation et de la comptabilité (AAA) pour les utilisateurs qui se connectent et utilisent un service réseau.
Dans le WiFi d'entreprise, RADIUS est utilisé pour activer la sécurité WPA2/WPA3-Enterprise (802.1X). Le WLC agit comme un client RADIUS, et les règles de pare-feu doivent lui permettre de communiquer avec le serveur RADIUS sur les ports UDP 1812 et 1813.
WiFi géré dans le cloud
Une architecture WiFi dans laquelle les points d'accès sont gérés par une plateforme de contrôle hébergée dans le cloud par le constructeur (par exemple, Cisco Meraki, Aruba Central).
Cette architecture est une alternative directe aux contrôleurs sur site. Elle simplifie le déploiement et élimine le besoin de redirection de port, car les points d'accès initient des connexions sortantes vers le cloud, ce qui constitue une posture par défaut plus sécurisée.
Autorisation d'IP sources (Whitelisting)
La pratique consistant à configurer une règle de pare-feu pour autoriser uniquement le trafic provenant d'une liste spécifique et pré-approuvée d'adresses IP sources.
Il s'agit du contrôle de sécurité le plus important lors de la redirection de port. Restreindre l'accès de gestion (HTTPS/SSH) à une liste blanche d'adresses IP de bureau ou de VPN réduit considérablement le risque d'accès non autorisé.
Exemples concrets
Un hôtel de 250 chambres doit fournir un accès WiFi invité et prendre en charge les appareils du personnel interne (tablettes du personnel de ménage, systèmes de point de vente). Ils disposent d'un Cisco 3504 WLC sur site dans leur salle serveurs et souhaitent garantir la conformité PCI DSS tout en offrant une expérience utilisateur fluide avec un portail captif Purple.
- Segmentation du réseau : Le WLC est placé dans un nouveau VLAN DMZ (par exemple, VLAN 100). Trois nouveaux réseaux sans fil sont créés : "GUEST_WIFI" (VLAN 101), "STAFF_CORP" (VLAN 102) et "POS_SECURE" (VLAN 103). Les règles de pare-feu sont configurées pour isoler complètement ces VLAN les uns des autres. Le réseau POS_SECURE est isolé d'internet, à l'exception du trafic vers le processeur de paiement.
- Pare-feu et redirection de port : Aucun port n'est redirigé depuis l'internet public vers le WLC. À la place, une règle est créée pour autoriser le trafic HTTPS entrant (TCP 443) uniquement depuis la plage d'adresses IP spécifique fournie par Purple pour leur service de portail captif. Cela permet au portail de communiquer avec le contrôleur pour autoriser les sessions des invités. Tout autre trafic entrant vers le WLC est bloqué.
- Conformité PCI DSS : Le WLAN "POS_SECURE" est configuré avec l'authentification WPA2-Enterprise et 802.1X. La politique du pare-feu garantit que ce segment de réseau est complètement isolé des réseaux des invités et du personnel de l'entreprise, répondant ainsi à la spécification PCI DSS 1.2.3. Le WLC lui-même est considéré comme faisant partie du périmètre et sécurisé conformément aux directives PCI.
Une chaîne de vente au détail de 50 magasins dispose d'un contrôleur Ruckus SmartZone central à son siège social. Chaque magasin possède entre 5 et 10 points d'accès (AP) qui doivent se connecter au contrôleur du siège via l'internet public. L'équipe informatique doit gérer le contrôleur à distance.
- Le VPN comme premier choix : La solution recommandée consiste à déployer un petit pare-feu/passerelle VPN dans chaque magasin pour créer un VPN IPsec de site à site vers le pare-feu du siège. Tout le trafic des AP est ensuite acheminé via le tunnel VPN sécurisé. Cela ne nécessite aucune redirection de port entrant au siège, ce qui en fait l'option la plus sécurisée.
- La redirection de port comme solution de secours : Si le VPN n'est pas réalisable pour des raisons de coût ou de contraintes techniques, une approche de redirection de port est utilisée. Au niveau du pare-feu du siège, des règles DNAT sont créées pour rediriger le port UDP 12223 (pour la découverte) et le port TCP 91/443 (pour le firmware) vers le contrôleur SmartZone. De manière cruciale, la source de ces règles est restreinte à une liste d'adresses IP publiques statiques des 50 magasins. Une règle distincte redirige le port TCP 8443 pour la gestion, avec une source restreinte à l'IP du bureau de l'équipe informatique.
- Configuration des AP : Les AP de chaque magasin sont configurés avec l'adresse IP publique du pare-feu du siège comme adresse de leur contrôleur. Ils initieront ensuite la connexion, qui sera redirigée vers le contrôleur SmartZone interne.
Questions d'entraînement
Q1. Vous déployez un nouveau réseau WiFi pour un centre de conférence. Le client souhaite utiliser Purple pour l'analyse des visiteurs et dispose déjà d'un Aruba Mobility Controller sur site. Quelle est la règle de pare-feu la plus critique à configurer pour permettre au Captive Portal de Purple de fonctionner ?
Conseil : Pensez au flux de communication. Le service externe doit communiquer avec le contrôleur interne. Quelles sont les adresses IP impliquées ?
Voir la réponse type
La règle la plus critique consiste à autoriser le trafic HTTPS entrant (TCP 443) depuis la plage d'adresses IP publiques spécifiques de Purple vers l'adresse IP publique du contrôleur Aruba. Vous devez obtenir cette plage d'adresses IP auprès de la documentation ou du support de Purple. Une règle ayant pour source « Any » (Tous) représenterait un risque majeur pour la sécurité. Vous créeriez ensuite une règle DNAT pour transférer ce trafic vers l'adresse IP interne du contrôleur dans la DMZ.
Q2. Un ingénieur réseau junior a configuré une redirection de port pour une nouvelle succursale à distance. Les AP sont en ligne, mais il vous indique qu'il a ouvert le port TCP 23 vers le contrôleur depuis l'adresse IP source « Any » pour « faciliter le dépannage ». Quel est le risque immédiat et quelle est votre consigne ?
Conseil : Le port TCP 23 est destiné à Telnet. Quelles sont les caractéristiques de sécurité de ce protocole ?
Voir la réponse type
Le risque immédiat est critique. Telnet est un protocole non chiffré, ce qui signifie que l'identifiant et le mot de passe du contrôleur sont envoyés en texte clair. Exposer cela à l'ensemble d'Internet rend le contrôleur hautement vulnérable au vol d'identifiants et à la compromission. La consigne est de désactiver immédiatement la règle de pare-feu, de désactiver le service Telnet sur le contrôleur lui-même et d'utiliser SSH (TCP 22) pour toute gestion en CLI, en limitant l'IP source à un réseau de gestion de confiance.
Q3. Votre directeur financier remet en question le coût de l'abonnement d'une solution WiFi gérée dans le cloud pour 100 nouveaux points de vente, affirmant que l'achat de contrôleurs sur site est un coût unique plus avantageux. Comment expliquez-vous le ROI de la solution cloud d'un point de vue sécuritaire et opérationnel ?
Conseil : Pensez au coût total de possession (TCO) et non pas uniquement au prix d'achat initial. Quel est le travail continu requis pour un déploiement sur site et multi-sites ?
Voir la réponse type
Le ROI d'une solution gérée dans le cloud dépasse le coût matériel initial. Sur le plan opérationnel, elle élimine la charge de travail importante requise pour configurer, gérer et auditer des règles de pare-feu et des VPN complexes pour 100 sites distincts. Cela accélère le déploiement et réduit les coûts de main-d'œuvre récurrents. Sur le plan de la sécurité, le modèle cloud présente un profil de risque fondamentalement plus faible. Il supprime le besoin de toute redirection de port entrant, réduisant considérablement la surface d'attaque du réseau et simplifiant la conformité aux normes telles que PCI-DSS. Le coût de l'abonnement externalise de fait la sécurité et la maintenance de la plateforme de gestion auprès du fournisseur, ce qui se traduit par un TCO inférieur et un réseau plus sécurisé et évolutif.
Questions fréquentes
When is port forwarding required for an enterprise WiFi controller?
Port forwarding is required when access points or branch switches located at external sites or home offices must communicate with an on-premises Wireless LAN Controller (WLC) located behind a network firewall or NAT boundary. Inbound NAT forwarding translates external WAN IP traffic to internal WLC interfaces for control tunnels and user traffic.
Which network ports are needed for CAPWAP controller communication?
CAPWAP (RFC 5415 and RFC 5416) requires two primary UDP ports: UDP 5246 for the control plane (discovery, DTLS management handshake, keepalives) and UDP 5247 for the data plane (tunneling client data frames in centralized switching mode). Legacy Cisco AireOS LWAPP implementations utilized UDP 12222 and 12223.
What are the security risks of forwarding ports to an on-premises WLC?
Opening inbound WAN ports exposes controller management interfaces to brute-force dictionary attacks, vulnerability scanning, and distributed denial-of-service (DDoS) packet floods. Exposing standard RADIUS ports (UDP 1812/1813) over the public internet exposes cleartext MD5 shared secrets to cryptographic offline cracking unless encapsulated in IPsec or RadSec.
How does MTU and packet fragmentation affect remote CAPWAP tunnels?
CAPWAP encapsulation adds a 44-byte outer header to every packet. When traversing WAN links with standard 1500-byte MTUs (or 1492-byte PPPoE links), frames exceed path MTU limits and undergo IP fragmentation. If intermediate firewalls drop fragmented UDP packets, access points suffer frequent DTLS retransmissions, association timeouts, and degraded throughput.
How does RadSec eliminate RADIUS port forwarding vulnerabilities?
RadSec (RFC 6614) encapsulates RADIUS authentication and accounting packets inside secure TCP port 2083 TLS 1.3 tunnels. RadSec provides mutual X.509 certificate authentication, eliminates fragile UDP packet loss over long-distance WAN connections, and protects credential hashes from eavesdropping without exposing open UDP ports.
How does Purple Cloud RADIUS eliminate the need for inbound port forwarding?
Purple Cloud RADIUS replaces on-premises authentication controllers with globally distributed cloud infrastructure. Access points establish secure outbound TLS connections to Purple endpoints, completely eliminating the need for inbound firewall pinholes, static public IP mapping, and fragile edge NAT port forwarding rules.
Continuer la lecture de cette série
Conformité CIPA : liste de contrôle de conformité pour les exploitants de sites
Vous serez en mesure de déterminer si la CIPA s'applique à votre WiFi, puis de segmenter les réseaux, d'acheminer le DNS via Purple Shield et de bloquer les voies de contournement. Vous saurez également quelles preuves conserver pour la certification du Form 486 ou du Form 479. La liste de contrôle attribue un responsable à chaque exigence, afin de garantir que rien ne manque pour la certification de votre prochaine année de financement.
Échecs de connexion en mode de transition WPA3 : une checklist de déploiement pour Cisco Meraki, HPE Aruba et Ruckus
Utilisez cette checklist pour diagnostiquer pourquoi des appareils échouent à se connecter sur un SSID en mode de transition WPA3 SAE et résoudre le problème sur Cisco Meraki, HPE Aruba ou Ruckus. Vous ferez correspondre les codes d'état 802.11 aux causes, isolerez les problèmes de PMF, 802.11r et 6GHz, et déciderez quand passer à un SSID WPA3 uniquement.
Le meilleur filtrage DNS : un guide complet pour les entreprises
Ce guide de référence technique explique comment le filtrage DNS d'entreprise sécurise les réseaux publics en bloquant les domaines malveillants au niveau de la couche de résolution - avant même qu'une connexion ne soit établie. Il fournit aux directeurs informatiques, architectes réseau et équipes d'exploitation des sites l'architecture de déploiement, la configuration du pare-feu et le contexte de conformité nécessaires pour protéger le WiFi invité dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public. Purple Shield bloque les logiciels malveillants, les botnets et les contenus inappropriés au niveau DNS sur plus de 80 000 sites actifs.
Vous avez des questions sur votre configuration spécifique ?
Notre équipe collabore avec des exploitants de sites, des responsables informatiques et des ingénieurs réseau au sein de 80 000 sites. Réservez un appel de 20 minutes et nous vous montrerons comment d'autres professionnels comme vous ont résolu ce problème.