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

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.

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 appliance XGS 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 Central ou, pour un appareil individuel, depuis son interface locale. Pour la variante Central, 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.

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.

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.

Avec LocalWiFi intégré, une interface bridge ou Bridge to Ethernet est en outre nécessaire selon la génération XGS. Cette variante ne doit donc être choisie que si le Wi-Fi et le LAN câblé appartiennent délibérément à la même zone de sécurité.

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.

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, par exemple LAN.
Vérifier que le point d’accès reçoit par DHCP une adresse, une passerelle et une adresse de serveur DNS.
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.

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 Central, 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.

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 et SSID peuvent en revanche ê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.

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.

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.

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

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