Aller au contenu
Avanet

Diagnostiquer le Wireless Controller du Sophos Firewall en CLI

Sophos Firewall

Sous SFOS 22, exécutez system wireless-controller dans 4. Device Console. Consultez séparément les logs de dépannage dans 5. Device Management > 3. Advanced Shell. Commencez par des contrôles en lecture seule et n’activez Remote Packet Capture qu’après avoir isolé le problème sur un point d’accès et un client de test.

⚠️ Confidentialité et exploitation : Une capture Wi-Fi peut contenir trafic utilisateur, adresses IP, requêtes DNS et données d’authentification ou de session. Utilisez un filtre étroit, capturez un seul test court et reproductible, puis protégez le fichier exporté. Notez la valeur initiale exacte avant chaque changement.

Ce guide repose sur l’aide publique de SFOS 22. Les commandes n’ont pas été exécutées sur un Sophos Firewall pour cet article : confirmez donc la syntaxe et le résultat observé sur le build installé.

Ouvrir la bonne console

La CLI est accessible localement par câble console, à distance par SSH ou via admin > Console dans WebAdmin. Pour SSH, autorisez SSH pour la zone requise sous Administration > Device access > Local service ACL. admin > Console exige l’accès HTTPS pour cette zone. Si possible, limitez l’administration aux postes prévus avec une Local service ACL exception rule.

Après connexion, choisissez 4. Device Console. Dans ce contexte, ? affiche les arguments disponibles et leur description pour une commande commencée. system wireless-controller est une commande de Device Console. Advanced Shell est un environnement distinct, utilisé ci-dessous uniquement pour la consultation documentée des logs en lecture seule; il n’est pas interchangeable avec Device Console.

Relever l’état initial et le symptôme

Vérifiez d’abord les branches proposées par le build installé, puis lisez les valeurs actuelles :

system wireless-controller ?
system wireless-controller ap_localdebuglevel get
system wireless-controller global show
system wireless-controller remote_pktcap show <AP_serial_number>

Remplacez <AP_serial_number> par le numéro de série de l’AP concerné, sans saisir les chevrons. Relevez également le build SFOS, le modèle et le firmware AP, le SSID, la bande, le canal, sa largeur, les adresses MAC et IP du client de test, l’heure et un symptôme exactement reproductible. Dans un cluster HA, notez le nœud auquel vous êtes connecté. Après un failover, ne répétez pas aveuglément le diagnostic sur les deux nœuds.

Un état normal du contrôleur confirme uniquement le plan de contrôle. Il ne prouve ni l’association du client, ni DHCP, DNS, l’authentification ou le chemin de données.

Contrôler d’abord WebAdmin et les bons logs

Sous Wireless > Access points, vérifiez que l’AP est actif et que son modèle et son numéro de série correspondent. Sophos Firewall gère les AP sur le port 2712. Si un AP est absent ou inactif, contrôlez d’abord zone, VLAN, port de switch, adressage et chemin vers ce port. Accepter un AP inconnu n’est pas un test : confirmez modèle, numéro de série, emplacement et réseau de management avant Accept.

L’aide SFOS 22 associe les fichiers suivants aux incidents Wi-Fi :

  • awed.log : communication entre AP ou APX et firewall
  • wc_remote.log : communication d’un client Wi-Fi avec AP ou APX
  • hostapd.log : événements SSID pour LocalWifi
  • hotspotd.log : événements de hotspot

SFOS 22 documente officiellement tail -f, grep et less pour lire les logs de dépannage dans 5. Device Management > 3. Advanced Shell. La syntaxe générique documentée permet ces exemples volontairement ciblés :

tail -f /log/awed.log
grep '<AP_serial_number>' /log/awed.log
grep '<client_MAC_address>' /log/wc_remote.log
less /log/hostapd.log

Remplacez chaque paramètre fictif par un seul identifiant exact, sans saisir les chevrons. N’exécutez tail -f que pendant la courte reproduction, puis arrêtez-le avec Ctrl+C; quittez less avec q. Ces commandes lisent chacune un fichier pertinent et ne remplacent pas les commandes Device Console ci-dessus. Les actions de service start, stop et restart, ainsi que les actions de debug, modifient l’état du système : ne les utilisez pas comme diagnostic général. Elles nécessitent un besoin propre au cas, un état initial consigné et un plan de rollback explicite. Si ces contrôles ne suffisent pas, activez un accès limité dans le temps sous Diagnostics > Support access et transmettez l’Access ID par le canal convenu.

Exécuter Remote Packet Capture sur un seul AP

remote_pktcap injecte les paquets de l’AP dans un Packet Capture exécuté simultanément sur le firewall. Sophos exige un ap_debuglevel global d’au moins 4. Le niveau de debug est global, tandis que la capture cible un numéro de série AP précis.

  1. Exécutez system wireless-controller global show et notez exactement ap_debuglevel. S’il vaut déjà 4 ou davantage, ne le modifiez pas.

  2. S’il est inférieur à 4, passez-le temporairement à 4, puis relisez l’état :

    system wireless-controller global ap_debuglevel 4
system wireless-controller global show

  3. Ouvrez Diagnostics > Packet capture, définissez un filtre étroit sur le client, la destination, le port ou le protocole, puis lancez Packet capture.

  4. Activez la capture AP et contrôlez son état :

    system wireless-controller remote_pktcap enable <AP_serial_number>
system wireless-controller remote_pktcap show <AP_serial_number>

  5. Générez uniquement le flux de test documenté. Packet capture affiche notamment interfaces entrante et sortante, Status, Reason et Firewall Rule ID. Ces champs indiquent si la trame atteint l’AP, est traitée par le firewall ou rejetée par une règle.

  6. Arrêtez d’abord la capture AP, puis Packet capture dans WebAdmin :

    system wireless-controller remote_pktcap disable <AP_serial_number>
system wireless-controller remote_pktcap show <AP_serial_number>

  7. Si vous avez modifié ap_debuglevel, restaurez et vérifiez la valeur relevée avant le test :

    system wireless-controller global ap_debuglevel <saved_ap_debuglevel>
system wireless-controller global show

Remplacez <saved_ap_debuglevel> par l’ancienne valeur exacte. La syntaxe documentée de Wireless Controller ne propose pas de branche reset pour ce paramètre : une valeur par défaut supposée n’est donc pas un rollback sûr.

Ne pas employer les autres paramètres comme remède global

Device Console liste d’autres paramètres globaux. Leurs plages sont documentées, mais leur effet opérationnel n’est pas toujours suffisamment expliqué :

  • ap_localdebuglevel : 0 à 15, lecture avec get, modification avec set
  • log_level : 0 à 7; les messages au niveau configuré ou supérieur sont écrits, donc une valeur plus haute ne signifie pas simplement « davantage de logs »
  • ap_autoaccept, stay_online et store_bss_stats : 0 désactivé, 1 activé
  • tunnel_id_offset : 0 à 65535

Ne modifiez pas ces valeurs préventivement et n’exécutez pas un bloc de changements. ap_autoaccept, notamment, supprime le contrôle volontaire lors de l’admission d’un AP. La page ne donne pas assez de contexte pour recommander généralement stay_online, store_bss_stats ou tunnel_id_offset. Utilisez-les seulement sur instruction spécifique de Sophos Support, sauvegardez la valeur avec global show et restaurez ensuite cette valeur exacte.

Retarder RADIUS Accounting Start uniquement si la cause est prouvée

radius_accounting_start_delay ne répond qu’à un problème d’ordre confirmé : 802.1X Accounting Start arrive avant l’attribution DHCP. Wi-Fi SSO ne peut alors reprendre aucune Framed-IP-Address exploitable du message. La plage documentée est de 0 à 60 secondes; Sophos utilise 30 secondes dans KBA-000006795.

Avant toute modification, prouvez la séquence par les logs RADIUS et une capture, puis sauvegardez la valeur avec global show. La procédure complète figure dans Contrôler RADIUS SSO et Accounting. Après le test, exécutez system wireless-controller global radius_accounting_start_delay <saved_delay> avec l’ancienne valeur exacte, puis vérifiez-la avec global show.

La largeur de canal est une configuration, pas un diagnostic

Sophos documente 20 et 40 MHz pour 2,4 GHz, puis 20, 40 et 80 MHz pour 5 GHz. La page CLI écrit par erreur 2.5GHz à un endroit. Ne copiez pas ce token aveuglément. La branche CLI documentée ne fournit pas non plus de commande de lecture ou de reset distincte. Sans état initial sauvegardé et syntaxe confirmée, ce n’est pas une étape de diagnostic à copier-coller.

Planifiez la largeur de canal dans la configuration Wireless Network normale de WebAdmin. Occupation des canaux, réseaux voisins, signal, retransmissions, capacités client et densité du site déterminent si une largeur supérieure est utile.

Évaluer le résultat et terminer proprement

Après le diagnostic, vérifiez état AP, association du client, bail DHCP, résolution DNS, authentification, Firewall Rule ID attendue, pertes, latence et application concernée. Pour RADIUS, contrôlez aussi Accounting Start, Framed-IP-Address et l’affectation utilisateur.

La procédure est terminée seulement lorsque remote_pktcap show n’indique plus de capture active pour l’AP, que Packet capture est arrêté dans WebAdmin et que global show contient les valeurs sauvegardées. Si la cause reste inconnue, conservez heure, numéro de série AP, client, capture et noms de logs pour Sophos Support au lieu d’essayer d’autres paramètres globaux.

Sources officielles

FAQ

Pourquoi Remote Packet Capture ne montre-t-il aucun paquet ?

Vérifiez que Packet capture fonctionne dans WebAdmin, que l’ap_debuglevel global vaut au moins 4, que le numéro de série AP est exact et que le filtre couvre le flux de test. Contrôlez ensuite les deux états au lieu d’augmenter le debug au hasard.

Puis-je exécuter les commandes Wireless Controller dans Advanced Shell ?

Non. Les commandes system wireless-controller montrées ici appartiennent à 4. Device Console. Utilisez Advanced Shell séparément pour les commandes documentées de lecture de logs indiquées plus haut. Les actions de service et de debug modifient l’état et exigent un besoin propre au cas ainsi qu’un plan de rollback.

Faut-il activer ap_autoaccept pour accélérer l'admission d'un AP ?

Pas pour dépanner. L’acceptation automatique supprime un contrôle. Vérifiez modèle, numéro de série, port de switch, emplacement et réseau de management, puis acceptez consciemment l’AP attendu dans WebAdmin.

Quel niveau de debug faut-il conserver après la capture ?

Pas automatiquement 0, ni nécessairement 4 : restaurez exactement la valeur relevée avant le test avec global show. Une nouvelle lecture de global show confirme le rollback.