Configurer et tester Wireless Mesh sur Sophos Firewall dans une installation APX existante

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.

Périmètre : exploitation d’une installation existante, et non création d’une nouvelle plateforme WLAN

Les étapes suivantes décrivent un mesh hérité géré par Sophos Firewall dans un ensemble APX existant, et non la mise en place d’une nouvelle plateforme APX ou UTM. Avant toute modification, la prise en charge du modèle d’AP concerné, de sa révision matérielle et du build SFOS réellement utilisé doit être confirmée. L’aide Wireless de SFOS 22 et SFOS 23 contient d’anciennes procédures mesh ; la présence d’une page d’aide ne prouve pas la prise en charge du matériel. En particulier, elle ne permet pas de conclure qu’une mise à niveau vers SFOS 23 est possible avec APX. Si la prise en charge n’est pas confirmée, conserver la configuration existante et clarifier d’abord la compatibilité modèle/build ainsi que la migration.

AP6-Mesh relève d’un autre mode de gestion : pour un ensemble AP6 géré de manière centralisée, la configuration s’effectue dans Sophos Fusion, anciennement Sophos Central, et non sous Wireless > Mesh networks sur le firewall. Une Sophos Firewall peut toujours servir de routeur et de frontière de sécurité sur le chemin des données, mais elle ne devient pas pour autant un contrôleur AP6. APX et AP6 ne doivent pas faire partie du même ensemble mesh. L’enregistrement et les prérequis réseau propres à ce mode de gestion sont décrits dans Prérequis de Sophos Central Wireless ; la planification détaillée, la configuration mesh et la validation figurent dans Planifier et configurer AP6-Mesh. Les rôles APX, les affectations de SSID et les étapes de retour arrière présentés ici ne s’appliquent pas à AP6.

Le modèle extérieur APX 320X ne relève pas de cette procédure gérée par Sophos Firewall. Les références à l’ancienne série d’AP Sophos et aux rôles manuels dans les anciens guides expliquent des installations historiques, et non une nouvelle installation prise en charge aujourd’hui. De même, LocalWiFi intégré et les modules Wi-Fi SD-RED ne peuvent pas remplacer les deux APX externes de l’exemple ; leurs prérequis WLAN et leur compatibilité matérielle doivent être vérifiés séparément. Cet article ne prolonge pas les procédures UTM et ne les recommande pas pour une nouvelle installation.

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, débrancher le câble LAN de l’AP mesh, redémarrer les APX 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.

Interpréter la divergence entre les documents : l’ancien guide de déploiement indique 5 GHz sur l’AP racine et 2.4 GHz sur l’AP mesh ; le guide d’ajout distingue quant à lui 5 GHz pour les SSID clients et 2.4 GHz pour le backhaul mesh. Ces formulations ne doivent pas conduire à utiliser des bandes de backhaul différentes sur l’AP racine et l’AP mesh. Dans la procédure documentée ici pour une installation existante, les deux AP doivent utiliser la même bande mesh choisie et le même canal fixe. La valeur 2.4 GHz de l’exemple n’est pas obligatoire ; avant d’utiliser une autre bande, vérifier sa prise en charge par le modèle et le build ainsi que le chemin radio. La restriction APX concernant la configuration simultanée des deux radios sur 5 GHz reste applicable.

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 un canal fixe testé localement dans le champ Channel 2.4 GHz ou Channel 5 GHz correspondant.
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

Pour le backhaul mesh, créer un nouveau réseau mesh dédié ou un nouveau SSID mesh dédié ; le SSID client visible existant Company WiFi ne doit pas être converti en réseau mesh. L’aide emploie à ce sujet les termes Mesh-ID et mesh-enabled SSID. Si l’interface existante ne propose Enable mesh mode que lors de la création d’un nouveau SSID, n’utiliser cette procédure héritée documentée que sur un modèle et un build dont la prise en charge est confirmée, et conserver un SSID client distinct. Un seul réseau mesh est prévu par AP. Tous les AP participants doivent recevoir le même Mesh-ID ; ils partagent la phrase secrète WPA2-Personal générée aléatoirement par SFOS. Il ne s’agit pas de la phrase secrète du WLAN client.

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. Retirer le câble Ethernet uniquement de ap-warehouse-mesh.
3. Laisser ap-office-root câblé.
4. Placer l’AP mesh à l’emplacement prévu et l’allumer ; il démarre alors sans Ethernet.
5. Redémarrer l’AP racine de manière contrôlée. Si le déplacement de l’AP mesh ne l’a pas mis hors tension, le redémarrer également à ce stade.
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, afficher le client de test par AP ou par SSID et vérifier qu’il est connecté à l’AP mesh attendu et à Company WiFi. Noter la puissance du signal et la fréquence, puis refaire ces vérifications dans des conditions similaires lors de la comparaison avec l’AP racine ; la fréquence affichée pour le client ne prouve pas à elle seule la bande utilisée par le backhaul.
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.

Situer correctement l’objet Mesh dans l’API XML

Les références XML pour SFOS 22 et 23 décrivent Add Mesh Networks et Update Mesh Networks pour l’objet WirelessMeshNetworks. Il s’agit d’une structure d’objet documentée, et non d’une prise en charge matérielle supplémentaire : le périmètre limité aux APX existants, la vérification du modèle et du build ainsi que la voie de gestion distincte des AP6 décrits ci-dessus restent inchangés. La protection de l’accès, les opérations explicites, les réponses XML et les nouvelles tentatives sûres sont expliquées dans Sécuriser l’accès à l’API XML de Sophos Firewall.

Distinguer MeshID, bande et rôle de l’AP

Pour préparer une automatisation, il faut distinguer les champs suivants :

• MeshID est une chaîne scalaire obligatoire de dix caractères au maximum. OfficeMesh convient comme nom d’exemple court ; il reste l’identifiant du backhaul, et non le SSID visible par les clients. Ne pas interpréter le marqueur de référence supplémentaire APINTERFACENAME comme une règle de caractères explicite en soi ni comme une identité d’AP ; confirmer la syntaxe autorisée dans le build installé.
• FrequencyBand est obligatoire et autorise exactement 5GHz ou 2.4GHz. Le tableau indique 5 GHz comme valeur par défaut documentée, et non comme recommandation pour chaque liaison radio. La notation combinée 5GHz/2.4GHz dans l’exemple de référence ne figure pas dans la liste des valeurs autorisées et n’est pas reprise comme valeur unique du champ. Tous les AP concernés doivent toujours utiliser la même bande de backhaul confirmée et le même canal fixe ; Dyn chan reste désactivé sur cette bande.
• Description est une chaîne scalaire facultative. Un élément vide dans l’exemple ne démontre pas comment une mise à jour traite une description existante.
• AccessPoints contient MeshNetwork dans l’exemple XML ; AccessPoint et Role y figurent ensemble. Le tableau des paramètres décrit ces deux champs comme des tableaux facultatifs à plusieurs valeurs et précise que les doublons ne sont pas ignorés. N’en déduire ni deux listes pouvant être triées indépendamment à volonté, ni une déduplication automatique. Vérifier conjointement l’identité de l’AP et le rôle associé par rapport à la configuration existante et à API help du build.
• Pour Role, les valeurs documentées sont exactement MeshAccessPoint et RootAccessPoint ; le tableau indique Root Access Point comme valeur par défaut. Ces valeurs XML proviennent de la référence de l’API, et non des termes Root, Mesh ou Repeater de l’interface graphique. En particulier, l’attribution automatique des rôles APX via Ethernet ne prouve pas si Role doit être défini, omis ou traité autrement dans le payload APX concerné. Si la correspondance avec le modèle et le build n’est pas clarifiée, ne pas envoyer de requête d’écriture.

L’extrait limité de structure XML suivant n’est ni une requête exécutable ni une attribution de rôle APX. Il montre uniquement l’imbrication documentée avec une valeur de référence pour Role ; AP_IDENTITAET_AUS_API_HELP est un espace réservé qui ne doit pas être envoyé. L’identité AP30 de l’exemple du fabricant n’est pas reprise comme exemple APX :

<WirelessMeshNetworks>
  <MeshID>OfficeMesh</MeshID>
  <FrequencyBand>2.4GHz</FrequencyBand>
  <Description />
  <AccessPoints>
    <MeshNetwork>
      <AccessPoint>AP_IDENTITAET_AUS_API_HELP</AccessPoint>
      <Role>RootAccessPoint</Role>
    </MeshNetwork>
  </AccessPoints>
</WirelessMeshNetworks>

Avant toute modification, relire et sauvegarder la configuration Mesh effectivement enregistrée, avec l’identifiant Mesh, les identités des AP, les affectations et les paramètres radio, puis la comparer à l’état cible prévu. L’extrait ne contient ni authentification ni opération et ne remplace pas un payload complet confirmé. La structure XML ne garantit ni une nouvelle tentative sûre ni une liaison radio fonctionnelle ; la validation distincte de l’état des AP, du SSID client, du DHCP et du chemin des données utilisateur reste nécessaire.

Distinguer les réponses selon l’opération, le code et le symbole

Les références associent aux deux opérations les codes d’état XML et les clés littérales Message.* suivants. Les clés ne sont pas résolues : elles ne constituent pas des messages d’exécution confirmés et ne sont pas traduites en prétendus textes de messages d’erreur. La correspondance propre à l’objet doit être vérifiée avec API help du build installé ; en particulier, ne pas interpréter ici 521 et 522 uniquement à partir du tableau général des états de l’article central sur l’API.

Add Mesh Networks :

• 200 : Message.WLANAPAddSuccessful.
• 500 : Message.WLANAPAddFailed.
• 501 : Message.WLANAPIPAlreadyInUsed.
• 504 : Message.WLANAPIntBaseVHExist.
• 521 : Message.WLANAPAddRunConfigFailed.
• 522 : Message.WLANAccessPointUnbound.

Update Mesh Networks :

• 200 : Message.WLANAPEditSuccessful.
• 500 : Message.WLANAPEditFailed.
• 501 : Message.WLANAPIPAlreadyInUsed.
• 504 : Message.WLANAPIntBaseVHExist.
• 511 : Message.WLANAPFailedWhileUnbinding.
• 512 : Message.WLANAPFailedWhileDeleteDHCPServer.
• 513 : Message.WLANAPFailedWhileDeleteDHCPRelay.
• 516 : Message.WLANAPFailedToUnbindInterface.
• 520 : Message.WLANAPFailedToUnbindIfaceRCg.
• 521 : Message.WLANAPEditRunConfigFailed.
• 523 : Message.WLANAPWLAN1UnboundEditFaild.
• 524 : Message.WLANAPOtherUnboundEditFaild.

L’orthographe Faild est elle aussi conservée exactement. Ne pas déduire des noms de symboles une cause avérée, l’annulation complète d’une modification ou la suppression déjà effectuée d’une dépendance DHCP ou d’interface. Après une réponse ambiguë ou un échec, comparer d’abord l’état Mesh et AP effectivement enregistré ainsi que les configurations Wireless, d’interface et DHCP dépendantes à l’état initial sauvegardé ; conserver la réponse expurgée et les journaux pour clarification. Ne décider d’une nouvelle modification qu’après clarification propre au build, sans répéter automatiquement le même Add ou Update. Même 200 ne remplace ni la relecture de l’objet cible ni la validation radio et client décrite ci-dessus.

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.

Si, dans une ancienne procédure, l’option Enable mesh mode n’apparaît pas pour un SSID existant, créer un nouveau SSID au lieu de réaffecter le SSID client visible. Si la cause reste incertaine, isoler le chemin pendant une fenêtre de maintenance en diffusant uniquement le réseau mesh sur l’AP racine et uniquement le SSID client visible sur le répéteur. Si le SSID client apparaît sur le répéteur, cela indique dans un premier temps que la configuration client est diffusée, mais ne prouve pas encore que le backhaul ou l’accès Internet fonctionne. Vérifier également que le répéteur est bien joignable sans uplink LAN, que le client de test apparaît dans la liste des clients de cet AP et que le chemin DHCP attendu ainsi que le chemin de données autorisé fonctionnent. Rétablir ensuite les affectations normales. Si le mesh reste inutilisable, vérifier si STP bloque la configuration mesh. Ne pas désactiver STP sans discernement : il empêche les boucles dans les topologies en bridge.

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é

Distinguer le SSID mesh du SSID client lors du retour arrière : l’ancienne aide décrit la désactivation par suppression du SSID mesh. Il s’agit de l’objet de configuration mesh correspondant, et non systématiquement du SSID client visible Company WiFi. Avant toute suppression, vérifier la correspondance entre le Mesh-ID, les affectations d’AP et les dépendances, sauvegarder l’état de la configuration et rendre les AP joignables par le chemin câblé prévu. La suppression du backhaul coupe la connexion des AP reliés sans fil ; supprimer un SSID client encore nécessaire déconnecterait en plus ses utilisateurs WLAN. Selon l’interface héritée, le retour arrière s’effectue via le réseau mesh ou son SSID mesh. Si la correspondance n’est pas clairement établie, ne rien supprimer sur la base d’une supposition : clarifier d’abord la configuration du modèle et du build concernés.

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