Sophos Firewall Wireless Controller per CLI diagnostizieren

Führe system wireless-controller in SFOS 22 unter 4. Device Console aus. Troubleshooting-Logs liest du separat unter 5. Device Management > 3. Advanced Shell. Beginne mit lesenden Prüfungen und aktiviere Remote Packet Capture erst, wenn das Fehlerbild auf einen bestimmten Access Point und einen Testclient eingegrenzt ist.

⚠️ Datenschutz und Betrieb: Ein Wireless Capture kann Nutztraffic, IP-Adressen, DNS-Anfragen sowie Authentifizierungs- und Sitzungsdaten enthalten. Verwende einen engen Filter, erfasse nur einen kurzen reproduzierbaren Test und schütze die exportierte Datei. Notiere vor jeder Änderung den exakten Ausgangswert.

Die Anleitung basiert auf der öffentlichen SFOS-22-Hilfe. Die Befehle wurden hier nicht auf einer Sophos Firewall ausgeführt; Syntax und beobachtete Ausgabe müssen deshalb auf dem installierten Build kontrolliert werden.

In die richtige Konsole wechseln

Die CLI ist lokal über ein Konsolenkabel, per SSH oder über admin > Console im WebAdmin erreichbar. Für SSH muss unter Administration > Device access > Local service ACL der Dienst SSH für die benötigte Zone freigegeben sein. Für admin > Console benötigt die Zone HTTPS-Zugriff. Beschränke den Verwaltungszugriff möglichst mit einer Local service ACL exception rule auf Administrationshosts.

Nach der Anmeldung wählst du 4. Device Console. Dort zeigt ? die Argumente eines angefangenen Befehls mit Beschreibung. system wireless-controller ist ein Device-Console-Befehl. Die Advanced Shell ist ein separater Ausführungsort, der unten nur für dokumentierte, lesende Logabfragen verwendet wird; sie ist nicht mit der Device Console austauschbar.

Ausgangszustand und Fehlerbild erfassen

Prüfe zuerst, welche Zweige der installierte Build anbietet, und lies die vorhandenen Werte aus:

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

Ersetze <AP_serial_number> durch die Seriennummer des betroffenen AP; die spitzen Klammern werden nicht eingegeben. Notiere zusätzlich SFOS-Build, AP-Modell und -Firmware, SSID, Band, Kanal, Kanalbreite, MAC- und IP-Adresse des Testclients, Uhrzeit und ein exakt reproduzierbares Symptom. In einem HA-Verbund hältst du auch fest, an welchem Node du angemeldet bist. Wiederhole die Diagnose nach einem Failover nicht ungeprüft auf beiden Nodes.

Ein unauffälliger Controllerstatus belegt nur den Steuerungszustand. Er beweist weder eine erfolgreiche Client-Assoziation noch DHCP, DNS, Authentifizierung oder den Datenpfad.

Erst WebAdmin und die passenden Logs prüfen

Kontrolliere unter Wireless > Access points, ob der AP als aktiv erscheint und ob Modell sowie Seriennummer stimmen. Sophos Firewall verwaltet Access Points über Port 2712. Fehlt ein AP oder bleibt er inaktiv, prüfe daher zuerst Zone, VLAN, Switchport, Adressierung und den Pfad zu diesem Port. Die Annahme eines unbekannten AP ist keine Diagnosemassnahme: Modell, Seriennummer, Standort und Managementnetz müssen vor Accept stimmen.

Die SFOS-22-Hilfe ordnet Wireless-Fehlern diese Logdateien zu:

• awed.log: Kommunikation zwischen AP beziehungsweise APX und der Firewall
• wc_remote.log: Kommunikation eines Wireless-Clients mit AP beziehungsweise APX
• hostapd.log: SSID-Ereignisse für LocalWifi
• hotspotd.log: Hotspot-Ereignisse

SFOS 22 dokumentiert tail -f, grep und less offiziell zum Lesen von Troubleshooting-Logs unter 5. Device Management > 3. Advanced Shell. Die allgemeine dokumentierte Syntax unterstützt diese gezielt begrenzten Beispiele:

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

Ersetze jeden Platzhalter durch genau eine Kennung und lasse die spitzen Klammern weg. Beobachte tail -f nur während des kurzen Reproduktionstests und beende es mit Ctrl+C; less verlässt du mit q. Diese Befehle lesen jeweils eine relevante Datei und ersetzen nicht die Device-Console-Befehle oben. Serviceaktionen wie start, stop und restart sowie Debugaktionen verändern den Systemzustand. Setze sie nicht als allgemeine Diagnose ein, sondern nur bei fallspezifischem Bedarf, mit dokumentiertem Ausgangswert und eindeutigem Rollback-Plan. Genügen diese Prüfungen nicht, aktiviere unter Diagnostics > Support access einen zeitlich begrenzten Zugang und übermittle die Access ID über den vereinbarten Supportkanal.

Remote Packet Capture auf genau einem AP

remote_pktcap leitet AP-Pakete in ein gleichzeitig laufendes Packet Capture der Firewall ein. Sophos verlangt dafür einen globalen ap_debuglevel von mindestens 4. Der Debuglevel ist global, der Capture-Aufruf verwendet dagegen eine konkrete AP-Seriennummer.

1. Lies system wireless-controller global show und notiere den exakten Wert von ap_debuglevel. Liegt er bereits bei 4 oder höher, ändere ihn nicht.

2. Liegt er unter 4, setze ihn temporär auf 4 und lies den Zustand erneut:

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

3. Öffne Diagnostics > Packet capture, setze einen engen Filter für den Testclient, das Ziel, den Port oder das Protokoll und starte Packet Capture.

4. Aktiviere die AP-Erfassung und kontrolliere den Status:

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

5. Erzeuge genau den dokumentierten Testflow. Packet Capture zeigt unter anderem ein- und ausgehende Schnittstelle, Status, Reason sowie Firewall Rule ID. Diese Angaben helfen zu unterscheiden, ob der Frame den AP erreicht, die Firewall ihn verarbeitet oder eine Policy ihn verwirft.

6. Beende zuerst die AP-Erfassung und danach Packet Capture im WebAdmin:

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

7. Falls du ap_debuglevel geändert hast, stelle den zuvor notierten Wert wieder her und prüfe ihn:

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

Ersetze <saved_ap_debuglevel> durch den exakten Vorwert. Die dokumentierte Wireless-Controller-Syntax bietet für diesen Parameter keinen reset-Zweig; ein vermuteter Default ist deshalb kein sicherer Rollback.

Andere Parameter nicht als Sammelfix verwenden

Die Device Console führt weitere globale Parameter auf. Ihre Zahlenbereiche sind dokumentiert, ihre betriebliche Wirkung aber nicht in jedem Fall ausreichend erklärt:

• ap_localdebuglevel: 0 bis 15; aktueller Wert mit get, Änderung mit set
• log_level: 0 bis 7; Meldungen ab dem konfigurierten Level werden geschrieben. Eine höhere Zahl bedeutet daher nicht pauschal „mehr Logging“.
• ap_autoaccept, stay_online und store_bss_stats: 0 aus, 1 ein
• tunnel_id_offset: 0 bis 65535

Ändere diese Werte nicht vorsorglich und führe keinen Block mit mehreren Änderungen aus. Insbesondere entfernt ap_autoaccept den bewussten Kontrollpunkt bei der AP-Annahme. Für stay_online, store_bss_stats und tunnel_id_offset nennt die Befehlsseite nicht genug Kontext für eine allgemeine Troubleshooting-Empfehlung. Verwende sie nur mit einer fallspezifischen Sophos-Support-Anweisung, sichere den Vorwert mit global show und stelle danach genau diesen Wert wieder her.

RADIUS Accounting Start gezielt verzögern

radius_accounting_start_delay ist nur für ein belegtes Reihenfolgeproblem gedacht: Der 802.1X Accounting Start trifft ein, bevor DHCP dem Client eine Adresse zugeteilt hat. Wi-Fi SSO kann dann keine brauchbare Framed-IP-Address aus der Accounting-Start-Nachricht übernehmen. Der dokumentierte Bereich beträgt 0 bis 60 Sekunden; Sophos zeigt in KBA-000006795 ein Beispiel mit 30 Sekunden.

Bevor du den Wert änderst, belege die Reihenfolge mit RADIUS-Logs und einem Capture und sichere den aktuellen Wert mit global show. Der vollständige Ablauf steht unter RADIUS SSO und Accounting prüfen. Nach dem Test setzt du mit system wireless-controller global radius_accounting_start_delay <saved_delay> den exakten Vorwert und kontrollierst ihn erneut mit global show.

Kanalbreite ist Konfiguration, nicht Diagnose

Sophos dokumentiert für 2,4 GHz Kanalbreiten von 20 und 40 MHz sowie für 5 GHz 20, 40 und 80 MHz. Die CLI-Seite schreibt an einer Stelle irrtümlich 2.5GHz. Kopiere diesen Token nicht blind. Der dokumentierte CLI-Zweig zeigt zudem keinen separaten Lese- oder Reset-Befehl für die Kanalbreite. Deshalb eignet er sich ohne gesicherten Ausgangswert und bestätigte Syntax nicht als Copy-and-paste-Diagnoseschritt.

Plane die Kanalbreite im normalen Wireless-Network-Setup im WebAdmin. Kanalbelegung, Nachbarnetze, Signal, Retransmits, Clientfähigkeiten und Standortdichte entscheiden, ob eine breitere Einstellung überhaupt hilft.

Ergebnis bewerten und sauber abschliessen

Prüfe nach der Diagnose AP-Status, Client-Assoziation, DHCP-Lease, DNS-Auflösung, Authentifizierung, erwartete Firewall Rule ID, Paketverlust, Latenz und die betroffene Anwendung. Bei RADIUS gehören Accounting Start, Framed-IP-Address und Benutzerzuordnung zur Abnahme.

Der Abschluss ist erst vollständig, wenn remote_pktcap show keine aktive Erfassung für den AP meldet, Packet Capture im WebAdmin beendet ist und global show die gesicherten Debug- und Parameterwerte zeigt. Bleibt die Ursache offen, sichere Uhrzeit, AP-Seriennummer, Testclient, Capture und relevante Lognamen für Sophos Support, statt weitere globale Werte auszuprobieren.

Offizielle Quellen

• SFOS 22: Wireless-controller commands
• SFOS 22: Accessing Command Line Console
• SFOS 22: Device console
• SFOS 22: Packet capture
• SFOS 22: Log files for troubleshooting
• SFOS 22: View troubleshooting log lines
• SFOS 22: Access points
• Sophos KBA-000006795: SSO for APX Wi-Fi users with RADIUS

FAQ