Configurer et tester le Wi-Fi directement sur Sophos Firewall

Un réseau Wi-Fi géré directement sur Sophos Firewall se crée sous Wireless > Wireless networks. Le SSID ne suffit toutefois pas : le mode de trafic choisi détermine si les clients disposent de leur propre réseau, rejoignent le LAN du point d’accès ou sont bridgés vers un VLAN. DHCP, les règles de pare-feu, NAT et l’affectation à un point d’accès doivent ensuite être cohérents.

⚠️ Important : Ce guide s’applique uniquement au matériel Wi-Fi géré directement par Sophos Firewall. Les points d’accès AP6 ne peuvent pas être gérés par SFOS. Pour plusieurs AP6, Sophos Fusion (anciennement Sophos Central) constitue le mode de gestion prévu et recommandé ; un AP6 individuel peut également être configuré depuis son interface locale. Aujourd’hui, Firewall-managed Wireless concerne donc principalement les installations APX existantes, le LocalWiFi intégré des modèles de bureau W et les modules Wi-Fi pris en charge dans Sophos Firewall ou SD-RED. Le firmware des APX gérés par SFOS est fourni par les mises à jour des patterns du firewall et installé volontairement.

Ce guide utilise un réseau Wi-Fi invité avec Separate zone. Cet exemple est facile à comprendre, car le réseau client, les règles et les destinations autorisées peuvent être clairement séparés du LAN interne.

Si un réseau Wi-Fi 802.1X utilise RADIUS et que le pare-feu doit reconnaître les utilisateurs sans portail captif supplémentaire, RADIUS SSO avec accounting explique le chemin d’accounting distinct, la Framed-IP-Address nécessaire et le test sous Live users.

Procédure rapide :

Sous Wireless > Wireless settings, préparer Wireless Protection et la zone du point d’accès.
Accepter le point d’accès sous Wireless > Access points.
Sous Wireless > Wireless networks, créer le SSID, la sécurité et le réseau client.
Sous Network > DHCP ainsi que Rules and policies, compléter DHCP, la règle de pare-feu et NAT.
Affecter le Wireless Network au point d’accès, puis contrôler avec un client de test l’adresse IP, le DNS, la Rule ID ainsi que les accès internes indésirables.

Ce guide convient-il au point d’accès ?

SFOS 22 peut gérer les points d’accès de la série APX destinés à une utilisation en intérieur, le Wi-Fi intégré d’une XGS Appliance compatible et les modules d’extension Wi-Fi compatibles dans Sophos Firewall ou SD-RED. Pour les APX externes, cela concerne les modèles APX 120, APX 320, APX 530 et APX 740. Le modèle extérieur APX 320X et l’ancienne série AP ne sont pas gérés directement par une version actuelle de Sophos Firewall.

AP6 ne fait pas partie de cette procédure. AP6 se configure dans Sophos Fusion ou, pour un appareil individuel, depuis son interface locale. Pour la variante Fusion, consulter les exigences Sophos Central Wireless.

La fonction Wireless locale est incluse dans la Sophos Firewall Base License. Un point d’accès compatible est nécessaire séparément. APX a toutefois déjà atteint sa fin de commercialisation et atteindra sa fin de vie le 31 décembre 2027. Ce guide sert donc principalement à exploiter en toute sécurité les installations APX existantes. Pour une nouvelle plateforme Wi-Fi, il convient de planifier la migration d’APX vers AP6 liée à cette fin de vie ou d’envisager d’autres systèmes Wi-Fi actuels.

Limite de version : L’aide Wireless contient les procédures correspondantes aussi bien pour SFOS 22 que pour SFOS 23. Toutefois, l’existence d’une page d’aide SFOS 23 ne prouve pas qu’un modèle APX donné est pris en charge sur SFOS 23. La prise en charge du matériel doit être confirmée indépendamment à l’aide du Retirement Calendar et de la matrice de prise en charge. Avant une mise à niveau, vérifiez donc le modèle, la révision matérielle et le build cible dans la matrice de prise en charge ; ne migrez pas les APX existants vers SFOS 23 sur la seule base de ces instructions. Le WLAN intégré et les modules SD-RED doivent également correspondre au modèle et au build précis. Pour les nouveaux points d’accès externes, la procédure de gestion AP6 dont le lien figure ci-dessus s’applique, et non cette procédure SFOS-APX.

Pour relier un APX existant sans Ethernet par un APX câblé, configurer et tester Wireless Mesh sur Sophos Firewall explique l’AP racine, le canal, le backhaul masqué et la validation contrôlée.

SD-RED avec module Wi-Fi : L’aide Wireless documente DHCP option 234 pour la communication d’un module SD-RED utilisé comme point d’accès avec Sophos Firewall. Il ne s’agit ni du DHCP des clients du Wi-Fi invité, ni d’une exigence générale pour APX ou AP6. L’aide mentionne également Sophos UTM dans ce contexte ; cela ne constitue pas ici de nouvelles instructions d’installation UTM. Avant toute modification, clarifiez la compatibilité du module, le DHCP de gestion et le contrôleur réellement utilisé ; ne reprenez pas une valeur d’option d’un autre type d’appareil. La configuration SD-RED est la procédure distincte pour le raccordement du site.

Choisir le bon mode Client traffic

Le choix sous Client traffic est plus important que le nom du SSID. Il détermine si les clients se trouvent dans le même segment réseau local sur la couche 2, qui distribue les adresses IP et quel trafic passe effectivement par le pare-feu.

Separate zone

Separate zone crée une interface Wireless dédiée avec sa propre adresse IP ainsi qu’un tunnel VXLAN entre le point d’accès et le pare-feu. Les clients disposent de leur propre sous-réseau. Les accès peuvent ainsi être contrôlés par réseau Wi-Fi au moyen de règles WiFi-to-WAN ou WiFi-to-LAN ciblées. L’article Zones et interfaces de Sophos Firewall explique comment la zone, l’interface et l’objet réseau interagissent.

Ce mode convient bien aux invités, à l’IoT ou à d’autres réseaux qui doivent être séparés du LAN interne. Un hotspot avec Captive Portal, mot de passe journalier ou voucher nécessite également Separate zone. Configurer un hotspot Sophos Firewall présente la procédure complète avec la définition du voucher, le portail et la règle créée automatiquement.

VXLAN réduit la MTU utilisable. Avec de gros paquets, cela peut provoquer une fragmentation ou une baisse des performances. Il ne faut donc pas modifier préventivement la MTU selon une valeur forfaitaire. Il convient d’abord de vérifier si seuls les transferts volumineux échouent ou si des paquets TCP sont retransmis, c’est-à-dire si des Retransmits se produisent. La procédure contrôlée est décrite dans Contrôler la MTU et la MSS sur Sophos Firewall.

Bridge to AP LAN

Bridge to AP LAN place les clients Wi-Fi dans le même réseau que le point d’accès. Un serveur DHCP existant sur ce LAN distribue les adresses aux clients. Cette solution est pratique, mais elle ne crée pas de frontière réseau distincte pour les invités ou les appareils non fiables.

Le chemin des données est déterminant : une communication au sein du même sous-réseau peut circuler directement entre le client, le point d’accès et le switch, en contournant entièrement Sophos Firewall. Une règle de pare-feu sur SFOS ne peut contrôler que le trafic effectivement routé par le pare-feu.

Pour n’autoriser qu’une liste connue d’appareils sur le réseau sans fil intégré, créer une liste MAC sous Hosts and services > MAC host. Dans le réseau Wireless, sélectionner ensuite Allow list sous Advanced settings > MAC filtering et attribuer cette liste. La phrase secrète doit comporter entre 8 et 63 caractères. Pour la validation, connecter un appareil présent dans la liste et un autre qui n’y figure pas.

Une adresse MAC peut toutefois être usurpée. L’Allow list n’est donc qu’un filtre d’admission supplémentaire et ne remplace ni WPA2 Personal avec AES, ni une méthode WPA3 prise en charge, ni une phrase secrète robuste, ni une séparation réseau correcte.

Lorsque Bridge to AP LAN est utilisé avec LocalWiFi intégré, le réseau Wi-Fi doit également être relié au LAN câblé. La méthode appropriée dépend du modèle de XGS Appliance :

Gen.1 – XGS 87w, 107w, 116w, 126w et 136w : créer un bridge sous Network > Interfaces > Add interface > Add bridge. Name est le nom affiché, modifiable ultérieurement, qui accepte au maximum 58 caractères ; Hardware name accepte au maximum 10 caractères parmi A-Za-z0-9_ et ne peut plus être modifié après l’enregistrement. Sous Member interfaces, attribuer la zone WiFi à l’interface Wireless et la zone LAN au port Ethernet souhaité. D’autres ports Ethernet peuvent y être ajoutés si nécessaire.
Sélectionner ensuite IPv4 configuration, saisir l’IPv4 address prévue pour le bridge dans le LAN existant et choisir le masque de sous-réseau correspondant. L’adresse et le masque proviennent du plan d’adressage du LAN, et non du réseau invité Separate zone présenté plus loin. Avant Save, vérifier que l’adresse n’est attribuée ni à un autre appareil ni simultanément à une interface membre, et qu’elle ne se trouve pas sans réservation dans la plage DHCP dynamique. Ne pas modifier au passage la passerelle existante des clients ni le plan d’adressage DHCP. Avant la modification, vérifier la sauvegarde, les dépendances des ports et un accès d’administration indépendant ; la procédure de configuration d’un bridge explique ces contrôles communs et les noms matériels réservés. Son exemple de bridge transparent en ligne sans adresse IP correspond à un autre usage : cette procédure documentée pour LocalWiFi Gen.1 utilise une adresse IPv4 sur le bridge, mais tous les bridges n’ont pas besoin d’une adresse IP. Enregistrer avec Save uniquement après ces contrôles.
Gen.2 – XGS 88w, 108w, 118w et 128w : l’interface Wireless ne doit pas être membre d’un bridge physique. Activer plutôt Bridge to Ethernet sous Wireless > Access points > LocalWiFi > Advanced settings, sélectionner exactement un port Ethernet et définir la zone sur LAN.
Pour Bridge to Ethernet, le port physique sélectionné doit posséder une adresse IP et ne doit être ni un port WAN ni membre d’un autre pont. Une interface VLAN ne peut pas être reliée par un pont à LocalWiFi de cette manière ; la zone du pont ne doit pas non plus être WAN. La fonction s’applique uniquement à IPv4 et aux SSID de type Bridge to AP LAN. SFOS utilise le serveur DHCP existant du port du pont ; s’il n’existe pas, l’aide documente la création automatique d’un nouveau serveur. Avant l’enregistrement, vérifiez donc si un serveur DHCP est déjà présent sur le LAN, puis contrôlez le serveur, le pool et le bail pour éviter des réponses DHCP concurrentes. Lors de la désactivation, le pont est supprimé et la configuration est rétablie sur l’interface physique. Sauvegardez donc l’état initial au préalable et contrôlez le retour arrière, y compris l’accès administrateur, le DHCP du LAN et la connexion des clients, pendant une fenêtre de maintenance.

Un APX externe n’a pas besoin de ce bridge LocalWiFi supplémentaire. Lors d’un remplacement matériel, un bridge Wireless physique de Gen.1 ne peut pas non plus être repris tel quel sur Gen.2. Sauvegarde et restauration de Sophos Firewall explique la préparation nécessaire.

Bridge to AP LAN ne doit être choisi que si le Wi-Fi et le LAN câblé appartiennent délibérément à la même zone de sécurité.

Pour cette procédure LAN, enregistrer le Wireless Network avec Save après avoir choisi Bridge to AP LAN, les paramètres de sécurité et la liste MAC. Sous Wireless > Access points > LocalWiFi, vérifier le Country correct, puis attribuer précisément ce réseau sous Wireless networks > Add new item et enregistrer ; le Guest WiFi présenté plus loin est un exemple distinct. Après la configuration du bridge, l’appareil de test inscrit dans la liste doit pouvoir se connecter et celui qui n’y figure pas doit être refusé. Sur le client autorisé, vérifier un bail dans la plage LAN prévue, le masque correspondant, la passerelle existante et les serveurs DNS prévus ; contrôler le bail sur le serveur DHCP réellement responsable du LAN. Tester la résolution de noms et un service prévu sur un appareil du LAN câblé. En l’absence de bail, vérifier d’abord l’admission MAC, l’affectation du réseau, les membres du bridge et le DHCP du LAN. La communication locale sur le LAN est ici intentionnelle et ne prouve ni l’isolation des invités ni le passage par un chemin contrôlé par SFOS.

Bridge to VLAN

Bridge to VLAN sépare le réseau de gestion du point d’accès du VLAN client. Le port du switch vers le point d’accès doit transporter les deux réseaux en mode trunk. Dans le profil Wi-Fi, Bridge to VLAN ID désigne le VLAN client. Avec l’authentification Enterprise, cet ID de VLAN client peut être défini statiquement ou transmis par RADIUS avec un fallback statique.

Le point d’accès doit d’abord être connecté au pare-feu pendant au moins une minute via le LAN standard non tagué afin de recevoir sa configuration. Il faut ensuite activer VLAN tagging sous Wireless > Access points > AP > Advanced settings et saisir l’AP VLAN ID du réseau de gestion. Ce n’est qu’à ce stade que le port du switch est configuré en trunk. Le VLAN de gestion du point d’accès et le VLAN client peuvent utiliser des ID différents. Sophos recommande de ne pas combiner des réseaux Wireless Separate zone et VLAN sur le même point d’accès. Pour LocalWiFi0 intégré, le VLAN tagging côté point d’accès n’est pas disponible.

Après l’activation, le point d’accès tente pendant 60 secondes d’obtenir une adresse par DHCP dans le VLAN de gestion configuré. Sans réponse, il retente DHCP sur le LAN non tagué. Ce mécanisme constitue un chemin de récupération utile, mais pas un critère de réussite : le VLAN, le trunk et DHCP doivent être corrigés jusqu’à ce que le point d’accès soit réellement en ligne via le VLAN de gestion prévu. Avec Bridge to VLAN, SFOS crée automatiquement l’interface VLAN et les règles de pare-feu correspondantes. Ces objets doivent être contrôlés, car chaque point d’accès crée une interface backend distincte pour chaque zone et une architecture comportant de nombreux points d’accès et zones peut rapidement prendre de l’ampleur.

La zone de l’interface du pare-feu pour le VLAN de gestion des AP doit être autorisée sous Wireless > Wireless settings > Allowed zone. Le mode de trafic des clients et le VLAN tagging côté AP doivent être cohérents : Bridge to VLAN nécessite le marquage sur l’AP ; pour Separate zone, il peut être activé ou désactivé. L’ancienne aide VLAN désigne un autre cas par bridge to an access point VLAN et exige que le marquage sur l’AP y soit désactivé. Cette formulation ne doit pas être interprétée comme une option supplémentaire de l’interface utilisateur actuelle. Pour la procédure Bridge to AP LAN non marquée décrite ici, laissez le marquage sur l’AP désactivé ; pour une conception différente, confirmez la compatibilité sur le modèle et le build réels avant le changement.

Bridge to VLAN évite le chemin VXLAN et convient souvent mieux aux environnements Wi-Fi de grande taille déjà correctement segmentés. Ici aussi, le trafic au sein du VLAN client n’est pas automatiquement contrôlé par SFOS.

Préparer le réseau d’exemple

L’exemple utilise les valeurs suivantes :

Name dans SFOS : Guest WiFi
Hardware name non modifiable : GuestWiFi
SSID visible : Company Guest
Security mode : WPA2 Personal
Client traffic : Separate zone
Zone : WiFi
Réseau client : 10.30.40.0/24
Interface et passerelle : 10.30.40.1
Plage DHCP : 10.30.40.100 à 10.30.40.220
Règle de pare-feu : WiFi_Guest_to_WAN

10.30.40.0/24 est un exemple issu de l’espace d’adressage privé. Avant de le reprendre, il faut choisir un sous-réseau libre qui ne chevauche ni le LAN, ni un VPN, RED, un VLAN ou un site distant. Dans cet exemple, la première adresse utilisable, 10.30.40.1, appartient à l’interface Wireless du pare-feu et est distribuée comme passerelle.

Pour les appareils APX existants, WPA2 Personal avec AES constitue une base sûre et compatible. Une phrase secrète longue et unique doit être conservée dans le gestionnaire de mots de passe, et non dans des tickets ou des captures d’écran. Dans SFOS 22, Sophos documente les modes WPA3 uniquement pour le Wi-Fi intégré des modèles XGS 88w, 108w, 118w et 128w. Il ne faut donc pas prévoir WPA3 pour APX.

La liste de sécurité contient également No Encryption, WEP Open, d’anciens modes WPA et des modes mixtes WPA/WPA2. Ces entrées ne sont pas des recommandations pour un Wi-Fi nouveau ou renouvelé : n’utilisez ni profil invité non chiffré ni repli WEP/TKIP ; remplacez plutôt les clients incompatibles ou migrez-les séparément. Sur XGS 88w, 108w, 118w et 128w, les profils avec TKIP ou AES/TKIP peuvent être enregistrés, mais pas affectés à LocalWiFi0. Sur ces modèles, choisissez le mode WPA3 le plus robuste pris en charge par tous les clients prévus, ou WPA2 Personal avec AES, et testez réellement la connexion.

Configurer le Wi-Fi géré par SFOS

1. Autoriser la connexion du point d’accès

Avec un APX externe, le réseau de gestion et le réseau des clients Wi-Fi sont deux éléments distincts. Le point d’accès obtient sa propre adresse de gestion par DHCP depuis le réseau auquel il est connecté. Les clients Wi-Fi reçoivent ensuite des adresses provenant du réseau 10.30.40.0/24 planifié ci-dessus.

Ouvrir Wireless > Wireless settings.
Activer Enable wireless protection.
Sous Allowed zone, sélectionnez la zone par laquelle l’AP atteint le pare-feu. SFOS propose DMZ, LAN et WiFi à cet effet. Validez la sélection et enregistrez les paramètres Wireless avec Apply avant d’accepter l’AP.
Vérifier que le point d’accès reçoit par DHCP une adresse, une passerelle et une adresse de serveur DNS. Il n’est pas possible de configurer une adresse de gestion statique sur le point d’accès.
Vérifier que le port 2712 entre le point d’accès et le pare-feu n’est bloqué ni par un switch, ni par une ACL, ni par un équipement intermédiaire.
Ouvrir Wireless > Access points et accepter un point d’accès pending avec Accept.
Définir le Country correct sur le point d’accès actif. Les canaux autorisés par la législation en dépendent. Si le Country d’un APX est modifié, enregistrer le réglage, puis redémarrer le point d’accès de manière contrôlée afin d’appliquer la nouvelle liste de canaux.

Sur un pare-feu équipé de deux cartes Wi-Fi, une modification de Country affecte les deux cartes et règle les deux canaux sur Auto. Documentez au préalable les deux configurations radio et contrôlez-les toutes deux ensuite. Selon l’aide, sur l’APX 320, les deux radios doivent être réglées sur 5 GHz pour afficher tous les canaux 5 GHz disponibles ; en Israël, toutefois, Radio 0 ne prend en charge que 2.4 GHz. L’autorisation locale du pays prévaut : n’utilisez pas une autre sélection de Country pour forcer des canaux.

Sous Wireless > Wireless settings > Advanced settings, Timeout indique le nombre de minutes entre le passage hors ligne d’un point d’accès et la notification de délai dépassé ; une fois ce délai écoulé, SFOS considère l’AP comme inactive. Pour effectuer un contrôle maîtrisé, noter d’abord la valeur existante et déconnecter uniquement un AP de test sans clients de production, pendant une fenêtre de maintenance. Après un délai temporairement réduit mais compatible avec l’exploitation, la notification et l’état inactive doivent apparaître. Reconnecter ensuite l’AP, vérifier qu’il repasse à l’état active, puis rétablir l’ancienne valeur de Timeout.

Le choix sous Allowed zone concerne le chemin de gestion du point d’accès, et non la future zone des clients Wi-Fi. Si le point d’accès est encore enregistré auprès d’une autre Sophos Firewall ou dans Sophos Fusion, il faut d’abord le supprimer de cette plateforme. Si ce n’est pas possible, il faut le réinitialiser aux paramètres d’usine. Pour une mise hors service planifiée, retirez d’abord du réseau le point d’accès identifié sans ambiguïté, puis sélectionnez ce point d’accès sous Wireless > Access points et utilisez Delete. Vérifiez son identité au préalable ; ensuite, vérifiez que son entrée a été supprimée et que les points d’accès et SSID restants fonctionnent toujours. Delete ne correspond ni à la suppression d’une affectation Wi-Fi ni à la désactivation d’un groupe ; ne supprimez pas un point d’accès en production à titre d’essai pour résoudre un problème.

La connexion de contrôle sur le port 2712 est chiffrée en AES entre le pare-feu et le point d’accès. L’ouverture du port ne remplace toutefois pas la limitation du réseau de gestion des points d’accès à la zone qui en a réellement besoin.

2. Créer le Wireless Network

Sous Wireless > Wireless networks > Add, saisir les valeurs de l’exemple :

Name: Guest WiFi
Hardware name: GuestWiFi
SSID: Company Guest
Security mode: WPA2 Personal
Passphrase: une phrase secrète longue et unique
Client traffic: Separate zone
Zone: WiFi
IP address: 10.30.40.1
Netmask: /24

Le Hardware name peut contenir au maximum dix caractères parmi les lettres, les chiffres et le trait de soulignement, et ne peut plus être modifié ultérieurement. Name accepte jusqu’à 58 caractères et le SSID de 1 à 32 caractères ASCII imprimables. Tous deux peuvent être adaptés à la convention de nommage en vigueur. Le Name du réseau sans fil peut être modifié ultérieurement et s’affiche dans les autres paramètres à la place du Hardware name. Tous les caractères sauf '"<>#%\/, sont autorisés dans ce champ ; n’appliquez pas cette restriction à SSID, Hardware name ou Passphrase.

Sous Advanced settings, les choix suivants sont judicieux pour l’exemple invité :

Encryption: AES
Frequency band: uniquement les bandes prises en charge par le modèle et ses modules radio
Client isolation: activer si les connexions directes entre invités sont indésirables
Hide SSID: laisser désactivé
Fast transition: utilise IEEE 802.11r et exige WPA2 comme Security mode. APX ne prend pas en charge cette fonction. Utilisez-la uniquement sur du matériel compatible autre qu’APX, après avoir vérifié le modèle, le build SFOS et les clients ; cela n’implique ni la prise en charge d’AP6 ni une validation pour tous les modèles W ou pour WPA3.
Time-based access: contrôle les horaires d’accès autorisés pour ce SSID. Utilisez Add new item pour sélectionner une planification adaptée ou créer la vôtre. Effectuez l’activation et les modifications de configuration pendant une fenêtre d’interruption planifiée, car l’activation redémarre hostapd et déconnecte tous les clients du point d’accès concerné, comme décrit ci-dessous. Avec un client de test, vérifiez aussi bien la période prévue d’accès autorisé que celle d’accès bloqué ; cette planification d’accès n’est pas celle des analyses radio ou des analyses de points d’accès non autorisés.

Client isolation bloque uniquement les communications directes entre les clients du même SSID sur la même radio. Cette fonction ne remplace pas la séparation par zones, VLAN et règles de pare-feu entre plusieurs points d’accès ou modules radio. Un SSID masqué ne constitue pas non plus une mesure de sécurité ; il empêche uniquement l’affichage visible du nom du réseau.

Avec le Wi-Fi intégré, le fonctionnement simultané sur deux bandes dépend du matériel. Les modèles XGS 87w et 107w émettent uniquement sur 2.4 GHz ou 5 GHz. Les modèles XGS 116w, 126w et 136w nécessitent un deuxième module radio pour utiliser les deux bandes. Les modèles XGS 88w, 108w, 118w et 128w peuvent utiliser les deux bandes simultanément sans module supplémentaire.

Lors de l’activation d’un calendrier Wireless, SFOS redémarre hostapd. Tous les clients Wi-Fi du point d’accès concerné sont alors brièvement déconnectés, et pas seulement ceux de ce SSID. Les appareils devraient se reconnecter automatiquement.

Si un appareil connu doit également être bloqué, créez par exemple Bad hosts avec Type: MAC list sous Hosts and services > MAC host > Add, saisissez les adresses MAC effectivement à bloquer et enregistrez. Dans le profil invité, sous Advanced settings > MAC filtering, sélectionnez l’option de liste de blocage, affectez cette MAC list et enregistrez le Wireless Network avec Save. L’aide Separate zone appelle cette option Blacklist ; vérifiez le libellé de la liste de blocage dans le build utilisé. À l’aide d’un appareil de test bloqué et d’un appareil autorisé, vérifiez que seul l’appareil bloqué est refusé. Une adresse MAC usurpée ou aléatoire peut contourner ce blocage : celui-ci ne prouve ni la détection de logiciels malveillants ni qu’un appareil est sain, et ne remplace pas les politiques de protection ou la séparation des réseaux. Allowed zone autorise le chemin de gestion des AP ; l’activation de Wireless Protection seule ne prouve pas que tous les paquets Wi-Fi ou LAN sont analysés à la recherche de logiciels malveillants.

Valider séparément le Wi-Fi Enterprise et RADIUS

Pour un réseau Wireless utilisant 802.1X, le serveur RADIUS est sélectionné sous Wireless > Wireless settings. Le point d’accès ne communique pas directement avec le serveur RADIUS : il utilise le port 414 pour communiquer avec le pare-feu lors de l’authentification et le port 417 pour l’Accounting. Le pare-feu transmet ensuite l’Accounting au port RADIUS configuré, normalement 1813.

Pour l’authentification Enterprise, utilisez le Wireless network Name comme NAS ID, et non automatiquement le SSID visible ou le Hardware name. Ces valeurs peuvent différer. Adaptez la politique RADIUS à ce nom et vérifiez dans le journal d’authentification d’un client de test que la NAS ID et la politique attendues sont utilisées ; vérifiez séparément l’authentification et la comptabilisation.

L’Accounting doit être activé sur le serveur RADIUS ; ce chemin Wireless ne prend pas en charge les Interim Accounting Updates. Le Secondary RADIUS server ne doit pas être considéré comme un failover général : APX et les appareils compatibles Wi-Fi ne peuvent utiliser que le serveur RADIUS principal, et les XGS Appliances ne prennent pas en charge de serveur RADIUS secondaire pour ce flux.

Pour ce chemin sans fil géré par SFOS, les paramètres Wireless de SFOS 22 et 23 exigent un mappage NAT pour les réseaux des points d’accès lorsque le serveur RADIUS est connecté au pare-feu par un tunnel IPsec. L’IP source doit être traduite en l’adresse IP exacte du pare-feu par laquelle celui-ci atteint le serveur RADIUS. Il s’agit des réseaux des AP, et non du réseau des clients Wi-Fi en général. L’aide renvoie à une configuration via le shell avec sys-traffic-nat, mais ne fournit pas ici de commande complète exécutable. Cela n’établit aucune exigence générale de NAT pour les autres chemins RADIUS.

Avant toute modification, documenter la version et le build exacts de SFOS, les réseaux des AP, l’adresse source réellement utilisée, l’IP prévue du pare-feu pour la traduction, le tunnel et les Traffic Selectors, le chemin de retour et les journaux RADIUS. Sans syntaxe confirmée pour ce build et ce chemin de données, ne rien modifier dans le shell : demander à Sophos Support de confirmer le shell pris en charge, les paramètres et les adresses à utiliser, ainsi que les contrôles préalables, la vérification du succès et le retour arrière exact. Effectuer la modification uniquement pendant une fenêtre de maintenance selon cette procédure confirmée ; vérifier ensuite l’authentification 802.1X et l’Accounting avec un client de test, puis comparer l’IP source observée sur le serveur RADIUS et le chemin de réponse aux valeurs prévues. En cas d’écart, ne pas élargir les règles d’accès : examiner les éléments avec Support et appliquer le retour arrière confirmé si nécessaire.

Le trafic d’authentification généré par le pare-feu doit être distingué du trafic client transféré. L’article sur les routes IPsec pour le trafic transféré explique system ipsec_route et le NAT pour ce chemin de transfert ; il ne contient aucune procédure sys-traffic-nat. Ni son DNAT/SNAT réflexif ni une règle LAN vers VPN ne remplacent la configuration NAT du trafic système requise ici.

Après avoir configuré les paramètres généraux et avancés ainsi que, le cas échéant, les paramètres Enterprise et du filtre MAC, enregistrer le Wireless Network avec Save – même si aucune liste de blocage MAC n’est utilisée. Sous Wireless > Wireless networks, vérifier que Guest WiFi apparaît avec les paramètres prévus. Créer seulement ensuite le serveur DHCP sur cette interface et attribuer le réseau à un AP comme décrit ci-dessous. Unplugged avant l’attribution à un AP ne constitue pas une raison de recréer le profil ou de le créer avec un autre mode de trafic.

3. Ajouter DHCP pour le réseau client

Pour Separate zone, aucun serveur DHCP complet n’est automatiquement mis à disposition des clients. Il faut donc créer, par exemple, la configuration suivante sous Network > DHCP > Server > Add :

Name: dhcp-wifi-guest
Interface: Guest WiFi
Dynamic IP lease: 10.30.40.100 à 10.30.40.220
Subnet mask: /24
Gateway: Use interface IP as gateway
DNS server: selon l’architecture DNS en place
Conflict detection: activé

La plage est délibérément placée au-dessus de l’adresse de l’interface et laisse de l’espace pour les adresses réservées. Sur un réseau Wi-Fi invité où les clients changent fréquemment, une durée de bail plus courte que sur un réseau de bureau stable peut être judicieuse. Des baux extrêmement courts génèrent en revanche un nombre inutilement élevé de renouvellements.

Le choix des serveurs DNS distribués relève de la sécurité et de l’exploitation. Il ne faut pas rendre des serveurs DNS AD internes accessibles aux invités par simple commodité. L’article Configurer Sophos Firewall comme serveur DHCP décrit la planification complète et le contrôle des baux.

4. Contrôler la règle de pare-feu, NAT et les services locaux

Sous Rules and policies > Firewall rules > Add firewall rule > New firewall rule, créer une règle pour l’accès Internet souhaité. L’article consacré aux règles de pare-feu Sophos Firewall explique le formulaire complet, l’ordre des règles et les Security Features.

Rule name: WiFi_Guest_to_WAN
Action: Accept
Log firewall traffic: activé
Source zones: WiFi
Source networks and devices: objet réseau pour 10.30.40.0/24
Destination zones: WAN
Destination networks: Any
Services: uniquement les services nécessaires au réseau Wi-Fi invité
Security features: politiques Web, Application et IPS adaptées à la licence et au cas d’utilisation

Un objet réseau explicite comme net_WiFi_Guest rend la règle plus restrictive et plus compréhensible que Source networks: Any. Le choix des services dépend notamment de l’utilisation locale de DNS et NTP sur le pare-feu ou de leur accès direct à l’extérieur. Une autorisation générale Any est pratique, mais complique les contrôles ultérieurs.

Une règle NAT doit en outre traduire le trafic sortant vers l’adresse WAN. La règle Default-SNAT existante avec MASQ couvre souvent déjà les nouveaux réseaux internes. Il faut toutefois le vérifier dans le jeu de règles concret au lieu de créer une deuxième règle NAT sans nécessité. L’article Comprendre NAT sur Sophos Firewall explique cette interaction.

Une règle WiFi-to-WAN n’empêche pas automatiquement les accès autorisés par des règles WiFi-to-LAN ou Any existantes et trop larges. Il faut donc contrôler l’ensemble de l’ordre des règles à la recherche d’autorisations internes. Si des clients du même réseau Separate-Zone doivent communiquer entre eux via plusieurs points d’accès, une règle WiFi-to-WiFi supplémentaire est nécessaire. Pour un réseau Wi-Fi invité, cette communication ne doit être autorisée que délibérément.

Les accès au pare-feu lui-même ne sont pas régis par la règle de pare-feu normale. Sous Administration > Device access, vérifiez les autorisations WiFi réellement configurées pour HTTPS et SSH, au lieu de supposer un réglage par défaut particulier. Sous Administration > Device access, il faut donc décocher WiFi pour HTTPS, SSH et tous les autres services locaux inutiles sur un réseau Wi-Fi invité. DNS ne reste autorisé que si les clients utilisent effectivement le pare-feu comme résolveur. L’article Device Access et Local Service ACL fournit des explications complémentaires.

5. Affecter le réseau Wi-Fi à un point d’accès

Un Wireless Network enregistré n’est encore diffusé par aucun point d’accès :

Ouvrir Wireless > Access points.
Ouvrir le point d’accès actif en cliquant sur son nom ou sur Edit.
Contrôler que le Country est correct.
Sous Wireless networks, cliquer sur Add new item.
Sélectionner Guest WiFi, appliquer le choix avec Apply, puis cliquer sur Save.

Avec plusieurs points d’accès, un groupe sous Wireless > Access point groups offre une meilleure visibilité. Les SSID sont ainsi affectés de manière cohérente et ne sont pas gérés différemment pour chaque point d’accès. Jusqu’à huit Wireless Networks peuvent être affectés à un point d’accès.

Le groupe est créé sous Wireless > Access point groups > Add avec un nom, les Wireless networks, le VLAN tagging facultatif et les Access points inclus. Avant l’enregistrement, vérifier que l’affectation VLAN convient réellement à tous les points d’accès sélectionnés.

⚠️ Impact opérationnel : La désactivation d’un groupe de points d’accès arrête la diffusion des réseaux Wi-Fi attribués sur tous les points d’accès qu’il contient. Toute modification de groupe doit être planifiée dans une fenêtre de maintenance avec une liste documentée des points d’accès et SSID.

Modifier délibérément les paramètres radio et les groupes de points d’accès

Sous Wireless > Access points > AP > Advanced settings, le canal, Dyn chan, TX power et Channel width affectent davantage qu’un seul client de test. Un changement dynamique de canal peut forcer les clients connectés à se reconnecter. Des canaux plus larges peuvent augmenter le débit dans un environnement peu dense, mais le chevauchement supplémentaire peut le réduire dans un environnement très dense. SFOS utilise par défaut 20 MHz en 2,4 GHz et 40 MHz en 5 GHz. La puissance d’émission et la largeur de canal doivent donc être mesurées sur chaque site plutôt que maximisées sans distinction.

Turn on Spanning Tree Protocol (STP) protège les réseaux bridgés contre les boucles de couche 2 et les tempêtes de broadcast qui en résultent. STP ne doit pas être traité comme un simple réglage de performance. Après une modification, tester au moins deux clients réels, le roaming, DHCP, DNS et un transfert prolongé ; avec la sélection automatique du canal, relever également l’heure du changement et la reconnexion correcte des clients.

Si la sélection dynamique du canal ne doit s’exécuter qu’à des heures définies, activez d’abord Dyn chan, puis Time-based scan pour chaque bande, et attribuez le Schedule prévu sous Select scan time > Add new item ou créez-le via Add. Après Save, observez l’heure du scan et une éventuelle reconnexion des clients. Avant toute modification de groupe, identifiez sans ambiguïté l’AP à l’aide de ID (numéro de série), Label et Group. Un WLAN individuel peut être désélectionné dans ses détails AP avec remove ; enregistrez ensuite et vérifiez les autres SSIDs. Cela ne revient pas à désactiver l’ensemble du groupe d’AP. Pour un redémarrage planifié de l’AP, l’AP sélectionné peut être redémarré sous Wireless > Access points avec Restart ; sauvegardez au préalable la liste des clients et les journaux, puis répétez les tests de connexion décrits ci-dessous.

Tester le réseau Wi-Fi de manière contrôlée

La validation ne doit pas s’arrêter à « le SSID est visible ». Un client de test permet de vérifier que le réseau et les règles prévus sont réellement utilisés :

Sous Wireless > Access points, le point d’accès doit être actif. Sous Network > Interfaces, l’interface Wireless reste à l’état Unplugged tant qu’aucun point d’accès n’est associé à ce Wireless Network.
Se connecter à Company Guest et contrôler le point d’accès, le SSID, la fréquence et le signal sous Wireless > Wireless client list.
Sous Network > DHCP > IPv4 lease, vérifier que le client a reçu une adresse comprise entre 10.30.40.100 et 10.30.40.220.
Contrôler l’adresse IP, la passerelle et le DNS sur le client. Sous Windows, utiliser :

ipconfig /all
nslookup example.com

Tester une connexion Internet autorisée et, volontairement, une destination interne non autorisée.
Dans le Log Viewer, filtrer sur l’adresse IP du client et contrôler la Firewall Rule ID ainsi que la NAT Rule ID attendues.

La réussite ne se limite pas à l’accès Internet. Le client doit utiliser la passerelle et les serveurs DNS prévus, rester séparé des destinations internes non autorisées et passer exactement par les règles de pare-feu et NAT attendues. La procédure de contrôle générale est décrite dans Tester correctement les règles de pare-feu.

Rechercher les points d’accès rogue de manière contrôlée

Rogue AP scan est disponible uniquement sur les appliances Sophos Firewall dotées d’un Wi-Fi intégré ; les points d’accès APX externes ne peuvent pas effectuer ce scan. Sous Wireless > Rogue AP scan, Scan now recherche les points d’accès à portée radio. Les clients Wi-Fi connectés sont brièvement déconnectés pendant le scan. Un scan manuel ou planifié doit donc s’effectuer dans une plage horaire connue, et non sans préavis en production.

Les appareils détectés apparaissent sous Unrecognized access points et sont délibérément marqués comme autorisés ou comme Rogue AP. Cette classification ne remplace pas l’analyse d’un incident : il faut corréler le SSID, le BSSID, le canal, le signal, l’emplacement et le port de switch possible avant de traiter un réseau Wi-Fi inconnu comme un appareil du LAN de l’organisation.

Pour les scans récurrents, un calendrier est sélectionné sous General settings > Schedule system-triggered scan at. Avec LocalWiFi0, Bridge to Ethernet activé et un réseau Wireless en mode Bridge to AP LAN, le scan affiche uniquement les réseaux proches utilisant la même bande de fréquences que le réseau Wireless attribué. Cette limite du produit doit être documentée lors de l’évaluation du résultat.

Appliquez la planification du scan avec Apply. Dans les résultats, utilisez les actions Mark as “authorized access point” ou Mark as “rogue access point” et contrôlez l’affectation obtenue. Une entrée marquée comme rogue est une classification, et non un mécanisme attesté permettant d’éteindre ou de bloquer un point d’accès tiers.

Identifier les erreurs courantes

Le SSID n’est pas affiché

Vérifier d’abord que Wireless Protection est actif, que la zone de gestion du point d’accès figure sous Allowed zone et que le point d’accès apparaît comme active, et non pending ou inactive, sous Wireless > Access points. Contrôler ensuite Country, le Wireless Network affecté, Frequency band et un éventuel calendrier.

Un réseau enregistré sans affectation à un point d’accès n’est pas diffusé. Avec le Wi-Fi intégré, les limites du modèle concernant les bandes de fréquence ou un ancien mode de chiffrement non pris en charge peuvent également empêcher l’association du profil à LocalWiFi0.

L’interface Separate zone reste `Unplugged`

Le statut Unplugged est normal tant qu’aucun point d’accès n’est connecté ou que le réseau Wi-Fi n’est affecté à aucun AP. S’il persiste malgré un APX actif et une affectation correcte, il faut contrôler le chemin de gestion du point d’accès.

Sous SFOS 21.5 MR1 Build 261, ce problème peut survenir lorsque l’adresse IP du pare-feu utilisée par le réseau de gestion de l’APX est configurée comme alias au lieu d’être attribuée directement à l’interface parente (NC-175920). SFOS ne peut alors pas créer le tunnel VXLAN pour Separate zone. La solution de contournement consiste à déplacer l’APX vers un réseau de gestion dont l’adresse IP du pare-feu est directement attribuée à l’interface parente. Il ne faut pas supprimer l’adresse alias sans avoir confirmé la cause.

Ce changement interrompt les réseaux Wi-Fi diffusés par le point d’accès. Il faut donc vérifier au préalable le DHCP, la passerelle, Allowed zone et le port 2712 dans le réseau cible, puis effectuer la modification pendant une fenêtre de maintenance. Contrôler ensuite l’état du point d’accès, l’affectation du réseau Wi-Fi, l’état de l’interface et la connexion d’un client de test. Sophos n’indique aucune version corrective ; sur les autres versions de SFOS, le seul état Unplugged ne suffit donc pas à prouver ce problème.

Le client ne reçoit pas d’adresse IP

Avec Separate zone, le serveur DHCP doit être lié à l’interface Wireless créée et la plage doit correspondre au réseau de l’interface. Avec Bridge to AP LAN, c’est en revanche le serveur DHCP du LAN du point d’accès qui répond. Avec Bridge to VLAN, il faut contrôler conjointement le trunk du switch, l’ID de VLAN et le serveur DHCP joignable dans le VLAN client.

Il ne faut pas confondre le DHCP de gestion du point d’accès et le DHCP des clients : le point d’accès peut être en ligne même si aucun serveur DHCP opérationnel n’est encore disponible pour les clients Wi-Fi.

Le client dispose d’une adresse IP, mais pas d’Internet

DHCP et la liaison radio sont alors déjà opérationnels ; le problème se situe plus loin, au niveau de la stratégie. Il faut ensuite contrôler la passerelle et le DNS, la règle WiFi-to-WAN, l’ordre des règles, la journalisation et la règle MASQ/SNAT appropriée. Le Log Viewer indique si la Firewall Rule ID prévue a été appliquée ou si la règle implicite #0 rejette le trafic.

Si le client accède à Internet, mais aussi à des systèmes internes, le résultat n’est pas correct pour un réseau Wi-Fi invité. Dans ce cas, des règles WiFi-to-LAN, Any ou des règles réseau trop larges s’appliquent probablement.

La connexion du point d’accès ou la communication des clients reste incertaine

Le trafic du pare-feu n’apparaît de manière fiable dans le Log Viewer que si Log firewall traffic est activé dans la règle et si le type de journal Firewall est actif sous System services > Log settings > Local reporting. Les événements Wireless ne sont pas disponibles à cet endroit comme type de journal Wireless local normal. Sous System services > Log settings, ils peuvent être envoyés à Sophos Fusion ou à un serveur Syslog.

Pour un diagnostic approfondi, Sophos documente awed.log pour la communication entre le pare-feu et APX, wc_remote.log pour les clients Wi-Fi et hostapd.log pour LocalWiFi. L’article Contrôler les services et journaux de Sophos Firewall par CLI explique comment lire ces journaux sans redémarrage incontrôlé d’un service.

Le journal d’un APX accessible peut être lu avec awetool si nécessaire. Connectez-vous à la CLI du pare-feu en tant que admin, sélectionnez 5 – Device Management, puis 3 – Advanced Shell, et lancez awetool. Sélectionnez Connect to an AP, choisissez l’AP cible d’après son identité, confirmez avec OK et terminez la connexion avec y. Ce n’est que sur cet AP que logread et logread -f constituent les vérifications en lecture documentées. La commande reboot, également proposée, déconnecte les clients et modifie l’état ; elle ne doit être exécutée qu’après la sauvegarde des journaux, pendant une fenêtre de maintenance, avec un contrôle ultérieur de l’état de l’AP, du SSID, de la liste des clients et du trafic réel. N’appliquez pas ces étapes du shell APX à AP6, à LocalWiFi intégré ou à UTM.

Les transferts volumineux sont lents ou s’interrompent

Si seuls les paquets volumineux ou les transferts prolongés sont concernés, l’encapsulation VXLAN de Separate zone peut jouer un rôle. Il n’existe pas de valeur MTU universelle dans ce cas. Il faut d’abord documenter la Rule ID, le chemin des données, les Retransmits et un test applicatif reproductible. Une modification contrôlée n’est effectuée que lorsqu’un problème de MTU/MSS a été démontré, puis le même test est répété.

Bien distinguer les objets Wireless via l’API XML

Pour automatiser les paramètres décrits ci-dessus, il faut traiter séparément le profil réseau, la radio locale, le groupe d’AP et les paramètres Wireless globaux. Les références XML pour SFOS 22 et 23 documentent les objets suivants, mais n’autorisent pas pour autant l’envoi d’une requête d’écriture copiée telle quelle. L’accès, les opérations explicites, l’analyse des réponses et les nouvelles tentatives sûres sont expliqués dans Sécuriser l’accès à l’API XML de Sophos Firewall. Avant toute modification, sauvegarder l’état existant des objets et leurs dépendances, et prévoir une procédure de retour arrière validée. Pour les contradictions entre sources mentionnées ci-dessous, clarifier d’abord les champs d’écriture concernés dans API help du build installé ou auprès du support ; ne pas les envoyer tant que ce point n’est pas résolu. Tous les codes ci-dessous sont des valeurs de statut XML propres aux objets, et non des codes de statut HTTP ; tous les symboles Message.* sont des clés de référence non résolues, et non des textes confirmés renvoyés à l’exécution. Consigner ensemble l’opération, le code et la réponse réelle expurgée.

WirelessLocalAP : identité et paramètres radio du modèle W

WirelessLocalAP concerne le point d’accès local intégré d’une appliance Wireless compatible, et non l’interface web locale d’un AP6 ni sa gestion via Central/Fusion. Ce contrat ne définit ni un nouveau processus API pour APX ni une procédure pour les anciens appareils AP/UTM. Le champ obligatoire Id identifie l’AP local existant ; Label est un libellé facultatif, pas une identité de remplacement. L’exemple de référence utilise LocalWifi0/LocalWifi1, tandis que l’aide de l’interface utilise LocalWiFi0. Ne pas corriger silencieusement la casse et ne pas envoyer la barre oblique comme s’il s’agissait d’un identifiant commun : confirmer l’identité individuelle réelle dans le résultat de lecture ou d’export correspondant au build. Country doit correspondre à l’emplacement réel, et non à l’exemple In.

Dans l’exemple, les affectations réseau figurent sous WirelessNetworks/Network. Le tableau décrit Network comme un tableau de valeurs et avertit que les doublons ne sont pas ignorés. Il faut donc vérifier intégralement les affectations existantes et ne pas envoyer une liste de SSID ou des noms de réseau supposés. La limite de huit Wireless Networks affectés et les limites matérielles des bandes radio restent pertinentes même en cas d’automatisation.

Pour l’affectation des bandes, le tableau décrit Band avec 2.4GHz ou 5GHz ; pour 2,4 GHz, il indique Channel, ChannelWidth, TXPower, DynChan et TimeBasedScan, et pour 5 GHz, Channel5GHz, ChannelWidth11a, TXPower5GHz, DynChan5GHz et TimeBasedScan5GHz. L’exemple présente les horaires de scan sous ScanTime/Time ; le tableau mentionne deux fois Time comme tableau dépendant de la bande, sans montrer clairement la structure parente pour les deux bandes. Confirmer la structure parente correcte de chaque bande avant toute requête d’écriture, au lieu de regrouper toutes les entrées Time ou d’inventer un parent pour 5 GHz. Les horaires de scan radio ne constituent pas le calendrier d’accès au SSID.

Plusieurs indications se contredisent : l’exemple utilise Channel2.4GHz, le tableau Channel ; pour DynChan et TimeBasedScan, l’exemple indique Enable, alors que les listes de valeurs ne mentionnent que t. Pour TXPower, l’exemple présente 100, tandis que le tableau indique 10%, 25%, 50%, 75%, 100%. Le texte relatif à l’affectation de bande de DynChan est lui aussi ambigu. Il n’est pas confirmé que ces formes soient interchangeables. La description de l’export pour DynChan5GHz distingue en outre Disabled (canal statique, scan dynamique désactivé), 1 (canal automatique sans scan dynamique) et Enabled (canal automatique avec scan dynamique) ; ne pas considérer automatiquement les valeurs exportées comme des entrées d’écriture autorisées.

BridgeToEthernet, BridgeToPort et Zone concernent le pont Ethernet local, et non l’ID de VLAN client d’un profil réseau. Les limites Gen.1/Gen.2, les prérequis IPv4/Bridge-to-AP-LAN et les vérifications DHCP/accès administrateur décrits ci-dessus restent applicables. Après une modification confirmée, vérifier les deux radios concernées, le pays, les affectations réseau, le pont et un client réel avant de modifier d’autres AP.

Dans les deux versions de référence, Status Message Information associe les valeurs de statut XML suivantes à l’opération Update Local AP :

200, 216 : Message.WPAPkUpdateSuccessfully ; 500, 541, 543, 544, 545 : Message.WPAPUpdateFail.
523 : Message.WPNetworkGroupMax ; 524 : Message.WPAccessPointMax ; 542 : Message.WPAccessPointMesh.
547 : Message.WPAPUpdateFailVLANGroup ; 548 : Message.WPA3IsNotSupported.
561 : Message.LegacyModeNotSupported ; 564 : Message.TKIPModeNotSupported ; 565 : Message.TopazToNonTopazImportFail.

Il s’agit de clés de référence littérales non résolues, et non de messages avérés renvoyés à l’exécution. En particulier, ne pas déduire de Message.TopazToNonTopazImportFail une correspondance entre modèles ou une migration par import autorisée. Si une réponse est ambiguë, relire l’identité de l’AP, les paramètres radio et les affectations enregistrés, sans répéter automatiquement la même mise à jour ni affaiblir le chiffrement.

WiFi6Interface : une interface existante, et non un SSID ou un bridge

Dans les références XML pour SFOS 22 et 23, WiFi6Interface gère les paramètres réseau et de zone par port de LocalWiFi6, et non un profil SSID ou un bridge physique. Les champs obligatoires sont Name, Hardware et Zone : Name est le libellé descriptif, limité à 58 caractères ; Hardware désigne le nom matériel de l’interface déjà existante. Avant toute modification, confirmer cette identité dans le résultat de lecture ou d’export correspondant au build, sans la déduire du nom d’affichage, du SSID ou de WirelessNetworks.HardwareName. La limite de dix caractères parmi A-Za-z0-9_ applicable au nom matériel d’un bridge physique n’est pas reprise ici ; le tableau WiFi6Interface indique uniquement une chaîne de caractères pour Hardware. Le nom de l’objet API ne permet pas non plus de déduire une correspondance avec une génération matérielle. Les contrôles du bridge dans l’interface graphique, du DHCP et de l’accès administrateur décrits ci-dessus selon le modèle restent applicables sans changement.

IPv4Address et Netmask sont facultatifs dans ce contrat. Cela n’implique ni l’obligation de définir une nouvelle adresse ni un effet confirmé lorsque des valeurs existantes sont omises. Avant toute modification, documenter le port réel, la zone et l’éventuelle adresse IP avec son masque ; ensuite, relire l’état de cette même interface et le comparer au plan d’adressage prévu. Cette comparaison de l’interface ne remplace ni la vérification de l’affectation à l’AP et du SSID ni un test réel avec un client.

Pour l’opération WiFi6Interface, les deux sources indiquent 200/Message.InterfaceUpdateSuccess, 500/Message.InterfaceUpdateFail et 502/Message.InterfaceIPAlreadyInUsed. Il s’agit de valeurs de statut XML propres à l’objet, associées à des clés de référence non résolues, et non de codes HTTP ou de textes confirmés renvoyés à l’exécution. Consigner ensemble l’opération, le code et la réponse réelle expurgée. Si le résultat est ambigu, relire d’abord l’identité matérielle, le port, la zone et, le cas échéant, l’IP et le masque, au lieu de répéter automatiquement la même mise à jour ou de créer un autre objet Wireless. Un code de réussite ne prouve à lui seul ni une affectation réseau correcte ni le bon fonctionnement du trafic Wi-Fi ; aucune nouvelle requête d’écriture n’est déduite ici.

WirelessNetworks : distinguer l’identité matérielle, le profil et le statut

Dans WirelessNetworks, le Hardware name immuable, le nom d’affichage modifiable Name et le SSID diffusé sont des valeurs distinctes. Dans l’exemple du réseau invité, il s’agit de GuestWiFi, Guest WiFi et Company Guest. Le tableau des paramètres d’ajout/mise à jour exige HardwareName, avec un maximum de dix caractères ; l’opération de suppression identifie elle aussi la cible par HardwareName, et non par le SSID ou le nom d’affichage. Avant une suppression, contrôler les affectations aux AP, l’interface, le DHCP et les règles, et ne supprimer que la cible clairement identifiée dont la suppression a été approuvée. Une erreur ne justifie pas de recréer le profil sous un nouveau nom.

L’exemple d’ajout/mise à jour utilise toutefois Hardware au lieu de HardwareName, ainsi que ClientIsolation avec Enable au lieu de la valeur Enabled du tableau. La même divergence existe pour HideSSID ; le tableau indique Enabled/Disabled pour chacun des champs TimeBasedAccess, ClientIsolation, HideSSID et FastTransition. De même, MACFiltering avec Allowlist/Blocklist côtoie une ancienne description de MACList avec Whitelist/Blacklist. Ne résoudre aucune de ces divergences par supposition. Le contrat XML répertorie également des modes de sécurité plus anciens, tandis que l’aide actuelle de l’interface ne décrit WPA3 que pour les modèles W mentionnés ci-dessus : cela ne permet pas d’en déduire une syntaxe d’écriture WPA3 complète.

Les valeurs de trafic documentées SeparateZone, BridgetoAPLAN et BridgetoVLAN relèvent de ClientTraffic. IPAddress et Netmask concernent Separate zone ; BridgetoVLANid concerne le VLAN client, et ClientVlanId concerne Static ou RadiusAndStatic. Ne pas confondre ces valeurs avec le VLAN de gestion des AP. Ne pas reprendre la clé d’exemple, l’adresse IP publique de l’exemple ni TKIP(only abg) : l’objectif reste AES ou un mode de sécurité plus robuste dont la prise en charge est avérée, une phrase secrète sûre propre à l’environnement et une séparation contrôlée des réseaux. ClientIsolation ne remplace toujours pas une frontière de pare-feu ou de VLAN entre plusieurs radios/AP.

Pour Add Wireless Network, les deux références indiquent les associations suivantes :

200 : Message.WPNetworkSuccess ; 500, 541, 545 : Message.WPNetworkFail.
502 : Message.WPNetworkExists ; 503 : Message.WPNetworkInterfaceExists ; 542 : Message.WPNetworkInterfaceIPExists.
544 : Message.InterfaceIPAssignedToPeerAdminIP ; 548 : Message.InterfaceReservedName ; 560 : Message.DHCPIPRangeConfig.

Pour Update Wireless Network, plusieurs clés diffèrent malgré des codes identiques :

200 : Message.WPNetworkUpdateSuccessfully ; 500, 541, 543, 545, 549 : Message.WPNetworkUpdateFail.
503 : Message.WPNetworkInterfaceExistsForUpdate ; 542 : Message.WPNetworkInterfaceIPExistsForUpdate.
544 : Message.InterfaceIPAssignedToPeerAdminIP ; 548 : Message.InterfaceReservedName ; 560 : Message.DHCPIPRangeConfig.
546 : Message.WPBindWithLA ; 547 : Message.APNotSupport5GHzWP.
561 : Message.SecModeChangedToLegacyFail ; 562 : Message.SecModeChangedToWAP3Fail ; 563 : Message.EncModeChangedToTKIPFail.

Pour Delete Wireless Network, les associations documentées sont 200/Message.WPNetworkDeleteSuccess, 500/Message.WPNetworkDeleteFail, 541/Message.BridgeWirelessNetworkExists et 542/Message.WPEnableDeteleFail. Même les erreurs typographiques apparentes telles que Message.SecModeChangedToWAP3Fail et Message.WPEnableDeteleFail restent inchangées ; elles ne sont pas renommées en messages d’exécution supposés corrects. Face à ces réponses, vérifier d’abord l’identité matérielle, l’IP, les dépendances DHCP, le pont et les affectations aux AP réellement enregistrés. Ne pas affirmer, sur la seule base d’une clé, une cause, la réussite d’un retour arrière ou la sûreté d’une nouvelle tentative.

WirelessNetworkStatus est un objet distinct : son tableau décrit explicitement Name comme un nom d’interface de dix caractères au maximum, et non comme un alias automatique du SSID ou du nom d’affichage. Status utilise ici Enable/Disable, et non les valeurs Enabled/Disabled d’autres champs. Confirmer au préalable le nom réel de l’interface. Pour Enable-Disable Wireless Network, les associations sont 200/Message.WPNetworkUpdateSuccessfully et 500/Message.WPNetworkUpdateFail. Une modification de statut n’affecte le réseau à aucun AP et ne prouve pas encore sa diffusion ; vérifier séparément le statut enregistré, l’affectation à l’AP et la connexion d’un client.

WirelessGrouping : l’appartenance à un groupe n’est pas une configuration radio

WirelessGrouping décrit un groupe d’AP avec Name et les entrées répétables WirelessNetworks/Network et AccessPoints/AccessPoint. Reprendre les identités des AP du parc existant, et non l’ancien exemple AP30 de la référence. La structure du groupe configure les affectations réseau et, facultativement, le marquage VLAN de gestion des AP, mais pas les paramètres radio locaux propres à chaque bande. Le caractère facultatif des tableaux ne permet pas de déduire une sémantique confirmée pour les listes vides ni la sûreté d’une mise à jour partielle.

VLANTagging indique Enable/Disable ; APVLANID indique 1 à 4094 et s’applique lorsque le marquage est activé. Il s’agit du VLAN de gestion des AP, et non de BridgetoVLANid pour les clients. Avant toute modification, vérifier la liste complète des membres, le trunk, le DHCP de gestion, Allowed zone et la procédure de retour arrière. La désactivation d’un groupe arrête toujours la diffusion de ses AP ; après une modification confirmée, contrôler chaque AP concerné et les SSID prévus.

Pour Add an Access Point Group, les associations sont 200, 216/Message.WPGroupSuccess, 500, 541, 543, 545/Message.WPGroupCreated, 502/Message.WPGroupExists, 523/Message.WPGroupMax, 524/Message.WPGroupMaxAP et 546/Message.WPA3IsNotSupported. Pour Update an Access Point Group, elles sont en revanche 200, 216/Message.WPGroupUpdateSuccessfully, 500, 541, 543, 545/Message.WPGroupUpdateFail, 523/Message.WPGroupMaxForUpdate, 524/Message.WPGroupMaxAPForUpdate et 546/Message.WPA3IsNotSupported. La clé déroutante Message.WPGroupCreated associée à des codes d’erreur ne garantit pas une réussite. Avant une nouvelle tentative, relire le groupe et les membres enregistrés, au lieu de créer un deuxième groupe ou d’y ajouter d’autres AP.

Paramètres globaux : accès de gestion et répercussions

WirelessProtectionGlobalSettings n’est ni un profil SSID ni une zone client. Dans l’exemple, AllowedZone/Zone contient les zones de gestion répétables ; NotificationTimeout correspond au délai de notification hors ligne en minutes expliqué ci-dessus. RADIUSServer désigne le serveur sélectionné globalement pour le fonctionnement Enterprise décrit. Pour le commutateur, l’exemple utilise WirelessProtection, tandis que le tableau indique EnableWirelessProtection : clarifier également ces noms de champs divergents pour le build concerné avant toute requête d’écriture.

Pour Global Settings, les deux références indiquent 200/Message.WLANAPEditSuccessful, 500/Message.WLANAPEditFailed, 501/Message.WLANAPIPAlreadyInUsed et 504/Message.WLANAPIntBaseVHExist. Les autres distinctions sont les suivantes :

511 : Message.WLANAPFailedWhileUnbinding ; 512 : Message.WLANAPFailedWhileDeleteDHCPServer ; 513 : Message.WLANAPFailedWhileDeleteDHCPRelay.
516 : Message.WLANAPFailedToUnbindInterface ; 520 : Message.WLANAPFailedToUnbindIfaceRCg ; 521 : Message.WLANAPEditRunConfigFailed.
523 : Message.WLANAPWLAN1UnboundEditFaild ; 524 : Message.WLANAPOtherUnboundEditFaild.

Ces clés ne sont pas interprétées comme des causes d’erreur prouvées, mais montrent pourquoi une modification globale ne doit pas être traitée comme un test anodin : les liaisons d’interfaces et la configuration DHCP peuvent être affectées. Ne pas désactiver puis réactiver Wireless Protection pour un diagnostic rapide. Avant une modification planifiée, consigner la sauvegarde, l’accès administrateur indépendant, les interfaces, les serveurs/relais DHCP et les affectations aux AP. Ensuite, relire l’état global réellement enregistré et les services concernés, vérifier l’accessibilité des AP et les clients, puis décider uniquement sur la base de ces éléments d’une nouvelle tentative ou du recours à la procédure de retour arrière validée. Un code de réussite XML ne prouve à lui seul ni l’effet sur la radio ni la réussite complète de la configuration.