WLAN direkt auf Sophos Firewall einrichten und testen

Ein direkt auf der Sophos Firewall verwaltetes WLAN wird unter Wireless > Wireless networks angelegt. Die SSID allein genügt aber nicht: Der gewählte Traffic-Modus bestimmt, ob die Clients ein eigenes Netz erhalten, im AP-LAN landen oder in ein VLAN gebridged werden. Danach müssen DHCP, Firewall-Regeln, NAT und die Zuweisung an einen Access Point zusammenpassen.

⚠️ Wichtig: Diese Anleitung gilt nur für WLAN-Hardware, die direkt von Sophos Firewall verwaltet wird. AP6 Access Points lassen sich nicht über SFOS verwalten. Für mehrere AP6 ist Sophos Fusion (ehemals Sophos Central) der vorgesehene und empfohlene Verwaltungsweg; ein einzelner AP6 kann alternativ über seine lokale Oberfläche konfiguriert werden. Firewall-managed Wireless ist heute deshalb vor allem für bestehende APX-Installationen, integriertes LocalWiFi der Desktop-W-Modelle und unterstützte Wi-Fi-Module in Sophos Firewall oder SD-RED relevant. Firmware für die von SFOS verwalteten APX wird über die Pattern-Updates der Firewall bereitgestellt und bewusst installiert.

Diese Anleitung verwendet ein Gäste-WLAN mit Separate zone. Das ist ein verständliches Beispiel, weil Clientnetz, Regeln und erlaubte Ziele sauber vom internen LAN getrennt werden können.

Verwendet ein 802.1X-WLAN RADIUS und soll die Firewall Benutzer ohne zusätzliches Captive Portal erkennen, erklärt RADIUS SSO mit Accounting den getrennten Accounting-Pfad, die notwendige Framed-IP-Address und den Test unter Live users.

Kurzablauf:

1. Unter Wireless > Wireless settings Wireless Protection und die AP-Zone vorbereiten.
2. Den Access Point unter Wireless > Access points annehmen.
3. Unter Wireless > Wireless networks SSID, Sicherheit und Clientnetz anlegen.
4. Unter Network > DHCP sowie Rules and policies DHCP, Firewall-Regel und NAT ergänzen.
5. Das Wireless Network dem AP zuweisen und mit einem Testclient IP, DNS, Rule ID sowie unerwünschte interne Zugriffe kontrollieren.

Passt diese Anleitung zum Access Point?

SFOS 22 kann Indoor-Access-Points der APX-Serie, integriertes WLAN einer passenden XGS Appliance und kompatible Wi-Fi-Erweiterungsmodule in Sophos Firewall oder SD-RED verwalten. Bei externen APX betrifft dies APX 120, APX 320, APX 530 und APX 740. Das Outdoor-Modell APX 320X und die alte AP-Serie werden nicht direkt von einer aktuellen Sophos Firewall verwaltet.

AP6 gehört nicht in diesen Ablauf. AP6 wird über Sophos Fusion oder bei einem einzelnen Gerät über dessen lokale Oberfläche konfiguriert. Für die Fusion-Variante passen die Sophos Central Wireless Anforderungen.

Die lokale Wireless-Funktion gehört zur Sophos Firewall Base License. Ein kompatibler Access Point wird separat benötigt. APX ist allerdings bereits End-of-Sale und erreicht am 31. Dezember 2027 sein End-of-Life. Diese Anleitung hilft deshalb vor allem beim sicheren Betrieb bestehender APX-Installationen; für eine neue WLAN-Plattform sollte man das APX-End-of-Life und AP6 als Nachfolger oder auch andere aktuelle WLAN-Systeme einplanen.

Versionsgrenze: Die Wireless-Hilfe enthält entsprechende Abläufe sowohl unter SFOS 22 als auch unter SFOS 23. Das Vorhandensein einer SFOS-23-Hilfeseite beweist jedoch keine Unterstützung eines bestimmten APX-Modells auf SFOS 23. Die Hardware-Unterstützung muss unabhängig anhand des Retirement Calendar und der Support-Matrix bestätigt sein. Vor einem Upgrade deshalb Modell, Hardware-Revision und Ziel-Build anhand der Support-Matrix prüfen; bestehende APX nicht allein aufgrund dieser Anleitung auf SFOS 23 migrieren. Integriertes WLAN und SD-RED-Module müssen ebenfalls zum konkreten Modell und Build passen. Für neue externe Access Points gilt der oben verlinkte AP6-Verwaltungsweg, nicht dieser SFOS-APX-Ablauf.

Soll ein bestehender APX ohne Ethernetanschluss über einen verkabelten APX angebunden werden, führt Sophos Firewall Wireless Mesh einrichten und testen durch Root-AP, Funkkanal, versteckten Backhaul und die kontrollierte Abnahme.

SD-RED mit Wi-Fi-Modul: Die Wireless-Hilfe dokumentiert DHCP option 234 für die Kommunikation eines als Access Point eingesetzten SD-RED-Moduls mit der Sophos Firewall. Das ist weder das Client-DHCP des Gäste-WLANs noch eine allgemeine Vorgabe für APX oder AP6. Die Hilfe nennt dabei auch Sophos UTM; daraus folgt hier keine neue UTM-Installationsanleitung. Vor Änderungen Modulkompatibilität, Management-DHCP und den tatsächlich verwendeten Controller klären; keinen Optionswert aus einem anderen Gerätetyp übernehmen. Die SD-RED-Einrichtung ist der getrennte Ablauf für die Standortanbindung.

Den richtigen Client-Traffic-Modus wählen

Die Entscheidung unter Client traffic ist wichtiger als der Name der SSID. Damit wird festgelegt, ob sich die Clients im selben lokalen Netzsegment auf Layer 2 befinden, wer IP-Adressen verteilt und welcher Traffic überhaupt durch die Firewall läuft.

Separate zone

Separate zone erzeugt ein eigenes Wireless-Interface mit eigener IP-Adresse und einen VXLAN-Tunnel zwischen Access Point und Firewall. Die Clients erhalten ein eigenes Subnetz. Dadurch lassen sich Zugriffe pro WLAN mit gezielten WiFi-to-WAN- oder WiFi-to-LAN-Regeln steuern. Wie Zone, Interface und Netzobjekt dabei zusammenspielen, erklärt Sophos Firewall Zonen und Interfaces.

Dieser Modus passt gut für Gäste, IoT oder andere Netze, die vom internen LAN getrennt werden sollen. Ein Hotspot mit Captive Portal, Tagespasswort oder Voucher setzt ebenfalls Separate zone voraus. Der vollständige Ablauf mit Voucher-Definition, Portal und automatischer Regel steht unter Sophos Firewall Hotspot einrichten.

VXLAN verkleinert die nutzbare MTU. Bei grossen Paketen kann dies Fragmentierung oder Leistungseinbussen verursachen. Deshalb sollte man die MTU nicht vorsorglich auf einen pauschalen Wert ändern. Zuerst wird geprüft, ob nur grosse Transfers ausfallen oder TCP-Pakete wiederholt übertragen werden, sogenannte Retransmits; den kontrollierten Ablauf erklärt MTU und MSS auf Sophos Firewall prüfen.

Bridge to AP LAN

Bridge to AP LAN legt die WLAN-Clients in dasselbe Netz wie den Access Point. Ein vorhandener DHCP-Server dieses LANs verteilt die Clientadressen. Das ist bequem, bietet aber keine eigene Netzgrenze für Gäste oder unsichere Geräte.

Entscheidend ist der Datenpfad: Kommunikation innerhalb desselben Subnetzes kann direkt zwischen Client, AP und Switch laufen und die Sophos Firewall vollständig umgehen. Eine Firewall-Regel auf SFOS kann nur Traffic kontrollieren, der tatsächlich über die Firewall geroutet wird.

Soll beim integrierten WLAN nur eine bekannte Geräteliste zugelassen werden, legt man unter Hosts and services > MAC host eine MAC-Liste an. Anschliessend im Wireless Network unter Advanced settings > MAC filtering die Option Allow list wählen und diese Liste zuweisen. Die Passphrase muss zwischen 8 und 63 Zeichen lang sein. Bei der Abnahme verbindet man je ein eingetragenes und ein nicht eingetragenes Testgerät.

Eine MAC-Adresse lässt sich jedoch nachbilden. Die Allow list ist deshalb nur ein zusätzlicher Zugangsfilter und ersetzt weder WPA2 Personal mit AES beziehungsweise ein unterstütztes WPA3-Verfahren noch eine starke Passphrase und eine saubere Netztrennung.

Wird Bridge to AP LAN mit integriertem LocalWiFi verwendet, muss das WLAN zusätzlich mit dem kabelgebundenen LAN verbunden werden. Der richtige Weg hängt vom XGS Appliance-Modell ab:

• Gen.1 – XGS 87w, 107w, 116w, 126w und 136w: Unter Network > Interfaces > Add interface > Add bridge wird eine Bridge erstellt. Name ist der später änderbare Anzeigename mit höchstens 58 Zeichen; Hardware name darf höchstens 10 Zeichen aus A-Za-z0-9_ enthalten und ist nach dem Speichern unveränderbar. Das Wireless-Interface erhält unter Member interfaces die Zone WiFi, der gewünschte Ethernet-Port die Zone LAN. Bei Bedarf können weitere Ethernet-Ports Mitglied dieser Bridge sein.

  Anschliessend IPv4 configuration auswählen, die vorgesehene IPv4 address der Bridge im bestehenden LAN eintragen und die dazu passende Subnetzmaske wählen. Adresse und Maske stammen aus dem eigenen LAN-Adressplan, nicht aus dem späteren Separate-Zone-Gästenetz. Vor Save prüfen, dass die Adresse weder einem anderen Gerät noch gleichzeitig einem Member-Interface zugewiesen ist und nicht unreserviert im dynamischen DHCP-Bereich liegt. Den bestehenden Client-Gateway und DHCP-Adressplan nicht beiläufig ändern. Vor dem Umbau Backup, Port-Abhängigkeiten und einen unabhängigen Adminzugang prüfen; der Bridge-Interface-Ablauf erklärt diese gemeinsamen Prüfungen und reservierte Hardware-Namen. Dessen transparentes Inline-Beispiel ohne IP-Adresse ist ein anderer Einsatzfall: Dieser dokumentierte Gen.1-LocalWiFi-Ablauf verwendet eine Bridge-IPv4-Adresse, nicht jede Bridge benötigt jedoch eine IP-Adresse. Erst nach diesen Prüfungen mit Save speichern.

• Gen.2 – XGS 88w, 108w, 118w und 128w: Das Wireless-Interface darf nicht Mitglied einer physischen Bridge sein. Stattdessen unter Wireless > Access points > LocalWiFi > Advanced settings die Option Bridge to Ethernet aktivieren, genau einen Ethernet-Port wählen und die Zone auf LAN setzen.

  Für Bridge to Ethernet muss der gewählte physische Port eine IP-Adresse haben und darf weder WAN-Port noch Mitglied einer anderen Bridge sein. Ein VLAN-Interface lässt sich damit nicht an LocalWiFi bridgen; auch die Bridge-Zone darf nicht WAN sein. Die Funktion gilt nur für IPv4 und SSIDs vom Typ Bridge to AP LAN. SFOS verwendet den bestehenden DHCP-Server des Bridge-Ports; fehlt er, dokumentiert die Hilfe eine automatische Neuanlage. Vor dem Speichern daher auf einen bereits im LAN vorhandenen DHCP-Server prüfen und danach Server, Pool und Lease kontrollieren, damit keine konkurrierenden DHCP-Antworten entstehen. Beim Ausschalten wird die Bridge gelöscht und die Konfiguration auf das physische Interface zurückgeführt. Den Ausgangszustand deshalb vorher sichern und den Rückbau samt Adminzugang, LAN-DHCP und Clientverbindung in einem Wartungsfenster kontrollieren.

Ein externer APX benötigt diese zusätzliche LocalWiFi-Bridge nicht. Bei einem Hardwarewechsel lässt sich eine physische Wireless-Bridge von Gen.1 ausserdem nicht unverändert auf Gen.2 übernehmen. Die nötige Vorbereitung erklärt Sophos Firewall Backup und Restore.

Bridge to AP LAN sollte nur gewählt werden, wenn WLAN und kabelgebundenes LAN bewusst denselben Sicherheitsbereich bilden.

Für diesen LAN-Ablauf das Wireless Network nach Auswahl von Bridge to AP LAN, Sicherheit und MAC-Liste mit Save speichern. Unter Wireless > Access points > LocalWiFi das korrekte Country prüfen und unter Wireless networks > Add new item genau dieses Netzwerk zuweisen und speichern; das spätere Guest WiFi ist ein anderes, getrenntes Beispiel. Nach der Bridge-Konfiguration muss das eingetragene Testgerät verbinden können, das nicht eingetragene dagegen abgewiesen werden. Am zugelassenen Client eine Lease aus dem vorgesehenen LAN-Bereich, passende Subnetzmaske, den bisherigen Gateway und die vorgesehenen DNS-Server prüfen; die Lease auf dem tatsächlich zuständigen LAN-DHCP-Server kontrollieren. Namensauflösung und einen beabsichtigten Dienst auf einem kabelgebundenen LAN-Gerät testen. Bleibt die Lease aus, zuerst MAC-Zulassung, Netzwerkzuweisung, Bridge-Member und LAN-DHCP prüfen. Lokale LAN-Kommunikation ist hier beabsichtigt und kein Nachweis für Gästeisolation oder für einen von SFOS kontrollierten Datenpfad.

Bridge to VLAN

Bridge to VLAN trennt das Managementnetz des Access Points vom Client-VLAN. Der Switch-Port zum AP muss beide Netze als Trunk transportieren. Im WLAN-Profil bezeichnet Bridge to VLAN ID das Client-VLAN; bei Enterprise-Authentifizierung kann diese Client-VLAN-ID statisch oder über RADIUS mit statischem Fallback bestimmt werden.

Der AP sollte zunächst mindestens eine Minute über das ungetaggte Standard-LAN mit der Firewall verbunden sein, damit er seine Konfiguration erhält. Danach wird unter Wireless > Access points > AP > Advanced settings das VLAN tagging aktiviert und die AP VLAN ID für das Managementnetz eingetragen. Erst jetzt wird der Switch-Port als Trunk umgestellt. AP-Management-VLAN und Client-VLAN können unterschiedliche IDs verwenden. Sophos empfiehlt, Separate zone und VLAN-WLANs nicht auf demselben AP zu mischen. Für integriertes LocalWiFi0 steht AP-seitiges VLAN-Tagging nicht zur Verfügung.

Nach der Aktivierung versucht der AP während 60 Sekunden, per DHCP im konfigurierten Management-VLAN eine Adresse zu erhalten. Bleibt die Antwort aus, fällt er auf DHCP im ungetaggten LAN zurück. Das ist ein hilfreicher Recovery-Pfad, aber kein Erfolgskriterium: VLAN, Trunk und DHCP müssen so lange korrigiert werden, bis der AP wirklich über das geplante Management-VLAN online ist. Bei Bridge to VLAN erstellt SFOS das VLAN-Interface und die zugehörigen Firewall-Regeln automatisch. Diese Objekte werden kontrolliert, weil jeder AP für jede Zone ein eigenes Backend-Interface erzeugt und ein Design mit vielen APs und Zonen entsprechend stark wachsen kann.

Die Zone des Firewall-Interfaces für das AP-Management-VLAN muss unter Wireless > Wireless settings > Allowed zone zugelassen sein. Client-Traffic-Modus und AP-seitiges VLAN tagging müssen zusammenpassen: Für Bridge to VLAN ist AP-Tagging erforderlich; für Separate zone kann es ein- oder ausgeschaltet sein. Die ältere VLAN-Hilfe bezeichnet einen weiteren Fall als bridge to an access point VLAN und verlangt dort ausgeschaltetes AP-Tagging. Das ist keine zusätzliche aktuelle UI-Auswahl, die man aus diesem Wortlaut ableiten sollte. Für den hier beschriebenen ungetaggten Bridge to AP LAN-Ablauf AP-Tagging ausgeschaltet lassen; bei einem davon abweichenden Design die Kompatibilität auf dem tatsächlichen Modell und Build vor der Umstellung bestätigen.

Bridge to VLAN vermeidet den VXLAN-Pfad und ist für grössere, bereits sauber segmentierte WLAN-Umgebungen oft passender. Auch hier gilt: Verkehr innerhalb des Client-VLANs wird nicht automatisch von SFOS geprüft.

Beispielnetz vorbereiten

Das Beispiel verwendet diese Werte:

• Name in SFOS: Guest WiFi
• unveränderbarer Hardware name: GuestWiFi
• sichtbare SSID: Company Guest
• Security mode: WPA2 Personal
• Client traffic: Separate zone
• Zone: WiFi
• Clientnetz: 10.30.40.0/24
• Interface und Gateway: 10.30.40.1
• DHCP-Bereich: 10.30.40.100 bis 10.30.40.220
• Firewall-Regel: WiFi_Guest_to_WAN

10.30.40.0/24 ist ein Beispiel aus dem privaten Adressraum. Vor der Übernahme muss man ein freies Subnetz wählen, das sich weder mit LAN, VPN, RED, VLAN noch einem entfernten Standort überschneidet. Die erste nutzbare Adresse 10.30.40.1 gehört im Beispiel dem Wireless-Interface der Firewall und wird als Gateway verteilt.

Für bestehende APX-Geräte ist WPA2 Personal mit AES die sichere kompatible Basis. Eine lange, einmalige Passphrase gehört in den Passwortmanager und nicht in Tickets oder Screenshots. WPA3-Modi dokumentiert Sophos in SFOS 22 nur für das integrierte WLAN der Modelle XGS 88w, 108w, 118w und 128w; für APX sollte man WPA3 deshalb nicht einplanen.

Die Sicherheitsliste enthält auch No Encryption, WEP Open, ältere WPA- und WPA/WPA2-Mischmodi. Diese Einträge sind keine Empfehlung für ein neues oder erneuertes WLAN: kein unverschlüsseltes Gästeprofil und kein WEP-/TKIP-Fallback verwenden, sondern inkompatible Clients ersetzen oder getrennt migrieren. Bei XGS 88w, 108w, 118w und 128w lassen sich Profile mit TKIP oder AES/TKIP zwar speichern, aber nicht LocalWiFi0 zuweisen. Bei diesen Modellen den stärksten von allen vorgesehenen Clients unterstützten WPA3-Modus beziehungsweise WPA2 Personal mit AES wählen und die Verbindung tatsächlich testen.

SFOS-verwaltetes WLAN konfigurieren

1. Verbindung des Access Points erlauben

Bei einem externen APX sind Managementnetz und WLAN-Clientnetz zwei verschiedene Dinge. Der AP bezieht seine eigene Managementadresse per DHCP aus dem angeschlossenen Netz. Die späteren WLAN-Clients erhalten dagegen Adressen aus dem oben geplanten Netz 10.30.40.0/24.

1. Wireless > Wireless settings öffnen.
2. Enable wireless protection aktivieren.
3. Unter Allowed zone die Zone wählen, über welche der AP die Firewall erreicht. SFOS bietet dafür DMZ, LAN und WiFi an. Die Auswahl übernehmen und die Wireless-Einstellungen mit Apply speichern, bevor der AP angenommen wird.
4. Sicherstellen, dass der AP per DHCP eine Adresse, Gateway und DNS erhält. Eine statische Managementadresse lässt sich am AP nicht konfigurieren.
5. Prüfen, ob Port 2712 zwischen AP und Firewall nicht durch einen Switch, eine ACL oder ein zwischengeschaltetes Gerät blockiert wird.
6. Wireless > Access points öffnen und einen pending AP mit Accept annehmen.
7. Beim aktiven AP das korrekte Country setzen. Davon hängen die gesetzlich zulässigen Kanäle ab. Wird das Country eines APX geändert, die Einstellung speichern und den Access Point danach kontrolliert neu starten, damit die neue Kanalliste angewendet wird.

Bei einer Firewall mit zwei Wi-Fi-Karten wirkt eine Änderung von Country auf beide Karten und setzt beide Kanäle auf Auto. Vorher beide Radio-Konfigurationen dokumentieren und danach beide kontrollieren. Beim APX 320 müssen laut Hilfe beide Radios auf 5 GHz stehen, um alle verfügbaren 5-GHz-Kanäle aufzulisten; in Israel unterstützt Radio 0 jedoch nur 2.4 GHz. Die lokale Länderfreigabe hat Vorrang: keine andere Country-Auswahl verwenden, um Kanäle zu erzwingen.

Unter Wireless > Wireless settings > Advanced settings gibt Timeout die Minuten zwischen dem Offline-Gehen eines Access Points und der Timeout-Benachrichtigung an; nach dieser Zeit betrachtet SFOS den AP als inactive. Für eine kontrollierte Prüfung zuerst den bisherigen Wert notieren und nur einen Test-AP ohne produktive Clients in einem Wartungsfenster trennen. Nach Ablauf der testweise verkürzten, aber betrieblich sicheren Zeit müssen Benachrichtigung und Status inactive erscheinen. Danach den AP wieder verbinden, den Status active prüfen und den alten Timeout-Wert wiederherstellen.

Die Auswahl unter Allowed zone bezieht sich auf den Managementpfad des Access Points, nicht auf die spätere Zone der WLAN-Clients. Ist der AP noch an einer anderen Sophos Firewall oder Sophos Fusion registriert, muss er dort zuerst gelöscht werden. Ist das nicht möglich, muss man ihn auf Werkseinstellungen zurücksetzen. Für die geplante Stilllegung den eindeutig identifizierten AP zuerst aus dem Netzwerk entfernen, dann unter Wireless > Access points diesen AP auswählen und Delete verwenden. Vorher seine Identität prüfen; danach prüfen, dass sein Eintrag entfernt ist und die verbleibenden APs und SSIDs weiterhin funktionieren. Delete ist nicht das Entfernen einer WLAN-Zuweisung oder das Deaktivieren einer Gruppe; keinen produktiven AP versuchsweise zur Fehlersuche löschen.

Die Steuerverbindung über Port 2712 ist zwischen Firewall und Access Point mit AES verschlüsselt. Die Portfreigabe ersetzt trotzdem keine Begrenzung des AP-Managementnetzes auf die wirklich benötigte Zone.

2. Wireless Network anlegen

Unter Wireless > Wireless networks > Add werden die Beispielwerte eingetragen:

1. Name: Guest WiFi
2. Hardware name: GuestWiFi
3. SSID: Company Guest
4. Security mode: WPA2 Personal
5. Passphrase: eine lange, einmalige Passphrase
6. Client traffic: Separate zone
7. Zone: WiFi
8. IP address: 10.30.40.1
9. Netmask: /24

Der Hardware name darf höchstens zehn Zeichen aus Buchstaben, Zahlen und Unterstrich enthalten und lässt sich später nicht mehr ändern. Name unterstützt bis zu 58 Zeichen, die SSID 1 bis 32 druckbare ASCII-Zeichen. Beide können an die eigene Namenskonvention angepasst werden. Der Wireless-Name lässt sich später ändern und wird statt des Hardware name in anderen Einstellungen angezeigt. Für dieses Feld sind alle Zeichen ausser '"<>#%\/, erlaubt; diese Einschränkung nicht auf SSID, Hardware name oder Passphrase übertragen.

Unter Advanced settings sind für das Gäste-Beispiel diese Entscheidungen sinnvoll:

• Encryption: AES
• Frequency band: nur die vom eingesetzten Modell und seinen Funkmodulen unterstützten Bänder
• Client isolation: aktivieren, wenn direkte Verbindungen zwischen Gästen unerwünscht sind
• Hide SSID: deaktiviert lassen
• Fast transition: verwendet IEEE 802.11r und setzt WPA2 als Security mode voraus. APX unterstützt diese Funktion nicht. Nur auf kompatibler Nicht-APX-Hardware verwenden, nachdem Modell, SFOS-Build und Clients geprüft wurden; daraus folgt weder AP6-Unterstützung noch eine Freigabe für alle W-Modelle oder für WPA3.
• Time-based access: steuert die erlaubten Zugriffszeiten dieser SSID. Mit Add new item einen passenden Zeitplan auswählen oder einen eigenen erstellen. Die Aktivierung und Konfigurationsänderungen in einem geplanten Unterbrechungsfenster durchführen, weil die Aktivierung wie unten beschrieben hostapd neu startet und alle Clients des betroffenen APs trennt. Mit einem Testclient sowohl den vorgesehenen erlaubten als auch den gesperrten Zeitraum prüfen; dieser Zugriffszeitplan ist nicht der Zeitplan für Radio- oder Rogue-AP-Scans.

Client isolation blockiert nur direkte Kommunikation zwischen Clients derselben SSID auf demselben Radio. Es ersetzt keine Trennung über Zonen, VLANs und Firewall-Regeln über mehrere APs oder Funkmodule hinweg. Eine versteckte SSID ist ebenfalls keine Sicherheitskontrolle; sie unterdrückt nur die sichtbare Anzeige des Netzwerknamens.

Bei integriertem WLAN hängt gleichzeitiges Dual-Band von der Hardware ab. XGS 87w und 107w senden nur auf 2.4 GHz oder 5 GHz. XGS 116w, 126w und 136w benötigen für beide Bänder ein zweites Funkmodul. XGS 88w, 108w, 118w und 128w können beide Bänder ohne zusätzliches Modul gleichzeitig verwenden.

Beim Aktivieren eines Wireless-Zeitplans startet SFOS hostapd neu. Dadurch werden alle WLAN-Clients des betroffenen Access Points kurz getrennt, nicht nur die Clients dieser SSID. Die Geräte sollten sich automatisch wieder verbinden.

Soll zusätzlich ein bekanntes Gerät gesperrt werden, unter Hosts and services > MAC host > Add etwa Bad hosts mit Type: MAC list anlegen, die tatsächlich gesperrten MAC-Adressen eintragen und speichern. Im Gästeprofil unter Advanced settings > MAC filtering die Sperrlisten-Option wählen, diese MAC list zuweisen und das Wireless Network mit Save speichern. Die Separate-Zone-Hilfe nennt diese Option Blacklist; die Bezeichnung der Sperrliste im eingesetzten Build prüfen. Mit einem gesperrten und einem zugelassenen Testgerät kontrollieren, dass nur das gesperrte Gerät abgewiesen wird. Eine nachgebildete oder randomisierte MAC-Adresse kann diese Sperre umgehen: Sie beweist weder Malware-Erkennung noch ein sauberes Gerät und ersetzt keine Schutz-Policies oder Netztrennung. Allowed zone erlaubt den AP-Managementpfad; das Einschalten von Wireless Protection allein ist kein Nachweis einer Malware-Prüfung aller WLAN- oder LAN-Pakete.

Enterprise-WLAN und RADIUS separat abnehmen

Bei einem Wireless Network mit 802.1X wird der RADIUS-Server unter Wireless > Wireless settings ausgewählt. Der Access Point spricht dabei nicht direkt mit dem RADIUS-Server: Für Authentication kommuniziert er über Port 414 mit der Firewall, für Accounting über Port 417. Die Firewall leitet Accounting danach an den konfigurierten RADIUS-Port weiter, normalerweise 1813.

Für Enterprise-Authentifizierung den Wireless network Name als NAS ID verwenden, nicht automatisch die sichtbare SSID oder den Hardware name. Diese Werte können unterschiedlich sein. Die RADIUS-Policy auf diesen Namen abstimmen und im Authentifizierungslog eines Testclients kontrollieren, dass die erwartete NAS ID und Policy verwendet werden; Authentication und Accounting getrennt prüfen.

Accounting muss auf dem RADIUS-Server aktiv sein; Interim Accounting Updates werden in diesem Wireless-Pfad nicht unterstützt. Einen Secondary RADIUS server sollte man nicht als allgemeinen Failover einplanen: APX und Wi-Fi-fähige Geräte können nur den primären RADIUS-Server verwenden, und XGS Appliances unterstützen keinen sekundären RADIUS-Server für diesen Ablauf.

Für diesen SFOS-verwalteten Wireless-Pfad verlangen die Wireless-Einstellungen von SFOS 22 und 23 eine NAT-Zuordnung für die Access-Point-Netze, wenn der RADIUS-Server über einen IPsec-Tunnel mit der Firewall verbunden ist. Die Quell-IP muss auf genau die IP-Adresse der Firewall übersetzt werden, über die sie den RADIUS-Server erreicht. Gemeint sind die AP-Netze, nicht pauschal das WLAN-Clientnetz. Die Hilfe verweist auf die Shell-Konfiguration mit sys-traffic-nat, liefert an dieser Stelle aber keinen vollständigen ausführbaren Befehl. Daraus folgt kein allgemeines NAT-Erfordernis für andere RADIUS-Pfade.

Vor einer Änderung die genaue SFOS-Version mit Build, AP-Netze, tatsächlich verwendete Quelladresse, vorgesehene Firewall-IP für die Übersetzung, Tunnel und Traffic Selectors, Rückweg sowie RADIUS-Logs dokumentieren. Ohne für diesen Build und Datenpfad bestätigte Syntax keine Shell-Änderung vornehmen: Bei Sophos Support die unterstützte Shell, Parameter und einzusetzenden Adressen sowie Vorprüfung, Erfolgskontrolle und exakten Rückbau klären. Erst mit diesem bestätigten Ablauf in einem Wartungsfenster ändern; danach mit einem Testclient 802.1X-Authentifizierung und Accounting prüfen und die am RADIUS-Server beobachtete Quell-IP sowie den Antwortpfad mit den vorgesehenen Werten vergleichen. Bei Abweichungen nicht die Freigaben verbreitern, sondern die Belege mit Support prüfen und gegebenenfalls den bestätigten Rückbau verwenden.

Firewall-erzeugter Authentifizierungstraffic ist von weitergeleitetem Clienttraffic zu unterscheiden. Der Artikel zu IPsec-Routen für weitergeleiteten Traffic erklärt system ipsec_route und NAT für diesen Forwarding-Pfad; er enthält keinen sys-traffic-nat-Ablauf. Weder dessen DNAT/reflexives SNAT noch eine LAN-zu-VPN-Regel ersetzt die hier erforderliche Systemtraffic-NAT-Konfiguration.

Nach den allgemeinen und erweiterten Einstellungen sowie gegebenenfalls den Enterprise- und MAC-Filter-Einstellungen das Wireless Network mit Save speichern – auch wenn keine MAC-Sperrliste verwendet wird. Unter Wireless > Wireless networks prüfen, dass Guest WiFi mit den vorgesehenen Einstellungen erscheint. Erst danach den DHCP-Server auf diesem Interface anlegen und das Netzwerk wie unten beschrieben einem AP zuweisen. Unplugged vor der AP-Zuweisung ist dabei kein Grund, das Profil erneut oder mit einem anderen Traffic-Modus anzulegen.

3. DHCP für das Clientnetz ergänzen

Für Separate zone wird nicht automatisch ein vollständiger DHCP-Server für die Clients bereitgestellt. Unter Network > DHCP > Server > Add legt man deshalb beispielsweise diese Konfiguration an:

• Name: dhcp-wifi-guest
• Interface: Guest WiFi
• Dynamic IP lease: 10.30.40.100 bis 10.30.40.220
• Subnet mask: /24
• Gateway: Use interface IP as gateway
• DNS server: passend zur eigenen DNS-Architektur
• Conflict detection: aktiviert

Der Bereich liegt bewusst oberhalb der Interface-IP und lässt Platz für reservierte Adressen. Bei einem stark wechselnden Gäste-WLAN kann eine kürzere Lease als in einem stabilen Büronetz sinnvoll sein. Extrem kurze Leases erzeugen dagegen unnötig viele Erneuerungen.

Welche DNS-Server verteilt werden, ist eine Sicherheits- und Betriebsentscheidung. Interne AD-DNS-Server sollten Gästen nicht allein aus Bequemlichkeit zugänglich gemacht werden. Die vollständige Planung und Lease-Kontrolle erklärt Sophos Firewall als DHCP-Server einrichten.

4. Firewall-Regel, NAT und lokale Dienste prüfen

Unter Rules and policies > Firewall rules > Add firewall rule > New firewall rule wird eine Regel für den gewünschten Internetzugriff erstellt. Die vollständige Maske, Regelreihenfolge und Security Features erklärt der Artikel zu Sophos Firewall-Regeln.

• Rule name: WiFi_Guest_to_WAN
• Action: Accept
• Log firewall traffic: aktiviert
• Source zones: WiFi
• Source networks and devices: Netzwerkobjekt für 10.30.40.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: nur die für das Gäste-WLAN benötigten Dienste
• Security features: passende Web-, Application- und IPS-Policies nach Lizenz und Einsatzzweck

Ein sprechendes Netzwerkobjekt wie net_WiFi_Guest macht die Regel enger und verständlicher als Source networks: Any. Bei den Services hängt die Auswahl davon ab, ob DNS und NTP lokal auf der Firewall oder direkt extern genutzt werden. Eine pauschale Any-Freigabe ist bequem, erschwert aber die spätere Kontrolle.

Zusätzlich muss eine NAT-Regel den ausgehenden Traffic auf die WAN-Adresse übersetzen. Die vorhandene Default-SNAT-Regel mit MASQ deckt neue interne Netze häufig bereits ab, das sollte man aber im konkreten Regelwerk prüfen, statt eine zweite NAT-Regel auf Verdacht anzulegen. Den Zusammenhang erklärt NAT auf Sophos Firewall verstehen.

Eine WiFi-to-WAN-Regel verhindert nicht automatisch Zugriffe über bereits vorhandene breite WiFi-to-LAN- oder Any-Regeln. Deshalb wird die gesamte Regelreihenfolge auf interne Freigaben geprüft. Sollen Clients desselben Separate-Zone-Netzes über mehrere APs miteinander kommunizieren, ist zusätzlich eine WiFi-to-WiFi-Regel nötig. Für ein Gäste-WLAN sollte man diese Kommunikation nur absichtlich erlauben.

Zugriffe auf die Firewall selbst werden nicht durch die normale Firewall-Regel gesteuert. Unter Administration > Device access die tatsächlich konfigurierten WiFi-Berechtigungen für HTTPS und SSH prüfen, statt eine bestimmte Voreinstellung anzunehmen. Unter Administration > Device access werden deshalb für ein Gäste-WLAN die WiFi-Häkchen bei HTTPS, SSH und allen anderen nicht benötigten lokalen Diensten entfernt. DNS bleibt nur erlaubt, wenn die Clients tatsächlich die Firewall als Resolver verwenden. Die Hintergründe erklärt Device Access und Local Service ACL.

5. WLAN einem Access Point zuweisen

Ein gespeichertes Wireless Network wird noch von keinem Access Point ausgestrahlt:

1. Wireless > Access points öffnen.
2. Den aktiven Access Point über seinen Namen oder Edit öffnen.
3. Das korrekte Country kontrollieren.
4. Unter Wireless networks auf Add new item klicken.
5. Guest WiFi auswählen, mit Apply übernehmen und Save klicken.

Bei mehreren Access Points ist eine Gruppe unter Wireless > Access point groups übersichtlicher. So werden SSIDs konsistent zugewiesen und nicht pro AP unterschiedlich gepflegt. Einem AP können bis zu acht Wireless Networks zugewiesen werden.

Eine Gruppe wird unter Wireless > Access point groups > Add mit Name, Wireless networks, optionalem VLAN tagging und den enthaltenen Access points angelegt. Vor dem Speichern muss geprüft werden, ob die VLAN-Zuordnung wirklich für alle ausgewählten APs passt.

⚠️ Betriebswirkung: Wird eine Access-Point-Gruppe deaktiviert, stellen alle enthaltenen APs die Ausstrahlung der zugewiesenen WLANs ein. Eine Gruppenänderung gehört deshalb in ein Wartungsfenster mit dokumentierter AP- und SSID-Liste.

Funkparameter und AP-Gruppen bewusst ändern

Unter Wireless > Access points > AP > Advanced settings beeinflussen Kanal, Dyn chan, TX power und Channel width nicht nur einen einzelnen Testclient. Eine dynamische Kanaländerung kann verbundene Clients zur Neuanmeldung zwingen. Breitere Kanäle erhöhen in einer Umgebung mit geringer Funkdichte den möglichen Durchsatz, können ihn bei hoher Dichte durch zusätzliche Überlappung jedoch verschlechtern. SFOS verwendet standardmässig 20 MHz auf 2,4 GHz und 40 MHz auf 5 GHz. Sendeleistung und Kanalbreite werden deshalb pro Standort gemessen statt pauschal maximiert.

Turn on Spanning Tree Protocol (STP) schützt bei gebridgten Netzen vor Layer-2-Schleifen und daraus entstehenden Broadcast-Stürmen. STP sollte nicht als Performance-Schalter behandelt werden. Nach einer Änderung werden mindestens zwei reale Clients, Roaming, DHCP, DNS und ein längerer Transfer geprüft; bei automatischer Kanalwahl zusätzlich der Wechselzeitpunkt und die erneute Verbindung der Clients.

Soll die dynamische Kanalwahl nur zu festgelegten Zeiten laufen, pro Band zuerst Dyn chan, danach Time-based scan aktivieren und unter Select scan time > Add new item den vorgesehenen Schedule zuweisen oder über Add anlegen. Nach Save den Scanzeitpunkt und eine mögliche Client-Neuverbindung beobachten. Den AP vor Gruppenänderungen anhand ID (Seriennummer), Label und Group eindeutig zuordnen. Ein einzelnes WLAN lässt sich in seinen AP-Details mit remove wieder abwählen; danach speichern und die übrigen SSIDs prüfen. Das ist nicht dasselbe wie das Deaktivieren der ganzen AP-Gruppe. Für einen geplanten AP-Neustart kann unter Wireless > Access points der ausgewählte AP mit Restart neu gestartet werden; vorher die Clientliste und Logs sichern und danach die unten beschriebenen Verbindungstests wiederholen.

WLAN kontrolliert testen

Die Abnahme sollte nicht bei «SSID ist sichtbar» enden. Mit einem Testclient wird geprüft, ob tatsächlich das geplante Netz und die geplanten Regeln verwendet werden:

1. Unter Wireless > Access points muss der AP aktiv sein. Das Wireless-Interface bleibt unter Network > Interfaces auf Unplugged, solange kein AP mit diesem Wireless Network verbunden ist.
2. Mit Company Guest verbinden und unter Wireless > Wireless client list AP, SSID, Frequenz und Signal kontrollieren.
3. Unter Network > DHCP > IPv4 lease prüfen, ob der Client eine Adresse aus 10.30.40.100 bis 10.30.40.220 erhalten hat.
4. Am Client IP-Adresse, Gateway und DNS kontrollieren. Unter Windows helfen:

ipconfig /all
nslookup example.com

5. Eine erlaubte Internetverbindung und bewusst ein nicht erlaubtes internes Ziel testen.
6. Im Log Viewer nach der Client-IP filtern und die erwartete Firewall Rule ID sowie NAT Rule ID kontrollieren.

Der Erfolg besteht nicht nur aus Internetzugriff. Der Client muss das richtige Gateway und die vorgesehenen DNS-Server verwenden, von unerlaubten internen Zielen getrennt sein und über genau die erwarteten Firewall- und NAT-Regeln laufen. Den allgemeinen Prüfablauf zeigt Firewall-Regeln sauber testen.

Rogue Access Points kontrolliert scannen

Rogue AP scan ist nur auf Sophos-Firewall-Appliances mit integriertem WLAN verfügbar; externe APX können diesen Scan nicht ausführen. Unter Wireless > Rogue AP scan startet Scan now eine Suche nach Access Points in Funkreichweite. Während des Scans werden verbundene WLAN-Clients kurz getrennt. Ein manueller oder geplanter Scan gehört deshalb in ein bekanntes Zeitfenster und nicht unangekündigt in den produktiven Betrieb.

Gefundene Geräte erscheinen unter Unrecognized access points und werden bewusst als autorisiert oder als Rogue AP markiert. Die Markierung ersetzt keine Incident-Prüfung: SSID, BSSID, Kanal, Signal, Standort und möglicher Switchport müssen korreliert werden, bevor ein fremdes Funknetz als Gerät im eigenen LAN behandelt wird.

Für wiederkehrende Scans wird unter General settings > Schedule system-triggered scan at ein Schedule gewählt. Bei LocalWiFi0 mit aktivem Bridge to Ethernet und einem Wireless Network im Modus Bridge to AP LAN zeigt der Scan nur nahe Netze im gleichen Frequenzband wie das zugewiesene Wireless Network. Diese Produktgrenze muss bei der Bewertung dokumentiert werden.

Die Scanplanung mit Apply übernehmen. Bei den Ergebnissen die Aktionen Mark as “authorized access point” oder Mark as “rogue access point” verwenden und die resultierende Zuordnung kontrollieren. Ein als Rogue markierter Eintrag ist eine Klassifizierung, kein belegter Mechanismus zum Abschalten oder Blockieren eines fremden Access Points.

Typische Fehler eingrenzen

SSID wird nicht angezeigt

Zuerst prüfen, ob Wireless Protection aktiv ist, die AP-Managementzone unter Allowed zone steht und der Access Point unter Wireless > Access points aktiv statt pending oder inactive ist. Danach Country, zugewiesenes Wireless Network, Frequency band und einen möglichen Zeitplan kontrollieren.

Ein gespeichertes Netz ohne AP-Zuweisung wird nicht ausgestrahlt. Bei integriertem WLAN können zudem Modellgrenzen bei Funkbändern oder ein nicht unterstützter alter Verschlüsselungsmodus verhindern, dass das Profil an LocalWiFi0 gebunden wird.

Separate-Zone-Interface bleibt Unplugged

Unplugged ist normal, solange kein Access Point verbunden oder das Wireless Network keinem AP zugewiesen ist. Bleibt der Status trotz aktivem APX und korrekter Zuweisung bestehen, sollte man den Managementpfad des Access Points prüfen.

Auf SFOS 21.5 MR1 Build 261 kann dies auftreten, wenn die Firewall-IP des APX-Managementnetzes als Alias statt direkt auf dem Parent-Interface konfiguriert ist (NC-175920). SFOS kann dann den VXLAN-Tunnel für Separate zone nicht anlegen. Als Workaround wird der APX in ein Managementnetz verschoben, dessen Firewall-IP direkt auf dem Parent-Interface liegt. Die Alias-IP sollte nicht auf Verdacht gelöscht werden.

Der Wechsel unterbricht die ausgestrahlten WLANs. Deshalb vorher DHCP, Gateway, Allowed zone und Port 2712 im Zielnetz prüfen und die Änderung in einem Wartungsfenster durchführen. Danach müssen AP-Status, WLAN-Zuweisung, Interface-Status und die Verbindung eines Testclients stimmen. Sophos nennt keine Fix-Version; auf anderen SFOS-Versionen beweist Unplugged allein diesen Fehler daher nicht.

Client erhält keine IP-Adresse

Bei Separate zone muss der DHCP-Server auf dem erzeugten Wireless-Interface liegen und der Bereich zum Interface-Netz passen. Bei Bridge to AP LAN antwortet dagegen der DHCP-Server des AP-LANs. Bei Bridge to VLAN werden Switch-Trunk, VLAN-ID und der im Client-VLAN erreichbare DHCP-Server gemeinsam geprüft.

AP-Management-DHCP und Client-DHCP dürfen nicht verwechselt werden: Der AP kann online sein, obwohl für die WLAN-Clients noch kein funktionierender DHCP-Server existiert.

Client hat eine IP-Adresse, aber kein Internet

Dann sind DHCP und Funkverbindung bereits weiter als die eigentliche Policy. Als Nächstes werden Gateway und DNS, die WiFi-to-WAN-Regel, Regelreihenfolge, Logging und die passende MASQ-/SNAT-Regel geprüft. Der Log Viewer zeigt, ob die geplante Firewall Rule ID matched oder die implizite Regel #0 den Traffic verwirft.

Erreicht der Client das Internet, aber gleichzeitig interne Systeme, ist das kein Erfolg für ein Gäste-WLAN. In diesem Fall greifen wahrscheinlich vorhandene WiFi-to-LAN-, Any- oder zu breite Netzwerkregeln.

AP-Verbindung oder Clientkommunikation bleibt unklar

Firewall-Traffic erscheint im Log Viewer nur zuverlässig, wenn Log firewall traffic in der Regel und der Firewall-Logtyp unter System services > Log settings > Local reporting aktiv sind. Wireless-Ereignisse selbst sind dort nicht als normaler lokaler Wireless-Logtyp verfügbar; unter System services > Log settings können sie an Sophos Fusion oder einen Syslog-Server gesendet werden.

Für eine tiefere Diagnose dokumentiert Sophos awed.log für die Kommunikation zwischen Firewall und APX, wc_remote.log für Wireless-Clients und hostapd.log für LocalWiFi. Wie man solche Logs ohne unkontrollierten Service-Neustart liest, erklärt Sophos Firewall Services und Logs per CLI prüfen.

Das Log eines erreichbaren APX kann bei Bedarf über awetool gelesen werden. Als admin an der Firewall-CLI anmelden, 5 – Device Management, dann 3 – Advanced Shell wählen und awetool starten. Connect to an AP wählen, den Ziel-AP anhand seiner Identität auswählen, mit OK bestätigen und mit y die Verbindung abschliessen. Erst auf diesem AP sind logread und logread -f die dokumentierten lesenden Prüfungen. Der ebenfalls angebotene Befehl reboot trennt Clients und verändert den Zustand; er folgt erst nach der Logsicherung, in einem Wartungsfenster und mit anschliessender Kontrolle von AP-Status, SSID, Clientliste und echtem Traffic. Diese APX-Shell-Schritte nicht auf AP6, integriertes LocalWiFi oder UTM übertragen.

Grosse Transfers sind langsam oder brechen ab

Wenn nur grössere Pakete oder längere Transfers betroffen sind, kann die VXLAN-Kapselung von Separate zone eine Rolle spielen. Es gibt dafür keinen allgemeingültigen MTU-Wert. Zuerst werden Rule ID, Datenpfad, Retransmits und ein reproduzierbarer Anwendungstest dokumentiert. Erst wenn ein MTU-/MSS-Problem nachgewiesen ist, wird kontrolliert geändert und derselbe Test wiederholt.

Wireless-Objekte per XML API sicher einordnen

Wer die oben beschriebenen Einstellungen automatisiert, muss Netzwerkprofil, lokalen Funkteil, AP-Gruppe und globale Wireless-Einstellungen getrennt behandeln. Die XML-Referenzen für SFOS 22 und 23 dokumentieren die folgenden Objekte, sind aber keine Freigabe für einen unverändert kopierten Schreibrequest. Zugang, explizite Operationen, Antwortauswertung und sichere Wiederholungen erklärt Sophos Firewall XML API Zugriff absichern. Vor Änderungen den bestehenden Objektzustand, Abhängigkeiten und einen bestätigten Rückweg sichern. Bei den unten genannten Quellenkonflikten die betroffenen Schreibfelder zuerst in API help des installierten Builds beziehungsweise mit Support klären; bis dahin nicht senden. Alle folgenden Codes sind objektspezifische XML-Statuswerte, keine HTTP-Statuscodes; alle Message.*-Symbole sind nicht aufgelöste Referenzschlüssel, keine bestätigten Laufzeittexte. Operation, Code und bereinigte tatsächliche Antwort gemeinsam festhalten.

WirelessLocalAP: Identität und Funkparameter des W-Modells

WirelessLocalAP gehört zum integrierten lokalen Access Point einer passenden Wireless-Appliance, nicht zur lokalen Weboberfläche eines AP6 und nicht zu dessen Central-/Fusion-Verwaltung. Aus diesem Vertrag entsteht weder ein neuer APX-API-Ablauf noch eine Anleitung für alte AP-/UTM-Geräte. Das Pflichtfeld Id identifiziert den vorhandenen lokalen AP; Label ist eine optionale Bezeichnung, keine Ersatzidentität. Das Referenzbeispiel schreibt LocalWifi0/LocalWifi1, während die UI-Hilfe LocalWiFi0 verwendet. Gross-/Kleinschreibung nicht still korrigieren und den Schrägstrich nicht als gemeinsame ID senden: die tatsächliche einzelne Identität im build-passenden Lese-/Export-Ergebnis bestätigen. Country muss zum realen Standort passen, nicht zum Beispiel In.

Die Netzwerkzuweisungen stehen im Beispiel unter WirelessNetworks/Network. Die Tabelle beschreibt Network als Array und warnt, dass doppelte Werte nicht ignoriert werden. Deshalb die vorhandenen Zuweisungen vollständig abgleichen und keine SSID-Liste oder geratenen Netzwerknamen senden. Die Grenze von acht zugewiesenen Wireless Networks und die Hardwaregrenzen der Funkbänder bleiben auch bei Automation relevant.

Für die Bandzuordnung beschreibt die Tabelle Band mit 2.4GHz oder 5GHz, für 2,4 GHz Channel, ChannelWidth, TXPower, DynChan und TimeBasedScan, für 5 GHz dagegen Channel5GHz, ChannelWidth11a, TXPower5GHz, DynChan5GHz und TimeBasedScan5GHz. Das Beispiel zeigt Scanzeiten unter ScanTime/Time; die Tabelle führt Time zweimal als bandabhängiges Array auf, ohne die Elternstruktur für beide Bänder eindeutig zu zeigen. Die richtige Elternstruktur je Band vor einem Schreibrequest bestätigen, statt alle Time-Einträge zusammenzufassen oder einen 5-GHz-Parent zu erfinden. Radio-Scanzeiten sind nicht der SSID-Zugriffszeitplan.

Mehrere Angaben widersprechen sich: Das Beispiel verwendet Channel2.4GHz, die Tabelle Channel; bei DynChan und TimeBasedScan steht im Beispiel Enable, in den Wertelisten nur t. Für TXPower zeigt das Beispiel 100, die Tabelle dagegen 10%, 25%, 50%, 75%, 100%. Auch der Text zur Bandzuordnung von DynChan ist nicht eindeutig. Diese Schreibweisen sind nicht als austauschbare Werte bestätigt. Die Exportbeschreibung für DynChan5GHz unterscheidet zudem Disabled (statischer Kanal, dynamischer Scan aus), 1 (Auto-Kanal ohne dynamischen Scan) und Enabled (Auto-Kanal mit dynamischem Scan); Exportwerte nicht automatisch als zulässige Schreibeingaben behandeln.

BridgeToEthernet, BridgeToPort und Zone betreffen die lokale Ethernet-Bridge, nicht die Client-VLAN-ID eines Netzwerkprofils. Die oben beschriebenen Gen.1-/Gen.2-Grenzen, IPv4-/Bridge-to-AP-LAN-Voraussetzungen und DHCP-/Adminzugangsprüfungen gelten weiterhin. Nach einer bestätigten Änderung beide betroffenen Radios, Country, Netzwerkzuweisungen, Bridge und einen echten Client prüfen, bevor weitere APs geändert werden.

Die Status Message Information für die Operation Update Local AP ordnet in beiden Referenzversionen diese XML-Statuswerte zu:

• 200, 216: Message.WPAPkUpdateSuccessfully; 500, 541, 543, 544, 545: Message.WPAPUpdateFail.
• 523: Message.WPNetworkGroupMax; 524: Message.WPAccessPointMax; 542: Message.WPAccessPointMesh.
• 547: Message.WPAPUpdateFailVLANGroup; 548: Message.WPA3IsNotSupported.
• 561: Message.LegacyModeNotSupported; 564: Message.TKIPModeNotSupported; 565: Message.TopazToNonTopazImportFail.

Das sind wörtliche, nicht aufgelöste Referenzschlüssel, keine nachgewiesenen Laufzeitmeldungen. Insbesondere aus Message.TopazToNonTopazImportFail keine Modellzuordnung oder erlaubte Importmigration ableiten. Bei einer unklaren Antwort gespeicherte AP-Identität, Funkparameter und Zuweisungen nachlesen, nicht automatisch denselben Update wiederholen oder die Verschlüsselung abschwächen.

WiFi6Interface: vorhandenes Interface statt SSID oder Bridge

WiFi6Interface verwaltet in den XML-Referenzen für SFOS 22 und 23 die portbezogenen Netz- und Zoneneinstellungen von LocalWiFi6, nicht ein SSID-Profil oder eine physische Bridge. Pflichtfelder sind Name, Hardware und Zone: Name ist die beschreibende Bezeichnung mit höchstens 58 Zeichen; Hardware bezeichnet den Hardware-Namen des bereits vorhandenen Interfaces. Diese Identität vor einer Änderung im build-passenden Lese-/Export-Ergebnis bestätigen, nicht aus Anzeigename, SSID oder WirelessNetworks.HardwareName ableiten. Die Zehn-Zeichen-/A-Za-z0-9_-Vorgabe für den Hardware-Namen einer physischen Bridge wird hier nicht übernommen; die WiFi6Interface-Tabelle nennt für Hardware nur einen String. Auch aus dem API-Objektnamen folgt keine Zuordnung zu einer Hardwaregeneration. Die oben beschriebenen modellabhängigen GUI-Bridge-, DHCP- und Adminzugangsprüfungen gelten unverändert.

IPv4Address und Netmask sind in diesem Vertrag optional. Daraus folgt weder eine Pflicht, eine neue Adresse zu setzen, noch eine bestätigte Wirkung beim Weglassen vorhandener Werte. Vor Änderungen den tatsächlichen Port, die Zone und eine gegebenenfalls vorhandene IP-Adresse mit Maske dokumentieren; danach denselben Interface-Zustand nachlesen und mit dem vorgesehenen Adressplan vergleichen. Ein solcher Interface-Abgleich ersetzt weder die Prüfung von AP-Zuweisung und SSID noch den echten Clienttest.

Für die Operation WiFi6Interface zeigen beide Quellkörper 200/Message.InterfaceUpdateSuccess, 500/Message.InterfaceUpdateFail und 502/Message.InterfaceIPAlreadyInUsed. Dies sind objektspezifische XML-Statuswerte mit nicht aufgelösten Referenzschlüsseln, keine HTTP-Codes oder bestätigten Laufzeittexte. Operation, Code und bereinigte tatsächliche Antwort gemeinsam festhalten. Bei unklarem Ergebnis zuerst Hardware-Identität, Port, Zone und gegebenenfalls IP/Netmask nachlesen, statt denselben Update automatisch zu wiederholen oder ein anderes Wireless-Objekt anzulegen. Ein Erfolgscode allein beweist weder korrekte Netzzuordnung noch funktionierenden WLAN-Traffic; hier wird kein neuer Schreibrequest abgeleitet.

WirelessNetworks: Hardware-Identität, Profil und Status unterscheiden

Bei WirelessNetworks sind der unveränderbare Hardware name, der änderbare Anzeigename Name und die ausgestrahlte SSID verschiedene Werte. Im Gäste-Beispiel sind dies GuestWiFi, Guest WiFi und Company Guest. Die Add-/Update-Parametertabelle verlangt HardwareName mit höchstens zehn Zeichen; auch die Löschoperation identifiziert das Ziel über HardwareName, nicht über SSID oder Anzeigename. Vor einer Löschung AP-Zuweisungen, Interface, DHCP und Regeln kontrollieren und nur das eindeutig identifizierte, freigegebene Ziel entfernen. Ein Fehler ist kein Anlass, das Profil unter einem neuen Namen nochmals anzulegen.

Das Add-/Update-Beispiel verwendet jedoch Hardware statt HardwareName und ClientIsolation mit Enable statt des Tabellenwerts Enabled. Bei HideSSID gibt es dieselbe Abweichung; die Tabelle nennt für TimeBasedAccess, ClientIsolation, HideSSID und FastTransition jeweils Enabled/Disabled. Auch MACFiltering mit Allowlist/Blocklist steht neben einer älteren MACList-Beschreibung mit Whitelist/Blacklist. Keine dieser Abweichungen durch Raten auflösen. Der XML-Vertrag listet ausserdem ältere Sicherheitsmodi, während die aktuelle UI-Hilfe WPA3 nur für die oben genannten W-Modelle beschreibt: Daraus folgt keine vollständige WPA3-Schreibsyntax.

Die dokumentierten Traffic-Tokens SeparateZone, BridgetoAPLAN und BridgetoVLAN gehören zu ClientTraffic. IPAddress und Netmask beziehen sich auf Separate zone; BridgetoVLANid auf das Client-VLAN, ClientVlanId auf Static beziehungsweise RadiusAndStatic. Diese Werte nicht mit dem AP-Management-VLAN verwechseln. Der Beispielschlüssel, die öffentliche Beispiel-IP und TKIP(only abg) werden nicht übernommen: AES beziehungsweise ein nachweislich unterstützter stärkerer Sicherheitsmodus, eine eigene sichere Passphrase sowie kontrollierte Netztrennung bleiben das Ziel. ClientIsolation ersetzt weiterhin keine Firewall- oder VLAN-Grenze über mehrere Radios/APs hinweg.

Für Add Wireless Network nennen beide Referenzen folgende Zuordnungen:

• 200: Message.WPNetworkSuccess; 500, 541, 545: Message.WPNetworkFail.
• 502: Message.WPNetworkExists; 503: Message.WPNetworkInterfaceExists; 542: Message.WPNetworkInterfaceIPExists.
• 544: Message.InterfaceIPAssignedToPeerAdminIP; 548: Message.InterfaceReservedName; 560: Message.DHCPIPRangeConfig.

Für Update Wireless Network unterscheiden sich mehrere Schlüssel trotz gleicher Codes:

• 200: Message.WPNetworkUpdateSuccessfully; 500, 541, 543, 545, 549: Message.WPNetworkUpdateFail.
• 503: Message.WPNetworkInterfaceExistsForUpdate; 542: Message.WPNetworkInterfaceIPExistsForUpdate.
• 544: Message.InterfaceIPAssignedToPeerAdminIP; 548: Message.InterfaceReservedName; 560: Message.DHCPIPRangeConfig.
• 546: Message.WPBindWithLA; 547: Message.APNotSupport5GHzWP.
• 561: Message.SecModeChangedToLegacyFail; 562: Message.SecModeChangedToWAP3Fail; 563: Message.EncModeChangedToTKIPFail.

Für Delete Wireless Network sind 200/Message.WPNetworkDeleteSuccess, 500/Message.WPNetworkDeleteFail, 541/Message.BridgeWirelessNetworkExists und 542/Message.WPEnableDeteleFail dokumentiert. Auch scheinbare Schreibfehler wie Message.SecModeChangedToWAP3Fail und Message.WPEnableDeteleFail bleiben unverändert; sie werden nicht in vermeintlich korrekte Laufzeitmeldungen umbenannt. Bei diesen Antworten zuerst die tatsächlich gespeicherte Hardware-Identität, IP, DHCP-Abhängigkeiten, Bridge und AP-Zuweisungen abgleichen. Nicht aus einem Schlüssel allein eine Ursache, einen erfolgreichen Rückbau oder einen sicheren Retry behaupten.

WirelessNetworkStatus ist ein getrenntes Objekt: Seine Tabelle beschreibt Name ausdrücklich als Interface-Namen mit höchstens zehn Zeichen, nicht als automatische SSID- oder Anzeigenamen-Alias. Status verwendet hier Enable/Disable, nicht die Enabled/Disabled-Werte anderer Felder. Den tatsächlichen Interface-Namen vorher bestätigen. Für Enable-Disable Wireless Network stehen 200/Message.WPNetworkUpdateSuccessfully und 500/Message.WPNetworkUpdateFail. Eine Statusänderung weist das Netzwerk keinem AP zu und beweist noch keine Ausstrahlung; gespeicherten Status, AP-Zuweisung und Clientverbindung getrennt prüfen.

WirelessGrouping: Gruppenmitgliedschaft ist keine Radio-Konfiguration

WirelessGrouping beschreibt eine AP-Gruppe mit Name, den mehrfach möglichen Einträgen WirelessNetworks/Network und AccessPoints/AccessPoint. Die AP-Identitäten aus dem vorhandenen Bestand übernehmen, nicht das alte AP30-Beispiel der Referenz. Die Gruppenstruktur konfiguriert Netzwerkzuweisungen und optionales AP-Management-Tagging, aber keine bandabhängigen lokalen Funkparameter. Aus optionalen Arrays folgt keine bestätigte Semantik für leere Listen oder ein sicherer partieller Update.

VLANTagging nennt Enable/Disable; APVLANID nennt 1 bis 4094 und gilt bei aktiviertem Tagging. Das ist das Management-VLAN der APs, nicht BridgetoVLANid für Clients. Vor Änderungen die gesamte Mitgliederliste, Trunk, Management-DHCP, Allowed zone und Rückweg prüfen. Das Deaktivieren einer Gruppe stoppt weiterhin die Ausstrahlung ihrer APs; nach einer bestätigten Änderung jeden betroffenen AP und die vorgesehenen SSIDs kontrollieren.

Für Add an Access Point Group stehen 200, 216/Message.WPGroupSuccess, 500, 541, 543, 545/Message.WPGroupCreated, 502/Message.WPGroupExists, 523/Message.WPGroupMax, 524/Message.WPGroupMaxAP und 546/Message.WPA3IsNotSupported. Für Update an Access Point Group stehen dagegen 200, 216/Message.WPGroupUpdateSuccessfully, 500, 541, 543, 545/Message.WPGroupUpdateFail, 523/Message.WPGroupMaxForUpdate, 524/Message.WPGroupMaxAPForUpdate und 546/Message.WPA3IsNotSupported. Der irritierende Schlüssel Message.WPGroupCreated bei Fehlercodes ist keine Erfolgsgarantie. Vor einem Retry gespeicherte Gruppe und Mitglieder nachlesen, statt eine zweite Gruppe anzulegen oder weitere APs aufzunehmen.

Globale Einstellungen: Managementzugang und Folgewirkungen

WirelessProtectionGlobalSettings ist weder ein SSID-Profil noch eine Clientzone. Im Beispiel enthält AllowedZone/Zone die mehrfach möglichen Managementzonen; NotificationTimeout entspricht dem oben erläuterten Offline-Benachrichtigungs-Timeout in Minuten. RADIUSServer bezeichnet den global ausgewählten Server für den beschriebenen Enterprise-Pfad. Beim Schalter verwendet das Beispiel WirelessProtection, die Tabelle dagegen EnableWirelessProtection: auch diese abweichenden Feldnamen vor einem Schreibrequest build-spezifisch klären.

Für Global Settings nennen beide Referenzen 200/Message.WLANAPEditSuccessful, 500/Message.WLANAPEditFailed, 501/Message.WLANAPIPAlreadyInUsed und 504/Message.WLANAPIntBaseVHExist. Weitere Unterscheidungen sind:

• 511: Message.WLANAPFailedWhileUnbinding; 512: Message.WLANAPFailedWhileDeleteDHCPServer; 513: Message.WLANAPFailedWhileDeleteDHCPRelay.
• 516: Message.WLANAPFailedToUnbindInterface; 520: Message.WLANAPFailedToUnbindIfaceRCg; 521: Message.WLANAPEditRunConfigFailed.
• 523: Message.WLANAPWLAN1UnboundEditFaild; 524: Message.WLANAPOtherUnboundEditFaild.

Die Schlüssel werden nicht als bewiesene Fehlerursache aufgelöst, zeigen aber, warum eine globale Änderung nicht als harmloser Test behandelt werden darf: Interface-Bindungen und DHCP-Konfiguration können betroffen sein. Wireless Protection nicht zur schnellen Diagnose aus- und wieder einschalten. Vor einer geplanten Änderung Backup, unabhängigen Adminzugang, Interfaces, DHCP-Server/-Relays und AP-Zuweisungen erfassen. Danach den tatsächlich gespeicherten globalen Zustand und die betroffenen Dienste nachlesen, AP-Erreichbarkeit und Clients prüfen und erst mit diesen Belegen über Wiederholung oder den bestätigten Rückweg entscheiden. Ein XML-Erfolgscode allein beweist weder die Funkwirkung noch vollständigen Konfigurationserfolg.