Configurer et tester Wireless Mesh sur Sophos Firewall

Un Wireless Mesh sur Sophos Firewall relie sans fil un ou plusieurs Sophos Access Points APX à un AP racine câblé. Il peut couvrir une zone sans signal lorsqu’aucun câblage Ethernet n’est disponible à l’emplacement distant. Le backhaul mesh n’est pas le SSID WLAN visible : SFOS crée pour lui un réseau WPA2-Personal masqué avec une phrase secrète aléatoire. Les clients continuent d’utiliser un Wireless Network configuré séparément.

⚠️ Important : Ce guide s’applique aux installations APX existantes gérées directement par SFOS. APX ne peut former un mesh qu’avec APX. AP6, LocalWiFi intégré, les modules Wi-Fi SD-RED et les séries d’AP Sophos mixtes ne font pas partie de cette procédure. Un mesh ne remplace pas non plus une redondance câblée : au moins un AP reste connecté au LAN et SFOS ne change pas automatiquement d’AP racine si celui-ci tombe en panne.

Procédure rapide :

1. Connecter d’abord les deux APX au LAN, les accepter sous Wireless > Access points et vérifier le firmware, Country et le plan radio.
2. Définir le même canal fixe sur tous les AP participants pour la bande mesh et désactiver Dyn chan.
3. Configurer Mesh-ID, Frequency band et les APX sous Wireless > Mesh networks > Add.
4. Affecter séparément le SSID client visible aux deux APX.
5. Enregistrer la configuration, redémarrer les APX, ne laisser que l’AP racine câblé et attendre jusqu’à cinq minutes.
6. Vérifier de manière contrôlée l’état des AP, la connexion client, DHCP, Rule ID, l’accès Internet et la panne du chemin racine.

Quand un mesh APX est adapté

Un mesh convient à une installation APX existante lorsqu’un point d’accès distant ne dispose pas d’Ethernet et que la liaison radio avec l’AP racine est suffisamment stable. Une petite zone d’entrepôt, une salle de réunion ou une zone temporaire qui sera câblée ultérieurement en sont des exemples typiques.

Un uplink Ethernet reste la meilleure base technique pour une capacité élevée durable, une latence stable et un failover prévisible. Le backhaul mesh partage le temps radio avec d’autres transmissions. Il faut donc mesurer les performances réelles avec les clients et applications prévus, au lieu de déduire la capacité utile de l’état de la liaison.

La limite du produit est également importante pour les nouvelles installations : APX est End-of-Sale et atteindra son End-of-Life le 31 décembre 2027. Il faut donc intégrer à la planification à moyen terme le cycle de vie APX et AP6 comme successeur. AP6 n’est pas géré par SFOS.

Comprendre le backhaul mesh, le SSID client et les rôles

Ces composants remplissent des fonctions différentes :

• Mesh network : backhaul radio masqué entre les APX. Le Mesh-ID identifie le groupe ; SFOS gère la phrase secrète WPA2 aléatoire.
• AP racine : APX disposant d’une connexion Ethernet au firewall. Pour APX, ce rôle découle automatiquement du câblage.
• AP mesh : APX sans uplink Ethernet qui atteint l’AP racine par radio.
• Wireless Network : SSID client visible avec Security mode, Client traffic, DHCP et règles. La base complète est décrite dans Configurer le WLAN directement sur Sophos Firewall.

Avec les anciennes séries d’AP Sophos, les rôles racine et mesh doivent être affectés explicitement. Cet article utilise uniquement APX et ne reprend donc pas cet ancien écran de rôles dans les étapes d’exemple.

Répéteur ou wireless bridge

En mode répéteur, l’AP mesh diffuse le SSID client affecté à l’emplacement distant. Les terminaux se connectent en Wi-Fi et l’AP transporte leurs données vers l’AP racine via le backhaul mesh.

Avec un wireless bridge, un segment Ethernet est également connecté au port réseau de l’AP mesh. Cette conception étend Layer 2 et peut créer des boucles s’il existe simultanément un deuxième chemin câblé. Elle doit donc être mise en oeuvre pendant une fenêtre de maintenance avec un chemin de récupération documenté. STP doit correspondre à l’ensemble de la conception des switches et bridges ; il n’est pas désactivé simplement parce qu’un chemin est bloqué.

Le mode répéteur est plus lisible pour la plupart des petites extensions. Un bridge ne doit être utilisé que si le segment Ethernet distant est réellement nécessaire et si son comportement de broadcast, VLAN et boucles est compris.

Vérifier les limites avant la configuration

Un mesh APX présente des limites produit claires :

• Tous les access points participants doivent appartenir à la série APX.
• Un seul réseau mesh peut être utilisé par AP.
• Au moins un APX doit rester connecté au firewall par LAN.
• Tous les AP mesh utilisent le même canal sur la bande mesh.
• Dynamic Channel Selection, ou Dyn chan, ne doit pas être actif sur cette bande, car les AP pourraient se retrouver sur des canaux différents après un redémarrage.
• Avec APX, les deux radios ne doivent pas être configurées simultanément sur 5 GHz lorsque le mesh est utilisé.
• Les AP auxquels un VLAN est affecté ne peuvent former un mesh que si les VLAN n’utilisent pas le mode Client traffic Bridge to VLAN.
• Un deuxième réseau mesh sur le même AP ne fonctionne pas.
• La panne de l’AP racine n’est pas reprise automatiquement et sans interruption par un autre AP mesh.

L’aide Sophos actuelle cite 2.4 GHz pour le backhaul mesh et 5 GHz pour les SSID clients comme point de départ possible. Ce n’est pas une pratique universelle. La distance, les murs, les interférences, les canaux disponibles, le Country réglementaire et la capacité nécessaire déterminent la conception réelle.

Planifier la topologie d’exemple

L’exemple utilise ces noms :

• Firewall : fw01
• APX câblé : ap-office-root
• APX sans fil : ap-warehouse-mesh
• Mesh-ID : OfficeMesh
• Wireless Network visible : Company WiFi
• Bande mesh : 2.4 GHz
• Canal mesh : un canal fixe testé sur le site

OfficeMesh est un exemple de documentation et doit être remplacé par un nom court et unique pour l’installation. Le Mesh-ID ne doit pas être confondu avec le SSID visible. Dans l’exemple, Company WiFi existe déjà avec les bons Client traffic, DHCP, règles firewall et NAT.

Avant le changement, préparer une sauvegarde actuelle de la configuration, un accès de gestion câblé et un plan de rollback. Les deux APX reçoivent du PoE et sont testés, pour leur configuration initiale, à portée de leur emplacement définitif. L’AP racine doit y rester accessible par Ethernet.

Préparer les access points et le canal radio

Provisionner d’abord les deux APX par LAN

1. Connecter ap-office-root et ap-warehouse-mesh par Ethernet au réseau de gestion prévu.
2. Sous Wireless > Wireless settings, vérifier que Wireless Protection est actif et que la zone de gestion est autorisée sous Allowed zone.
3. Sous Wireless > Access points, accepter les deux APX pending avec Accept.
4. Définir le bon Country pour les deux APX. Après une modification de Country, enregistrer et redémarrer les APX de manière contrôlée afin de mettre à jour la liste des canaux.
5. Vérifier que les deux APX sont actifs et ont reçu leur configuration actuelle.

Le câblage initial n’est pas un confort facultatif. Un APX qui n’a pas reçu la configuration mesh ne peut pas ensuite rejoindre le groupe uniquement par radio.

Avant le déploiement, il faut également planifier la version du firmware APX au moyen des Pattern updates de Sophos Firewall. Une mise à jour de firmware et la bascule mesh ne doivent pas se dérouler simultanément sans contrôle.

Définir un canal fixe commun

1. Sous Wireless > Access points, ouvrir le premier APX.
2. Sous Advanced settings, définir pour la bande mesh choisie un canal fixe testé localement.
3. Désactiver Dyn chan pour cette bande.
4. Appliquer le même réglage au deuxième APX.
5. Dans la mesure du possible, placer les AP proches qui ne font pas partie du mesh sur un autre canal peu perturbé.

Un canal n’est pas choisi simplement parce qu’il fonctionne bien dans l’exemple. Un scan local, les exigences Country et l’occupation des canaux voisins déterminent le choix. Après chaque changement de canal, les deux AP mesh doivent à nouveau afficher la même valeur.

Créer le Wireless Mesh dans SFOS

Créer le réseau mesh

1. Ouvrir Wireless > Mesh networks.
2. Sélectionner Add.
3. Saisir OfficeMesh comme Mesh-ID.
4. Sous Frequency band, sélectionner la bande commune planifiée, 2.4 GHz dans l’exemple.
5. Ajouter ap-office-root et ap-warehouse-mesh.
6. Enregistrer.

Avec APX, aucun rôle ne doit être attribué manuellement dans cette procédure. Tant que les deux APX sont encore câblés, ils reçoivent d’abord la configuration. Après la déconnexion ultérieure de ap-warehouse-mesh, ap-office-root reste l’AP racine grâce à sa connexion Ethernet.

Affecter le SSID client visible

Le réseau mesh n’est pas visible pour les terminaux. Il faut donc aussi affecter Company WiFi aux deux APX sous Wireless > Access points ou au moyen d’un Access Point Group adapté.

Le SSID client conserve son propre Security mode et Client traffic. Avec Separate zone, Wireless interface, DHCP, règle firewall, NAT et Device Access doivent notamment être corrects. Un mesh fonctionnel ne corrige pas une règle WLAN manquante ni un chemin DHCP erroné.

Déplacer l’AP mesh à son emplacement

1. Vérifier que la configuration et le SSID client visible ont atteint les deux APX.
2. Redémarrer les deux APX de manière contrôlée.
3. Retirer le câble Ethernet uniquement de ap-warehouse-mesh.
4. Laisser ap-office-root câblé.
5. Placer l’AP mesh à l’emplacement prévu et l’allumer.
6. Attendre jusqu’à cinq minutes avant de considérer la connexion comme défaillante.

Un seul APX reste connecté au LAN pendant le fonctionnement mesh normal. Si le deuxième APX est lui aussi relié par erreur au même réseau Layer 2, vérifier la conception pour détecter les boucles et contrôler l’effet de STP.

Valider le Wireless Mesh de manière contrôlée

La validation associe l’état du contrôleur, le chemin radio et un trafic utilisateur réel :

1. Sous Wireless > Access points, les deux APX doivent être actifs. ap-office-root reste câblé ; ap-warehouse-mesh est joignable sans Ethernet.
2. Vérifier l’affectation mesh et le canal identique sur les deux APX.
3. Connecter un client de test proche de ap-warehouse-mesh à Company WiFi.
4. Sous Wireless > Wireless client list, vérifier que le client est associé à l’AP mesh attendu.
5. Comparer l’adresse IP, la gateway et le DNS du client au Wireless Network planifié.
6. Tester une destination autorisée et une destination volontairement bloquée.
7. Dans Log Viewer, filtrer sur l’IP du client et vérifier les Firewall Rule ID et NAT Rule ID attendus.
8. Effectuer un test réaliste de débit et de latence et le comparer à un client connecté à l’AP racine.

Un état vert de l’AP ne confirme pas encore le chemin de données complet. Le succès signifie que le client utilise le bon AP, la bonne adresse et les règles prévues, et que les performances suffisent à l’application. La procédure générale est expliquée dans Tester correctement les règles firewall.

Tester volontairement la limite de panne

L’AP racine est une dépendance connue. Pendant une fenêtre de maintenance, on peut déconnecter brièvement son uplink et documenter la durée de l’interruption des accès clients. SFOS ne promet aucun changement automatique de root. Un AP mesh peut devoir être redémarré et câblé pour établir un nouveau rôle.

Ce test ne justifie pas l’arrêt non planifié d’un AP racine en production. Pour les zones critiques, prévoir un uplink AP câblé ou une autre architecture WLAN.

Diagnostiquer selon le symptôme

L’AP mesh n’apparaît pas ou reste offline

Après la configuration, attendre jusqu’à cinq minutes. Si l’AP reste offline, vérifier d’abord qu’il était actif lors du provisionnement initial par LAN et qu’il a reçu la configuration mesh. Contrôler ensuite la série APX, l’affectation mesh, la bande, le canal commun, Dyn chan, Country et l’alimentation.

L’AP racine doit rester câblé. Si les deux AP sont sans fil ou si le mauvais AP a été déconnecté d’Ethernet, le chemin vers le firewall manque. Après correction, redémarrer les APX de manière contrôlée et attendre à nouveau.

Le SSID client n’est pas visible

Le Mesh-ID n’est volontairement pas diffusé comme SSID client. Sous Wireless > Access points, un Wireless Network visible supplémentaire doit être affecté à l’AP mesh. Si seul OfficeMesh est configuré, les terminaux ne disposent d’aucun réseau visible.

Vérifier aussi Frequency band, le calendrier, Security mode et l’affectation AP du SSID client. Un deuxième réseau mesh sur le même AP n’est pas une solution, car un seul mesh est pris en charge par AP.

Le client se connecte mais ne reçoit pas d’adresse IP

Le chemin radio fonctionne alors déjà au moins en partie. Vérifier ensuite Client traffic, Wireless interface, serveur DHCP ou DHCP relay et les éventuels chemins VLAN. Avec Bridge to VLAN, tenir également compte de la limite mesh : les AP auxquels des VLAN sont affectés ne peuvent former un mesh que si les VLAN n’utilisent pas ce mode Client traffic.

Le redémarrage du service wireless n’est pas une étape standard. Il faut d’abord établir à quel AP le client est connecté et si les requêtes DHCP empruntent le chemin attendu.

Le client possède une adresse IP mais pas d’accès Internet

Dans Log Viewer, rechercher d’abord les Firewall Rule ID et NAT Rule ID attendus. Si les deux manquent, le problème concerne plus probablement la zone, l’objet réseau, l’ordre des règles ou le chemin de données que le mesh lui-même. Si les règles correspondent, vérifier ensuite le DNS, la gateway et le chemin WAN.

Une règle Any large n’est pas un diagnostic mesh. Effectuer le même test client une fois sur l’AP racine et une fois sur l’AP mesh. S’il ne fonctionne que sur l’AP racine, poursuivre l’analyse du backhaul ; s’il échoue sur les deux AP, l’erreur appartient probablement à la configuration WLAN ou firewall commune.

La connexion est instable ou lente

Vérifier le même canal sur tous les AP mesh, Dyn chan désactivé, la qualité du signal, les interférences, la distance et les murs. Les AP qui ne font pas partie du mesh ne doivent pas occuper inutilement le même canal. Il doit également rester assez de capacité radio pour le backhaul et les clients.

Comparer les performances avec la même application, le même client et des conditions aussi similaires que possible sur l’AP racine et l’AP mesh. Cela permet de séparer le chemin mesh d’un problème général WAN, DNS ou client.

L’état du contrôleur ou du client reste incertain

Les logs de service Sophos Firewall aident au diagnostic local du noeud. Ces contrôles en lecture seule sont utiles dans l’Advanced Shell :

tail -n 200 /log/awed.log
tail -n 200 /log/wc_remote.log

awed.log montre la communication du contrôleur et des APX ; wc_remote.log aide pour les clients wireless. Une entrée de log isolée ne prouve pas le chemin du trafic. Les horodatages, l’état des AP, la liste des clients, les logs firewall et un test reproductible doivent être corrélés. Les LED et codes de clignotement des Sophos Access Points aident aussi à interpréter les états de démarrage, de mise à jour et de mesh sur l’appareil.

Revenir en arrière en toute sécurité

Le rollback s’effectue de manière contrôlée tant que l’accès de gestion câblé fonctionne :

1. Documenter quel APX est le root et lequel est l’AP mesh.
2. Reconnecter l’AP mesh par LAN au réseau de gestion et attendre qu’il soit actif.
3. Si nécessaire, déplacer le SSID client visible vers un AP câblé restant.
4. Retirer le réseau mesh des APX ou le supprimer sous Wireless > Mesh networks.
5. Ne rétablir les anciens réglages de canal et Dyn chan que de manière consciente.
6. Redémarrer les deux APX de manière contrôlée.
7. Vérifier à nouveau l’IP client, le DNS, les règles et l’accès Internet.

Une réinitialisation d’usine n’est utile que si l’APX n’accepte plus de configuration gérée malgré un câblage, une alimentation et un chemin vers le contrôleur corrects. Elle ne remplace pas un rollback documenté.

Checklist d’exploitation

• Tous les appareils participants sont des APX compatibles et ont d’abord été provisionnés par LAN.
• Un seul réseau mesh est affecté par AP.
• Un APX reste câblé en permanence comme root.
• La bande mesh et le canal fixe sont identiques sur tous les APX participants.
• Dyn chan est désactivé sur la bande mesh.
• Le SSID client visible est affecté séparément.
• DHCP, Firewall Rule ID, NAT Rule ID et une destination bloquée ont été testés.
• Les performances et la stabilité ont été comparées sur l’AP racine et l’AP mesh.
• La panne du root, l’absence de takeover automatique et le rollback sont documentés.
• L’End-of-Life APX et un changement ultérieur de plateforme WLAN sont planifiés.

FAQ