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.

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.

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.

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.

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.

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électionner la zone par laquelle le point d’accès rejoint le pare-feu. SFOS propose pour cela DMZ, LAN et WiFi.
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.

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.

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.

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: n’est pas pris en charge par APX
Time-based access: n’utiliser que dans le cadre d’une fenêtre de maintenance planifiée

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.

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.

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.

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. Par défaut, SFOS autorise HTTPS et SSH depuis la zone WiFi. 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.

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.

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.

Si nécessaire, le journal d’un APX joignable peut être lu depuis l’Advanced Shell avec awetool. Après Connect to an AP, logread et logread -f sont des contrôles en lecture seule. La commande reboot, également proposée, déconnecte les clients et modifie l’état ; elle ne doit être utilisée qu’après la sauvegarde des journaux, dans une fenêtre de maintenance, puis suivie d’un contrôle de l’état de l’AP, du SSID, de la liste des clients et du trafic réel.

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é.