Sophos Firewall Wireless Mesh im APX-Bestand einrichten und testen

Ein Wireless Mesh auf Sophos Firewall verbindet einen oder mehrere APX Access Points drahtlos mit einem verkabelten Root-AP. Es kann eine Funklücke überbrücken, wenn am entfernten Standort keine Ethernet-Verkabelung vorhanden ist. Der Mesh-Backhaul ist dabei nicht die sichtbare WLAN-SSID: SFOS erzeugt dafür ein verborgenes WPA2-Personal-Netz mit einer zufälligen Passphrase. Die Clients verwenden weiterhin ein separat konfiguriertes Wireless Network.

⚠️ Wichtig: Diese Anleitung gilt für bestehende, direkt von SFOS verwaltete APX-Installationen. APX lässt sich nur mit APX vermeshen. AP6, integriertes LocalWiFi, SD-RED-Wi-Fi-Module und gemischte Sophos-AP-Serien gehören nicht in diesen Ablauf. Ein Mesh ersetzt zudem keine verkabelte Redundanz: Mindestens ein AP bleibt per LAN verbunden, und SFOS führt bei einem Ausfall des Root-AP keinen automatischen Root-Wechsel durch.

Geltungsbereich: Bestandsbetrieb statt neue WLAN-Plattform

Die folgenden Schritte beschreiben Legacy Firewall-managed Mesh für einen bestehenden APX-Verbund, nicht den Aufbau einer neuen APX- oder UTM-Plattform. Vor einer Änderung muss die Unterstützung des konkreten AP-Modells, seiner Hardware-Revision und des tatsächlich eingesetzten SFOS-Builds bestätigt sein. Die Wireless-Hilfe unter SFOS 22 und SFOS 23 enthält ältere Mesh-Abläufe; eine vorhandene Hilfeseite ist kein Nachweis für Hardware-Unterstützung. Insbesondere darf daraus kein APX-Upgrade auf SFOS 23 abgeleitet werden. Ist die Unterstützung nicht bestätigt, bei der bestehenden Konfiguration bleiben und zuerst Modell-/Build-Kompatibilität und Migration klären.

AP6-Mesh ist ein anderer Verwaltungsweg: Für einen zentral verwalteten AP6-Verbund erfolgt die Konfiguration in Sophos Fusion, ehemals Sophos Central, nicht unter Wireless > Mesh networks auf der Firewall. Eine Sophos Firewall kann dabei weiterhin Router und Sicherheitsgrenze im Datenpfad sein, wird aber nicht zum AP6-Controller. APX und AP6 dürfen nicht denselben Mesh-Verbund bilden. Registrierung und Netzvoraussetzungen für diesen getrennten Weg erklärt Sophos Central Wireless Anforderungen; die konkrete Planung, Mesh-Konfiguration und Abnahme stehen unter AP6-Mesh planen und einrichten. Die hier gezeigten APX-Rollen, SSID-Zuweisungen und Rückbauschritte werden nicht auf AP6 übertragen.

Das Outdoor-Modell APX 320X gehört nicht in diesen Firewall-verwalteten Ablauf. Hinweise auf die alte Sophos-AP-Serie und manuelle Rollen in älteren Anleitungen erklären historische Installationen, nicht eine heute unterstützte Neuinstallation. Auch integriertes LocalWiFi und SD-RED-Wi-Fi-Module sind keine Austauschgeräte für die beiden externen APX im Beispiel; deren WLAN- und Modellvoraussetzungen müssen separat geprüft werden. UTM-Anleitungen werden hier weder fortgeschrieben noch als neuer Einrichtungsweg empfohlen.

Kurzablauf:

1. Beide APX zunächst per LAN verbinden, unter Wireless > Access points annehmen und Firmware, Country sowie Funkplanung prüfen.
2. Für das Mesh-Band auf allen beteiligten APs denselben festen Kanal setzen und Dyn chan ausschalten.
3. Unter Wireless > Mesh networks > Add Mesh-ID, Frequency band und APX-Geräte konfigurieren.
4. Die sichtbare Client-SSID separat an beide APX zuweisen.
5. Konfiguration speichern, das LAN-Kabel am Mesh-AP trennen, die APX neu starten und bis zu fünf Minuten warten.
6. AP-Status, Clientverbindung, DHCP, Rule ID, Internetzugriff und den Ausfall des Root-Pfads kontrolliert prüfen.

Wann ein APX-Mesh passt

Ein Mesh passt zu einer bestehenden APX-Installation, wenn ein einzelner entfernter Access Point keinen Ethernetanschluss erhält und die Funkverbindung zum Root-AP stabil genug ist. Typische Beispiele sind eine kleine Lagerzone, ein Besprechungsraum oder ein temporärer Bereich, in dem eine spätere Verkabelung geplant ist.

Ein Ethernet-Uplink bleibt technisch die bessere Basis für dauerhaft hohe Kapazität, stabile Latenz und planbares Failover. Der Mesh-Backhaul teilt Funkzeit mit anderen Übertragungen. Deshalb sollte man die reale Leistung mit den vorgesehenen Clients und Anwendungen messen, statt aus dem Link-Status auf die nutzbare Kapazität zu schliessen.

Für neue Installationen ist zudem die Produktgrenze wichtig: APX ist End-of-Sale und erreicht am 31. Dezember 2027 das End-of-Life. Das APX-Lifecycle und AP6 als Nachfolger gehört deshalb in die mittelfristige Planung. AP6 wird nicht über SFOS verwaltet.

Mesh-Backhaul, Client-SSID und Rollen verstehen

Diese Bausteine erfüllen unterschiedliche Aufgaben:

• Mesh network: verborgener Funk-Backhaul zwischen den APX-Geräten. Die Mesh-ID identifiziert den Verbund; die zufällige WPA2-Passphrase verwaltet SFOS.
• Root-AP: APX mit bestehender Ethernetverbindung zur Firewall. Bei APX ergibt sich diese Rolle automatisch aus der Verkabelung.
• Mesh-AP: APX ohne Ethernet-Uplink, der den Root-AP über Funk erreicht.
• Wireless Network: sichtbare Client-SSID mit Security mode, Client traffic, DHCP und Regeln. Die vollständige Basis steht unter WLAN direkt auf Sophos Firewall einrichten.

Bei älteren Sophos-AP-Serien muss man Root und Mesh ausdrücklich zuweisen. Dieser Artikel verwendet ausschliesslich APX und überträgt diese alte Rollenmaske deshalb nicht auf die Beispielschritte.

Repeater oder Wireless Bridge

Im Repeater-Betrieb sendet der Mesh-AP die zugewiesene Client-SSID am entfernten Standort aus. Die Endgeräte verbinden sich per WLAN; der AP transportiert ihre Daten über den Mesh-Backhaul zum Root-AP.

Bei einer Wireless Bridge wird zusätzlich ein Ethernetsegment an den Netzwerkport des Mesh-AP angeschlossen. Dieses Design erweitert Layer 2 und kann Schleifen erzeugen, wenn gleichzeitig ein zweiter Kabelpfad existiert. Es gehört deshalb in ein Wartungsfenster mit dokumentiertem Rückweg. STP muss zum gesamten Switch- und Bridge-Design passen; es wird nicht nur auf Verdacht deaktiviert, wenn ein Pfad blockiert wird.

Für die meisten kleinen Erweiterungen ist der Repeater-Betrieb übersichtlicher. Eine Bridge sollte man nur einsetzen, wenn das entfernte Ethernetsegment wirklich benötigt und sein Broadcast-, VLAN- und Schleifenverhalten verstanden ist.

Grenzen vor der Konfiguration prüfen

Ein APX-Mesh hat klare Produktgrenzen:

• Alle beteiligten Access Points müssen zur APX-Serie gehören.
• Pro AP kann nur ein Mesh-Netz verwendet werden.
• Mindestens ein APX muss per LAN mit der Firewall verbunden bleiben.
• Alle Mesh-APs verwenden auf dem Mesh-Band denselben Kanal.
• Dynamic Channel Selection beziehungsweise Dyn chan darf auf diesem Band nicht aktiv sein, weil APs nach einem Neustart sonst auf unterschiedlichen Kanälen landen können.
• Bei APX darf nicht auf beiden Radios gleichzeitig 5 GHz konfiguriert sein, wenn Mesh verwendet wird.
• APs mit zugewiesenem VLAN können nur dann vermesht werden, wenn die VLANs nicht den Client-Traffic-Modus Bridge to VLAN verwenden.
• Ein zweites Mesh-Netz auf demselben AP funktioniert nicht.
• Der Ausfall des Root-AP wird nicht automatisch und unterbrechungsfrei von einem anderen Mesh-AP übernommen.

Die aktuelle Sophos-Hilfe nennt 2.4 GHz für den Mesh-Backhaul und 5 GHz für Client-SSIDs als möglichen Ausgangspunkt. Das ist keine universelle Best Practice. Entfernung, Wände, Störpegel, verfügbare Kanäle, regulatorisches Country und benötigte Kapazität entscheiden über das reale Design.

Dokumentationskonflikt einordnen: Die ältere Deployment-Anleitung nennt 5 GHz am Root-AP und 2.4 GHz am Mesh-AP; die Anleitung zum Hinzufügen trennt dagegen 5 GHz für Client-SSIDs von 2.4 GHz für den Mesh-Backhaul. Diese Formulierungen dürfen nicht zu unterschiedlichen Backhaul-Bändern auf Root und Mesh führen. Für den hier dokumentierten Bestandsablauf müssen beide APs dasselbe gewählte Mesh-Band und denselben festen Kanal verwenden. Das Beispiel 2.4 GHz ist keine Pflichtvorgabe; vor einem anderen Band die Modell-/Build-Unterstützung und den Funkpfad prüfen. Die APX-Grenze für zwei gleichzeitig auf 5 GHz konfigurierte Radios bleibt bestehen.

Beispieltopologie planen

Das Beispiel verwendet diese Namen:

• Firewall: fw01
• verkabelter APX: ap-office-root
• drahtloser APX: ap-warehouse-mesh
• Mesh-ID: OfficeMesh
• sichtbares Wireless Network: Company WiFi
• Mesh-Band: 2.4 GHz
• Mesh-Kanal: ein fester, am Standort geprüfter Kanal

OfficeMesh ist ein Dokumentationsbeispiel und wird durch einen kurzen, eindeutigen Namen der eigenen Installation ersetzt. Die Mesh-ID darf nicht mit der sichtbaren SSID verwechselt werden. Company WiFi steht im Beispiel bereits mit passendem Client traffic, DHCP, Firewall-Regeln und NAT zur Verfügung.

Vor der Änderung werden ein aktuelles Konfigurationsbackup, ein kabelgebundener Managementzugang und ein Rückbauplan vorbereitet. Beide APX erhalten PoE und werden für die Erstkonfiguration in Reichweite ihrer endgültigen Positionen getestet. Der Root-AP muss dort per Ethernet erreichbar bleiben.

Access Points und Funkkanal vorbereiten

Beide APX zunächst per LAN provisionieren

1. ap-office-root und ap-warehouse-mesh per Ethernet mit dem vorgesehenen Managementnetz verbinden.
2. Unter Wireless > Wireless settings prüfen, ob Wireless Protection aktiv und die Managementzone unter Allowed zone erlaubt ist.
3. Unter Wireless > Access points beide pending APX mit Accept annehmen.
4. Für beide APX das korrekte Country setzen. Nach einer Country-Änderung speichern und die APX kontrolliert neu starten, damit die Kanalliste aktualisiert wird.
5. Prüfen, ob beide APX aktiv sind und ihre aktuelle Konfiguration erhalten haben.

Die Erstverkabelung ist kein optionaler Komfort. Ein APX ohne erhaltene Mesh-Konfiguration kann später nicht allein über Funk in den Verbund aufgenommen werden.

Vor dem Rollout sollte ausserdem der APX-Firmwarestand über die Pattern-Updates der Sophos Firewall geplant werden. Ein Firmwareupdate und die Mesh-Umschaltung sollten nicht unkontrolliert gleichzeitig stattfinden.

Einen gemeinsamen festen Kanal setzen

1. Unter Wireless > Access points den ersten APX öffnen.
2. Unter Advanced settings im passenden Feld Channel 2.4 GHz oder Channel 5 GHz einen festen, lokal geprüften Kanal setzen.
3. Dyn chan für dieses Band deaktivieren.
4. Dieselbe Einstellung auf den zweiten APX übertragen.
5. Nahe APs, die nicht zum Mesh gehören, nach Möglichkeit auf einen anderen störungsarmen Kanal legen.

Ein Kanal wird nicht allein deshalb gewählt, weil er im Beispiel gut funktioniert. Ein lokaler Scan, die Country-Vorgaben und die Nachbarbelegung bestimmen die Auswahl. Nach jeder Kanaländerung müssen beide Mesh-APs erneut denselben Wert zeigen.

Wireless Mesh unter SFOS anlegen

Mesh-Netz erstellen

Für den Mesh-Backhaul wird ein neues, eigenes Mesh-Netz beziehungsweise eine neue Mesh-SSID angelegt; die vorhandene sichtbare Client-SSID Company WiFi wird nicht in ein Mesh-Netz umgewandelt. Die Hilfe verwendet dafür sowohl Mesh-ID als auch mesh-enabled SSID. Wenn die vorhandene Oberfläche Enable mesh mode nur beim Anlegen einer neuen SSID anbietet, diesen dokumentierten Legacy-Weg nur auf dem bestätigten Modell und Build verwenden und die Client-SSID getrennt lassen. Pro AP ist nur ein Mesh-Netz vorgesehen. Alle beteiligten APs müssen dieselbe Mesh-ID erhalten; sie teilen die von SFOS zufällig erzeugte WPA2-Personal-Passphrase. Das ist nicht die Passphrase des Client-WLANs.

1. Wireless > Mesh networks öffnen.
2. Add wählen.
3. Als Mesh-ID OfficeMesh eintragen.
4. Unter Frequency band das geplante gemeinsame Band wählen, im Beispiel 2.4 GHz.
5. ap-office-root und ap-warehouse-mesh hinzufügen.
6. Speichern.

Bei APX muss in diesem Ablauf keine Rolle manuell festgelegt werden. Solange beide APX noch verkabelt sind, erhalten sie zuerst die Konfiguration. Nach dem späteren Trennen von ap-warehouse-mesh bleibt ap-office-root wegen seiner Ethernetverbindung der Root-AP.

Sichtbare Client-SSID zuweisen

Das Mesh-Netz ist für Endgeräte nicht sichtbar. Deshalb wird unter Wireless > Access points oder über eine passende Access Point Group zusätzlich Company WiFi beiden APX zugewiesen.

Die Client-SSID behält ihren eigenen Security mode und Client traffic. Für Separate zone müssen insbesondere Wireless-Interface, DHCP, Firewall-Regel, NAT und Device Access stimmen. Ein erfolgreiches Mesh korrigiert keine fehlende WLAN-Regel und keinen falschen DHCP-Pfad.

Mesh-AP an den Zielort verschieben

1. Prüfen, ob Konfiguration und sichtbare Client-SSID auf beiden APX angekommen sind.
2. Das Ethernetkabel nur von ap-warehouse-mesh entfernen.
3. ap-office-root verkabelt lassen.
4. Den Mesh-AP am vorgesehenen Standort platzieren und einschalten; dieser Start erfolgt bereits ohne Ethernet.
5. Den Root-AP kontrolliert neu starten. Wurde der Mesh-AP beim Verschieben nicht stromlos, auch ihn jetzt neu starten.
6. Bis zu fünf Minuten warten, bevor die Verbindung als fehlgeschlagen bewertet wird.

Nur ein APX bleibt im normalen Mesh-Betrieb per LAN verbunden. Wird der zweite APX versehentlich ebenfalls an dasselbe Layer-2-Netz angeschlossen, muss das Design auf Schleifen und die STP-Wirkung geprüft werden.

Wireless Mesh kontrolliert abnehmen

Die Abnahme verbindet Controllerstatus, Funkpfad und echten Nutztraffic:

1. Unter Wireless > Access points müssen beide APX aktiv sein. ap-office-root bleibt verkabelt; ap-warehouse-mesh ist ohne Ethernet erreichbar.
2. Die Mesh-Zuweisung und der identische Kanal werden auf beiden APX kontrolliert.
3. Mit einem Testclient in der Nähe von ap-warehouse-mesh mit Company WiFi verbinden.
4. Unter Wireless > Wireless client list den Testclient nach AP oder SSID anzeigen und prüfen, ob er am erwarteten Mesh-AP und an Company WiFi angemeldet ist. Signalstärke und Frequenz notieren und beim Vergleich mit dem Root-AP unter ähnlichen Bedingungen erneut prüfen; eine angezeigte Clientfrequenz allein beweist nicht das Backhaul-Band.
5. IP-Adresse, Gateway und DNS des Clients gegen das geplante Wireless Network prüfen.
6. Einen erlaubten und einen bewusst gesperrten Zielzugriff testen.
7. Im Log Viewer nach der Client-IP filtern und die erwartete Firewall Rule ID sowie NAT Rule ID kontrollieren.
8. Einen realistischen Durchsatz- und Latenztest ausführen und mit einem Client am Root-AP vergleichen.

Ein grüner AP-Status bestätigt noch nicht den vollständigen Datenpfad. Erfolg bedeutet, dass der Client den richtigen AP, die richtige Adresse und die vorgesehenen Regeln verwendet und dass die Leistung für die Anwendung ausreicht. Den allgemeinen Regeltest erklärt Firewall-Regeln sauber testen.

Ausfallgrenze bewusst testen

Der Root-AP ist ein bekannter Abhängigkeitspunkt. In einem Wartungsfenster kann man den Root-Uplink kurz trennen und dokumentieren, wie lange Clientzugriffe ausfallen. SFOS verspricht keinen automatischen Root-Wechsel. Ein Mesh-AP muss für eine neue Rollenbildung gegebenenfalls neu gestartet und verkabelt werden.

Dieser Test ist kein Grund, einen produktiven Root-AP ungeplant auszuschalten. Für kritische Bereiche sollte man einen verkabelten AP-Uplink oder eine andere WLAN-Architektur einplanen.

Mesh-Objekt in der XML API sicher einordnen

Die XML-Referenzen für SFOS 22 und 23 beschreiben Add Mesh Networks und Update Mesh Networks für das Objekt WirelessMeshNetworks. Das ist eine dokumentierte Objektstruktur, keine zusätzliche Hardware-Freigabe: Der APX-Bestandsumfang, die Modell-/Build-Prüfung und der getrennte AP6-Verwaltungsweg oben bleiben unverändert. Zugangsschutz, explizite Operationen, XML-Antworten und sichere Wiederholungen erklärt Sophos Firewall XML API Zugriff absichern.

MeshID, Band und AP-Rolle auseinanderhalten

Für die Vorbereitung einer Automation sind diese Felder zu unterscheiden:

• MeshID ist ein verpflichtender skalarer String mit höchstens zehn Zeichen. OfficeMesh passt als kurzer Beispielname; es ist weiterhin die ID des Backhauls, nicht die sichtbare Client-SSID. Den zusätzlichen Referenzmarker APINTERFACENAME nicht als selbst erklärende Zeichenregel oder als AP-Identität interpretieren; die zulässige Schreibweise im installierten Build bestätigen.
• FrequencyBand ist verpflichtend und erlaubt genau 5GHz oder 2.4GHz. Die Tabelle nennt 5 GHz als dokumentierten Default, nicht als Empfehlung für jeden Funkpfad. Die kombinierte Schreibweise 5GHz/2.4GHz im Referenzbeispiel steht nicht in der Liste der erlaubten Werte und wird nicht als einzelner Feldwert übernommen. Alle beteiligten APs benötigen weiterhin dasselbe bestätigte Backhaul-Band und denselben festen Kanal; Dyn chan bleibt auf diesem Band ausgeschaltet.
• Description ist ein optionaler skalarer String. Ein leeres Element im Beispiel beweist nicht, wie ein Update eine bestehende Beschreibung behandelt.
• AccessPoints enthält im XML-Beispiel MeshNetwork; darin stehen AccessPoint und Role zusammen. Die Parametertabelle beschreibt beide Felder als optionale Arrays mit mehreren Werten und weist darauf hin, dass Duplikate nicht ignoriert werden. Daraus weder zwei beliebig unabhängig sortierbare Listen noch automatische Deduplizierung ableiten. AP-Identität und zugehörige Rolle gemeinsam gegen die vorhandene Konfiguration und API help des Builds prüfen.
• Für Role sind exakt MeshAccessPoint und RootAccessPoint dokumentiert; die Tabelle nennt Root Access Point als Default. Diese XML-Werte stammen aus der API-Referenz, nicht aus den GUI-Begriffen Root, Mesh oder Repeater. Die automatische APX-Rollenbildung über Ethernet ist insbesondere kein Nachweis dafür, ob Role im konkreten APX-Payload gesetzt, ausgelassen oder anders behandelt werden muss. Bei ungeklärter Modell-/Build-Zuordnung keinen Schreibrequest senden.

Der folgende begrenzte XML-Strukturausschnitt ist keine ausführbare Anfrage und keine APX-Rollenzuweisung. Er zeigt nur die dokumentierte Verschachtelung mit einem Referenzwert für Role; AP_IDENTITAET_AUS_API_HELP ist ein nicht sendbarer Platzhalter. Die AP30-Identität im Herstellerbeispiel wird nicht als APX-Beispiel übernommen:

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

Vor einer Änderung den tatsächlich gespeicherten Verbund mit Mesh-ID, AP-Identitäten, Zuweisungen und Funkparametern nachlesen, sichern und mit dem geplanten Zielzustand vergleichen. Der Ausschnitt enthält weder Login noch eine Operation und ersetzt keinen bestätigten vollständigen Payload. Aus der XML-Struktur folgen weder ein sicherer Retry noch eine funktionierende Funkverbindung; die getrennte Abnahme von AP-Status, Client-SSID, DHCP und Nutzdatenpfad bleibt notwendig.

Antworten nach Operation, Code und Symbol unterscheiden

Die Referenzen ordnen den beiden Operationen folgende XML-Statuscodes und wörtliche Message.*-Schlüssel zu. Die Schlüssel sind nicht aufgelöst: Sie sind keine bestätigten Laufzeitmeldungen und werden nicht zu vermeintlichen Fehlermeldungstexten übersetzt. Die objektspezifische Zuordnung muss mit API help des installierten Builds abgeglichen werden; insbesondere 521 und 522 hier nicht allein anhand der allgemeinen Statustabelle im zentralen API-Artikel interpretieren.

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.

Auch die Schreibweise Faild bleibt exakt erhalten. Aus Symbolnamen keine nachgewiesene Ursache, vollständige Rücknahme einer Änderung oder bereits gelöschte DHCP-/Interface-Abhängigkeit ableiten. Nach einer unklaren oder fehlgeschlagenen Antwort zuerst den tatsächlich gespeicherten Mesh- und AP-Zustand sowie abhängige Wireless-, Interface- und DHCP-Konfigurationen mit dem gesicherten Ausgangsstand abgleichen; bereinigte Antwort und Logs für die Klärung sichern. Erst nach der build-spezifischen Klärung über eine weitere Änderung entscheiden, nicht denselben Add oder Update automatisch wiederholen. Auch 200 ersetzt weder das Nachlesen des Zielobjekts noch die Funk- und Clientabnahme oben.

Fehler nach Symptom eingrenzen

Mesh-AP erscheint nicht oder bleibt offline

Nach der Konfiguration bis zu fünf Minuten warten. Bleibt der AP offline, zuerst prüfen, ob er bei der Erstprovisionierung per LAN aktiv war und die Mesh-Konfiguration erhalten hat. Danach APX-Serie, Mesh-Zuweisung, Band, gemeinsamer Kanal, Dyn chan, Country und Stromversorgung kontrollieren.

Der Root-AP muss weiterhin verkabelt sein. Sind beide APs drahtlos oder wurde der falsche AP vom Ethernet getrennt, fehlt der Pfad zur Firewall. Nach einer Korrektur die APX kontrolliert neu starten und erneut warten.

Fehlt in einem älteren Ablauf bei einer bestehenden SSID die Option Enable mesh mode, eine neue SSID anlegen, statt die sichtbare Client-SSID umzudeuten. Bleibt die Ursache unklar, kann man in einem Wartungsfenster zur Eingrenzung nur das Mesh-Netz am Root-AP und nur die sichtbare Client-SSID am Repeater senden lassen. Erscheint die Client-SSID am Repeater, ist das zunächst ein Hinweis auf die ausgestrahlte Clientkonfiguration, aber noch kein vollständiger Nachweis für einen funktionierenden Backhaul oder Internetzugriff. Zusätzlich prüfen, dass der Repeater wirklich ohne LAN-Uplink erreichbar ist, der Testclient in der Clientliste an diesem AP erscheint und der erwartete DHCP- und erlaubte Datenpfad funktionieren. Anschliessend die regulären Zuweisungen wiederherstellen. Bleibt das Mesh unbenutzbar, prüfen, ob STP die Mesh-Konfiguration blockiert. STP nicht unbesehen deaktivieren: Es verhindert Schleifen in Bridge-Topologien.

Client-SSID ist nicht sichtbar

Die Mesh-ID wird absichtlich nicht als Client-SSID ausgestrahlt. Unter Wireless > Access points muss dem Mesh-AP zusätzlich ein sichtbares Wireless Network zugewiesen sein. Ist nur OfficeMesh konfiguriert, haben Endgeräte kein sichtbares Netz.

Zusätzlich Frequency band, Zeitplan, Security mode und AP-Zuweisung der Client-SSID prüfen. Ein zweites Mesh-Netz auf demselben AP ist keine Lösung, weil pro AP nur ein Mesh unterstützt wird.

Client verbindet sich, erhält aber keine IP-Adresse

Dann funktioniert der Funkpfad bereits teilweise. Als Nächstes Client traffic, Wireless-Interface, DHCP-Server oder DHCP-Relay und mögliche VLAN-Pfade prüfen. Bei Bridge to VLAN ist ausserdem die Mesh-Produktgrenze zu beachten: VLAN-zugewiesene APs lassen sich nur vermeshen, wenn die VLANs nicht diesen Client-Traffic-Modus verwenden.

Ein Neustart des Wireless-Dienstes ist kein Standardschritt. Zuerst wird belegt, an welchem AP der Client hängt und ob DHCP-Anfragen den erwarteten Pfad erreichen.

Client hat eine IP-Adresse, aber kein Internet

Im Log Viewer zuerst die erwartete Firewall Rule ID und NAT Rule ID suchen. Fehlen beide, liegt das Problem eher bei Zone, Netzobjekt, Regelreihenfolge oder Datenpfad als beim Mesh selbst. Stimmen die Regeln, danach DNS, Gateway und den WAN-Pfad prüfen.

Eine breite Any-Regel dient nicht als Mesh-Diagnose. Der gleiche Clienttest sollte einmal am Root-AP und einmal am Mesh-AP ausgeführt werden. Funktioniert er nur am Root, wird der Backhaul weiter untersucht; fällt er an beiden APs aus, gehört der Fehler wahrscheinlich zur gemeinsamen WLAN- oder Firewall-Konfiguration.

Verbindung ist instabil oder langsam

Gleichen Kanal auf allen Mesh-APs, deaktiviertes Dyn chan, Signalqualität, Störquellen, Distanz und Wände prüfen. Nicht zum Mesh gehörende APs sollten denselben Kanal nicht unnötig belegen. Ausserdem muss genügend Funkkapazität für Backhaul und Clients übrig bleiben.

Die Leistung wird mit derselben Anwendung, demselben Client und möglichst denselben Zeitbedingungen am Root- und Mesh-AP verglichen. So lässt sich der Mesh-Pfad von einem allgemeinen WAN-, DNS- oder Clientproblem trennen.

Controller- oder Clientstatus bleibt unklar

Für die node-lokale Diagnose helfen die Sophos Firewall Service-Logs. In der Advanced Shell sind diese lesenden Prüfungen sinnvoll:

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

awed.log zeigt Controller- und APX-Kommunikation; wc_remote.log hilft bei Wireless-Clients. Ein einzelner Logeintrag beweist den Nutzdatenpfad nicht. Zeitstempel, AP-Status, Clientliste, Firewall-Logs und ein reproduzierbarer Test gehören zusammen. Die LED- und Blinkcodes der Sophos Access Points helfen zusätzlich, Boot-, Update- und Mesh-Zustände am Gerät einzuordnen.

Mesh sicher zurückbauen

Mesh-SSID und Client-SSID beim Rückbau unterscheiden: Die ältere Hilfe beschreibt das Abschalten durch Löschen der Mesh-SSID. Damit ist das zugehörige Mesh-Konfigurationsobjekt gemeint, nicht pauschal die sichtbare Client-SSID Company WiFi. Vor dem Löschen Mesh-ID, AP-Zuweisungen und Abhängigkeiten abgleichen, den Konfigurationsstand sichern und die APs über den vorgesehenen Kabelpfad erreichbar machen. Das Entfernen des Backhauls unterbricht drahtlos angebundene APs; das Löschen einer weiterhin benötigten Client-SSID würde zusätzlich deren WLAN-Nutzer trennen. Je nach Legacy-Oberfläche erfolgt der Rückbau über das Mesh-Netz oder dessen Mesh-SSID. Fehlt eine eindeutige Zuordnung, nicht auf Verdacht löschen, sondern zuerst die konkrete Modell-/Build-Konfiguration klären.

Ein Rückbau erfolgt kontrolliert, solange der kabelgebundene Managementzugang funktioniert:

1. Dokumentieren, welcher APX Root und welcher Mesh-AP ist.
2. Den Mesh-AP wieder per LAN in das Managementnetz verbinden und warten, bis er aktiv ist.
3. Die sichtbare Client-SSID bei Bedarf auf einen verbleibenden verkabelten AP verschieben.
4. Das Mesh-Netz von den APX entfernen oder unter Wireless > Mesh networks löschen.
5. Frühere Kanal- und Dyn chan-Einstellungen nur bewusst wiederherstellen.
6. Beide APX kontrolliert neu starten.
7. Client-IP, DNS, Regeln und Internetzugriff erneut prüfen.

Ein Werksreset ist erst dann sinnvoll, wenn der APX trotz korrekter Verkabelung, Stromversorgung und Controllerpfad keine verwaltete Konfiguration mehr annimmt. Er ersetzt keinen dokumentierten Rückbau.

Betriebscheckliste

• Alle beteiligten Geräte sind kompatible APX und wurden zuerst per LAN provisioniert.
• Genau ein Mesh-Netz ist pro AP zugewiesen.
• Ein APX bleibt als Root dauerhaft verkabelt.
• Mesh-Band und fester Kanal stimmen auf allen beteiligten APX überein.
• Dyn chan ist auf dem Mesh-Band ausgeschaltet.
• Die sichtbare Client-SSID ist separat zugewiesen.
• DHCP, Firewall Rule ID, NAT Rule ID und ein gesperrtes Ziel wurden geprüft.
• Leistung und Stabilität wurden am Root- und Mesh-AP verglichen.
• Root-Ausfall, fehlendes automatisches Takeover und Rückbau sind dokumentiert.
• APX-End-of-Life und ein späterer Wechsel der WLAN-Plattform sind eingeplant.

FAQ