Sophos Firewall Zonen und Interfaces richtig planen

Eine Zone fasst Interfaces mit ähnlicher Vertrauensstufe zusammen. Das Interface ist der physische oder virtuelle Anschluss, beispielsweise Port1, ein VLAN, LAG, RED- oder XFRM-Interface. Jedes gebundene Interface gehört genau zu einer Zone; physische Ports können auch ungebunden sein.

Wichtig: Eine Zone erlaubt keinen Traffic automatisch. Auch zwischen zwei Interfaces in der Zone LAN braucht es eine passende LAN-to-LAN-Firewall-Regel. Zugriffe auf die Firewall selbst, etwa WebAdmin, SSH oder DNS, werden zusätzlich über Device Access gesteuert.

Zonen und Interfaces direkt konfigurieren

Zone erstellen

Unter Network > Zones > Add wird eine eigene Zone in vier Schritten angelegt:

1. Einen eindeutigen Namen vergeben, beispielsweise Server, Management, Guest oder IoT.
2. Als Type LAN oder DMZ wählen.
3. Unter Device Access nur die lokalen Firewall-Dienste freigeben, die aus dieser Zone wirklich benötigt werden.
4. Speichern.

Danach sollte die Zone unter Network > Zones sichtbar und in einer Firewall-Regel als Source zone oder Destination zone auswählbar sein. Produktiver Traffic läuft erst darüber, sobald ihr mindestens ein Interface zugeordnet ist.

Eigene Zonen können nur vom Typ LAN oder DMZ erstellt werden. Zusätzliche WAN- oder VPN-Zonen sind nicht möglich. VPN-Interfaces ordnet SFOS automatisch der Zone VPN zu. Die maximale Anzahl Zonen ist versionsabhängig: SFOS 22.0 erlaubt bis zu 100 Zonen, SFOS 23.0 bis zu 248 Zonen.

Physisches Interface konfigurieren

Die Anzahl verfügbarer physischer Ports hängt vom Appliance-Modell ab. Bei der Planung deshalb zuerst prüfen, welche Anschlüsse das konkrete Gerät bereitstellt; virtuelle Interfaces ersetzen keine zusätzlich benötigten physischen Ports.

Ein bestehender Port wird unter Network > Interfaces über Edit interface bearbeitet:

1. Einen sprechenden Name mit höchstens 58 Zeichen vergeben, beispielsweise Core Switch Trunk oder MPLS Provider.
2. Die passende Network zone wählen.
3. IPv4 und bei Bedarf IPv6 konfigurieren.
4. Bei WAN-Interfaces Gateway sowie gegebenenfalls MTU und MSS prüfen.
5. Speichern und anschliessend Link-Status, Gateway-Status und Log Viewer kontrollieren.

Die Zone WAN ist für Anschlüsse mit Default Gateway vorgesehen. Interne Interfaces werden normalerweise statisch adressiert; physische Interfaces bieten für IPv4 die Methoden Static, DHCP und PPPoE. Die nachfolgenden Feldverfahren unterscheiden diese Methoden. Die dort aufgeführten Gatewayfelder sind kein Grund, ein internes Interface allein deshalb der Zone WAN zuzuordnen: Zone, Adressierung und Routing müssen zum Netzdesign und zur tatsächlich angezeigten Maske passen.

Liegt bereits ein VLAN auf dem physischen Interface, lässt SFOS den Wechsel der IPv4-Zuweisung von Static zu DHCP oder PPPoE nicht zu. Bei IPv6 ist der Wechsel von Static zu DHCP oder Delegated ebenfalls gesperrt. Vor einer solchen Umstellung werden deshalb die VLAN-Abhängigkeiten unter Object usage erfasst. Anschliessend werden die betroffenen VLAN-Interfaces auf einen anderen Parent verschoben oder in einem Wartungsfenster entfernt. Erst danach wird die Zuweisungsart geändert; anschliessend werden die VLAN-Konfiguration und die Konnektivität wiederhergestellt und getestet.

IPv4 am physischen Port: Static oder DHCP

⚠️ Vor einer Adress- oder Methodenänderung Object usage > Refresh ausführen, bisherige Adresse, Maske, Zone und Gateway dokumentieren und Backup, Wartungsfenster sowie unabhängigen Adminzugang vorbereiten. Die Änderung kann den aktuellen Management- und Datenpfad unterbrechen. Bestehende VLAN-Abhängigkeiten zuerst wie oben beschrieben behandeln. Der Konsolen-Recovery-Weg weiter unten ersetzt nicht die normale WebAdmin-Konfiguration.

Static: feste IPv4-Werte eintragen

1. Unter Network > Interfaces den richtigen physischen Port über Menu > Edit interface öffnen und Hardware prüfen. Dieser physische Anschluss lässt sich hier nicht ändern.
2. IPv4 configuration auswählen und die Zuweisungsart Static wählen.
3. Die für dieses Interface vorgesehene IPv4-Adresse eintragen. Die Subnetzmaske bei Bedarf an das geplante Netz anpassen.
4. Gateway name und Gateway IP address gemäss der angezeigten Maske und den freigegebenen Netz- beziehungsweise Providerwerten eintragen. Der Name dient der eindeutigen Bezeichnung; die Gateway-IP ist die Adresse der vorgesehenen Gegenstelle, nicht eine weitere Adresse der Firewall.
5. Werte und Port-ID nochmals vergleichen und mit Save speichern. Danach gespeicherte IP und Maske, Link, gegebenenfalls Gateway-Status sowie Routing, DNS, Device Access und den tatsächlichen Daten- und Managementpfad prüfen.

Ein rein illustrativer statischer WAN-Anschluss verwendet etwa IPv4-Adresse 192.0.2.2, Maske 255.255.255.0, Gateway name ISP-Static und Gateway IP address 192.0.2.1. Diese Adressen liegen in einem Dokumentationsnetz und sind keine produktiven Providerwerte. Adresse, Maske und Gateway durch die zusammengehörigen Angaben des eigenen Providers ersetzen; den Namen so wählen, dass die Leitung im Betrieb erkennbar bleibt.

DHCP: dynamischen Bezug und dokumentierte Felder unterscheiden

1. Den physischen Port unter Network > Interfaces > Menu > Edit interface öffnen, Hardware und Zone prüfen und IPv4 configuration auswählen.
2. DHCP wählen. Diese Methode bezieht die Interface-Adresse von einem DHCP-Server; sie richtet keinen DHCP-Server für Clients ein.
3. Das dokumentierte DHCP-Feldverfahren nennt zusätzlich die Eingabe einer IPv4-Adresse, eine optionale Änderung der Subnetzmaske sowie Gateway name und Gateway IP address. Die Beschreibung erklärt jedoch nicht, wie diese Angaben mit der vom DHCP-Server bezogenen Adresse zusammenwirken. Daraus weder eine manuelle Ersatzadresse noch ein Fallback oder ein Überschreiben des DHCP-Leases ableiten.
4. Vor dem Speichern die tatsächlich sichtbaren beziehungsweise editierbaren Felder im installierten Build prüfen und mit der freigegebenen DHCP-/Providerkonfiguration abgleichen. Keine statischen Beispielwerte in DHCP-Felder übernehmen. Ist die Rolle eines erforderlichen Feldes unklar, die Änderung nicht speichern, sondern mit dem Provider oder Support klären.
5. Nach geklärter Konfiguration mit Save speichern und prüfen, ob eine passende Adresse bezogen wird. Connecting bedeutet, dass noch ein Lease bezogen wird; bleibt der Zustand bestehen, zuerst Link, DHCP-Erreichbarkeit und Provideranforderungen untersuchen. Anschliessend IP, Maske, Gateway, DNS, Routing und den realen Management- und Datenpfad kontrollieren.

Fehlt nach einer dieser Änderungen der erwartete Pfad, über den unabhängigen Zugang die dokumentierte ursprüngliche Methode und ihre Werte wiederherstellen und erneut testen. PPPoE verwendet dagegen die Zugangsdaten des Providers; sein vollständiger Ablauf steht unter PPPoE-WAN einrichten und prüfen.

IPv6 am physischen Port: Methode und Empfangsmodus

Unter IPv6 configuration stehen auf WAN-Interfaces Static oder DHCP zur Verfügung; interne Interfaces bieten Static, DHCP oder Delegated. Delegated verwendet ein vom Provider delegiertes Präfix für interne Interfaces. Den vollständigen Ablauf mit WAN-DHCP, Upstream Interface und interner Verteilung erklärt IPv6 Prefix Delegation auf Sophos Firewall. Das ist eine eigene Aufgabe und ersetzt nicht die statische Konfiguration oder die Wahl des Empfangsmodus unten.

Static: IPv6-Adresse, Präfix und Gatewayfelder

1. Unter Network > Interfaces > Menu > Edit interface den physischen Port öffnen und IPv6 configuration auswählen.
2. Static wählen. Statische IPv6-Adressen sind für WAN- und interne Interfaces vorgesehen.
3. Die geplante IPv6-Adresse eintragen und das Präfix bei Bedarf an das zugewiesene Netz anpassen.
4. Die im Static-Verfahren aufgeführten Felder Gateway name und Gateway IP address gemäss der tatsächlich angezeigten Maske und dem Netzdesign ausfüllen. Die allgemeinen Static-Anweisungen nennen diese Felder auch im Abschnitt für WAN- und interne Interfaces; daraus weder ein zwingendes internes Default Gateway noch eine pauschale WAN-only-Feldregel ableiten. Unklare oder unerwartete Pflichtfelder vor einer produktiven Änderung klären.
5. Mit Save speichern und gespeicherte IPv6-Adresse und Präfix, gegebenenfalls Gateway, IPv6-Routing, DNS und erlaubte Verbindungen prüfen. Dabei den unabhängigen Adminzugang behalten; bei einem falschen Pfad die zuvor dokumentierten IPv6-Werte wiederherstellen.

Die Sicherungen vor dem IPv4-Verfahren gelten ebenso für IPv6: vorherige Methode und Werte dokumentieren, VLAN-Abhängigkeiten prüfen und den aktuellen Managementpfad nicht als einzigen Rückweg verwenden.

DHCPv6: Auto, Manual und Stateless

Nach Auswahl von DHCP unter IPv6 configuration bestimmt Mode, wie die Firewall selbst ihre Interface-Adresse empfängt. Das ist nicht dieselbe Einstellung wie ein Router-Advertisement-Server für interne Clients:

• Auto: Die Interface-Adresse wird automatisch entsprechend der verwendeten Konfigurationsmethode zugewiesen; diese kann DHCP only oder Stateless sein. Daraus keine hier nicht dokumentierte feste Auswahlregel ableiten.
• Manual > DHCP only: Die Firewall weist dem Interface die vom DHCPv6-Server gelieferte Adresse und die weiteren Parameter zu.
• Manual > Stateless: Die Firewall bildet die Interface-Adresse mit Stateless Address Auto-Configuration (SLAAC) entsprechend den in Router Advertisements angekündigten Managed- beziehungsweise Other-Flags (M/O). Mit Accept other configuration from DHCP können weitere Parameter vom DHCPv6-Server bezogen werden. Das macht den Empfangsmodus nicht zu DHCP only.

Optional verwendet DHCP rapid commit einen Austausch aus zwei Nachrichten (solicit und reply) statt vier (solicit, advertise, request und reply). Nur aktivieren, wenn Rapid Commit auch auf dem DHCPv6-Server aktiviert ist und zur freigegebenen Konfiguration passt. Das ist keine allgemeine Fehlerbehebung oder pauschale Leistungsoptimierung.

Das DHCPv6-Verfahren führt Gateway name und Gateway IP address auf. Bei Mode Manual und Stateless lässt sich Gateway IP address jedoch nicht setzen. Diese Einschränkung gehört zum Stateless-Modus und darf nicht auf Manual > DHCP only übertragen werden. Empfangsmodus und Gatewayfelder vor dem Speichern mit dem vorgesehenen RA-/DHCPv6-Design und der sichtbaren Maske abgleichen; keine Gateway-IP erzwingen, wenn der gewählte Modus sie nicht zulässt.

Nach Save die tatsächlich zugewiesene IPv6-Adresse, Präfix und weitere Parameter sowie Routing, DNS und einen erlaubten IPv6-Datenpfad prüfen. Bei falscher oder fehlender Adresse zuerst den gewählten Modus, die empfangenen RA-Flags und die DHCPv6-Erreichbarkeit mit der Gegenstelle vergleichen; nicht ungeprüft zwischen Modi wechseln. Bei einem unterbrochenen Managementpfad die vorherige Konfiguration über den unabhängigen Zugang wiederherstellen.

Port- und Link-Einstellungen abstimmen

Unter Advanced settings werden Link mode, Auto-negotiation for media type, modellabhängig Forward Error Correction (FEC) sowie MTU und MSS mit der Gegenstelle abgestimmt. Bei 25-, 50- und 100-Gbit/s-Ports wird zuerst der Link mode gespeichert, das Interface erneut geöffnet und danach die empfohlene Konfiguration geladen. Bei XGS 2100, 2300, 3100 und 3300 müssen alle SFP+-Ports der FleXi-Port-Module mit derselben Geschwindigkeit konfiguriert sein. Den vollständigen Ablauf mit Show recommended settings, Load recommended configuration, beiden Speicherschritten und der abweichenden Anzeige bei anderen Ports einschliesslich 40 Gbit/s zeigt Breakout-Interfaces und Port-Einstellungen konfigurieren.

SFOS unterstützt für selbst erzeugten DHCP- und ARP-Traffic keine DSCP-Markierung, auch wenn die Firewall als DHCP-Client, Relay oder Server arbeitet. Eine Policy darf für diese Pakete daher nicht auf DSCP-basierte Priorisierung vertrauen. Diese Einschränkung betrifft DSCP; sie ist keine Aussage, dass jede andere mögliche Priorisierung ausgeschlossen wäre.

Unter Advanced settings > Interface settings verwendet Use default MAC address die Standard-MAC des Interfaces. Im Kontext eines Interfaces mit Member-Ports liefert der zuerst aufgenommene Member-Port diese Standard-MAC. Override default MAC address erlaubt eine andere MAC-Adresse; ein Factory Reset stellt die Standard-MAC wieder her. Das ist keine Aufforderung zum Zurücksetzen und keine Voraussetzung für einen eigenständigen physischen PPPoE-Port. Vor einem begründeten Override die unten beschriebenen Abhängigkeiten und den Rückweg prüfen.

Die Portgeschwindigkeiten auf Firewall und Gegenstelle müssen zusammenpassen. Ein 25-Gbit/s-Port lässt sich beispielsweise nicht ohne passende Umsetzung über Breakout-Kabel mit einem 40-Gbit/s-Port verbinden. Unterstützte 40- und 100-Gbit/s-Ports der Firewall lassen sich mit geeigneten Breakout-Kabeln in zwei oder vier Ports aufteilen. Das ist keine Zusage für jede Appliance oder jede Kabelkombination; vor der Planung die Unterstützung der konkreten Ports, Transceiver und Gegenstelle prüfen.

IPv4-Adresse im interaktiven Recovery-Menü setzen

Unter 1. Network Configuration > Interface Configuration zeigt die CLI die IPv4-Adresse und Netzmaske, IPv6-Adresse und Präfix, Zone, Gateways sowie konfigurierte Aliases der physischen Ports. VLAN- und WLAN-Interfaces erscheinen in dieser Ansicht nicht.

Mit y beginnt die IPv4-Änderung. SFOS zeigt für jeden Port nacheinander die aktuelle Adresse, Netzmaske und Zone; Enter ohne neue Eingabe behält den jeweiligen Wert. Dieser Weg gilt nur im Gateway Mode und nur für statische IPv4-Werte. VLAN, DHCP, PPPoE, WLAN und WWAN lassen sich darüber nicht konfigurieren; der IPv6-Dialog unterscheidet sich.

Vor dem Ändern werden alle angezeigten Werte, Port-ID, Zone, Gateway, Aliases und ein unabhängiger Managementzugang gesichert. Nach dem Speichern werden Link, neue IP und Netzmaske, Gateway, Device Access, Routing, DNS und der echte Managementpfad geprüft. Bricht der Zugriff ab oder ist der Datenpfad falsch, werden über Console oder den unabhängigen Zugang die ursprünglichen Werte wiederhergestellt.

Link- und MAC-Werte in der Device Console korrigieren

WebAdmin bleibt der normale Konfigurationsweg. Die Device Console ist für einen dokumentierten Korrektur- oder Recovery-Fall gedacht, weil ein falscher Link-Wert den einzigen Managementpfad sofort unterbrechen kann. Vorher werden Port-ID, Gegenstelle, aktueller Link-Modus, Autonegotiation, FEC, unabhängiger Adminzugang und Rückweg gesichert.

Die offizielle SFOS-22-Syntax erlaubt für die aufgeführten Kupferwerte 1000fd, 100fd, 100hd, 10fd, 10hd oder auto:

Die folgenden Beispiele sind Alternativen, keine Befehlsfolge. Port2 durch den geprüften Hardware-Port ersetzen und genau eine Variante wählen, die zur freigegebenen Port- und Gegenstellenkonfiguration passt; nicht beide nacheinander ausführen. Vorher auf beiden Seiten die ursprünglichen Link-Modus-, Autonegotiation- und gegebenenfalls FEC-Werte sowie Linkstatus, tatsächliche Geschwindigkeit und Duplex dokumentieren. Unabhängigen Zugang und exakte Wiederherstellung über WebAdmin beziehungsweise ein für den installierten Build von Support bestätigtes Verfahren klären. Sind Ausgangswerte oder Rückweg unbekannt, vor der CLI-Änderung stoppen und Support hinzuziehen.

Alternative 1: automatische Geschwindigkeit und Duplex, zusätzliche Autonegotiation eingeschaltet:

set network interface-link Port2 linkmode auto autoneg on

Alternative 2: 1000 Mbps Full-Duplex, zusätzliche Autonegotiation ausgeschaltet:

set network interface-link Port2 linkmode 1000fd autoneg off

autoneg steuert zusätzliche Linkparameter ausserhalb von Speed und Duplex. FEC-Modi sind modellabhängig und werden von Sophos in diesem CLI-Befehl nicht allgemeingültig aufgelistet. Für 25-, 50- oder 100-Gbit/s-Ports wird deshalb kein Wert von einem anderen Modell übernommen, sondern die empfohlene Portkonfiguration der konkreten Appliance und des Transceivers verwendet.

Unmittelbar nach der gewählten Änderung die gespeicherten Link-Modus-, Autonegotiation- und gegebenenfalls FEC-Werte im WebAdmin und auf der Gegenstelle mit dem freigegebenen Soll vergleichen. Auf beiden Seiten Linkstatus, tatsächliche Geschwindigkeit und Duplex sowie den normalen Managementzugang und die benötigten realen Datenpfade prüfen. Bei fehlendem, instabilem oder schlechterem Pfad über den unabhängigen Zugang die exakt aufgezeichneten ursprünglichen Portwerte und alle für die Änderung angepassten Gegenstellenwerte wiederherstellen, einschliesslich geänderter FEC. Dafür den zuvor geklärten Wiederherstellungsweg verwenden und dieselben Prüfungen wiederholen; die Konfiguration beider Seiten muss wieder dem jeweiligen Ausgangsstand entsprechen. Keines der Beispiele, auch nicht auto mit autoneg on, ist ein pauschaler Rückweg.

Eine MAC-Adresse wird nur für eine nachgewiesene Designabhängigkeit überschrieben. Vor jeder Änderung werden die tatsächlich verwendete MAC-Adresse und der konfigurierte Zustand (default oder override, einschliesslich einer bereits vorhandenen eigenen Adresse) als Ausgangsstand dokumentiert. Port Security, DHCP-Bindings, Providerfreigaben, HA, LAG und die MAC-/ARP-Zuordnungen der Gegenstelle werden geprüft. Ein unabhängiger Adminzugang und ein Wartungsfenster müssen bereitstehen.

Die CLI-Beschreibungen für SFOS 22.0 und 23.0 sagen, dass default die bestehende MAC-Adresse beibehält. Das belegt nicht die Interpretation, dass es nach einem Override die Standard-MAC wiederherstellt. default ist kein bestätigter inverser Befehl und kein pauschaler Rückweg. Vor dem Override muss feststehen, wie Adresse und Zustand auf dem installierten Build exakt wiederhergestellt werden. Lassen sich Ausgangsstand oder Rückweg nicht verifizieren, wird nicht geändert, sondern mit Sophos Support geklärt.

Das folgende Beispiel verändert die MAC-Adresse und kann Management- und Datenverbindungen unterbrechen. Port2 wird durch den geprüften Port ersetzt; die lokal administrierte Beispieladresse muss durch die freigegebene, im eigenen Netz eindeutige Zieladresse ersetzt werden. Sie ist kein Wert für die Wiederherstellung:

set network macaddr Port2 override 02:00:5e:10:00:02

Für den verifizierten Rückweg gilt:

• War zuvor override mit einer eigenen MAC-Adresse konfiguriert, wird mit dem dokumentierten override-Zweig die exakt aufgezeichnete Adresse wieder gesetzt, nicht die Beispieladresse. Das Verfahren muss für den installierten Build bestätigt sein.
• War zuvor default konfiguriert, wird Use default MAC address unter Network > Interfaces > Edit interface > Advanced settings > Interface settings nur verwendet, wenn dieses Bedienelement und die Wiederherstellung des aufgezeichneten Ausgangsstands auf dem installierten Build bestätigt sind. Andernfalls braucht es ein von Sophos Support bestätigtes build-spezifisches Verfahren; ein CLI-default oder Factory Reset wird nicht als Ersatz versucht.

Nach Änderung und Wiederherstellung werden konfigurierter Zustand und tatsächlich verwendete Adresse mit dem jeweiligen Soll verglichen; beim Rückweg müssen beide dem aufgezeichneten Ausgangsstand entsprechen. Zusätzlich werden normaler Adminzugang, MAC-/ARP-Lernen der Gegenstelle und der betroffene reale Datenfluss geprüft. Bei Abweichungen wird über den unabhängigen Zugang gestoppt und mit Support geklärt, nicht mit weiteren MAC-Werten experimentiert.

MTU und MSS haben laut Sophos die Defaults 1500 und 1460; geändert werden sie nur nach dem kontrollierten Ablauf unter MTU und MSS bei VPN-Problemen prüfen.

Für IPv6 bestimmen DAD attempts, wie viele aufeinanderfolgende Neighbor-Solicitation-Nachrichten die Firewall bei der Duplicate Address Detection auf einer vorläufigen (tentative) Adresse sendet. Unter Allowed RA servers werden die MAC- oder IPv6-Adressen der Router-Advertisement-Server eingetragen, von denen dieses Interface eine stateless Konfiguration annehmen darf. Providerpräfix und interne Verteilung erklärt IPv6 Prefix Delegation auf Sophos Firewall; die Client-Flags und Präfixanzeigen stehen unter IPv6 Router Advertisement konfigurieren.

Für eine konkrete Aufgabe helfen die fokussierten Anleitungen:

• VLAN-Interface einrichten und testen
• SFOS-verwaltetes WLAN einrichten und testen
• Bestehende APX mit einem Wireless Mesh verbinden
• LAG-Interface konfigurieren
• GRE-Tunnel konfigurieren und testen
• IPv6 über IPv4 oder IPv4 über IPv6 mit einem IP-Tunnel transportieren
• Multicast zwischen Interfaces mit einer statischen Multicast-Route weiterleiten
• Dynamisches Multicast Routing mit PIM-SM planen und prüfen
• PPPoE-WAN einrichten und prüfen
• WAN-Failover mit einer zweiten Internetleitung einrichten
• Sophos SD-RED einrichten
• Device Access absichern
• Site-to-Site IPsec VPN einrichten

Zonenmodell planen

Zone, Interface und Netzwerkobjekt unterscheiden

Diese drei Elemente erfüllen unterschiedliche Aufgaben:

• Zone: beschreibt den Sicherheitsbereich, aus dem Traffic kommt oder in den er geht.
• Interface: verbindet die Firewall physisch oder virtuell mit einem Netz.
• Netzwerkobjekt: beschreibt die konkrete IP-Adresse oder das Subnetz in einer Regel.

Eine Regel ist erst präzise, wenn Zone und Netzwerkobjekt stimmen. Source zone: LAN zusammen mit Source networks: Any ist oft unnötig breit. Umgekehrt hilft ein korrektes Netzobjekt nicht, wenn das Paket über eine andere Zone eintritt als in der Regel angegeben.

Die Standard-Zonen haben feste Aufgaben:

• LAN für interne Netze
• WAN für Provider- und Internetverbindungen
• DMZ für exponierte oder besonders isolierte Systeme
• WiFi für WLAN-Kontexte
• VPN für Remote-Access- und Site-to-Site-Tunnel

Die Zone WiFi gilt für WLAN-Netze mit einer eigenen Zone. Bei Bridge to AP LAN und Bridge to VLAN entsteht dagegen kein dediziertes WiFi-Interface; der Datenpfad folgt der gewählten Bridge-Zuordnung.

Ein Wireless Network legt gemeinsame Einstellungen für WLAN-Clients fest: SSID, Sicherheitsmodus und die Behandlung des Client-Traffics. Mit dem Traffic Mode Separate zone erstellt die Firewall einen zugehörigen VXLAN-Tunnel. Die Auswahl des Traffic Mode bestimmt damit auch, wie das WLAN an die Firewall angebunden wird; sie ist nicht nur eine Bezeichnung für das Netz.

Eigene LAN-Zonen eignen sich etwa für Client, Server, Management, Guest, IoT, VoIP, Backup oder OT. Eine eigene DMZ-Zone passt zu veröffentlichten Servern, Reverse Proxies oder anderen Systemen, deren Zugriff ins interne Netz streng begrenzt werden soll.

Nicht jedes VLAN benötigt eine eigene Zone. Mehrere VLANs können zusammengefasst werden, wenn Vertrauensstufe, Firewall-Regeln und Device Access gleich sind. Unterscheiden sich erlaubte Ziele, Management-Zugriffe oder Schutzfunktionen, ist eine eigene Zone meist übersichtlicher.

Für VPN-Benutzer oder Standorttunnel werden keine eigenen VPN-Zonentypen erstellt. Die Trennung erfolgt in der Zone VPN mit präzisen Netzwerkobjekten, Benutzern und Firewall-Regeln.

Zugriffsrichtungen vor den Regeln festlegen

Vor der Konfiguration genügt eine kurze Liste der erlaubten Richtungen. Zum Beispiel:

• Client zu WAN: benötigte Web-, DNS-, NTP- und Anwendungsdienste
• Client zu Server: nur definierte Applikationsports
• Guest zu WAN: Internetzugriff, aber kein Zugriff auf interne Netze
• IoT zu Server: nur notwendige Ziele wie DNS, NTP oder eine Management-Plattform
• Management zu internen Zonen: administrative Dienste, eng begrenzt und geloggt
• DMZ zu LAN: standardmässig blockiert, nur explizit notwendige Verbindungen
• VPN zu Server: nur freigegebene Ziele und Dienste

Zu jeder erlaubten Richtung sollten Ziel, Dienste, NAT-Bedarf, Logging und verantwortliche Person bekannt sein. Daraus entstehen die eigentlichen Regeln. Aufbau, Reihenfolge und Matching erklärt Sophos Firewall-Regeln richtig konfigurieren.

Vor einer Änderung prüfen

Vor dem Anlegen oder Verschieben eines Interfaces sollten mindestens diese Punkte geklärt sein:

• Zone und Vertrauensstufe des Netzes
• IP-Adresse, Subnetz und Default Gateway
• DHCP-Quelle und DNS-Server
• benötigte lokale Firewall-Dienste
• Firewall- und NAT-Regeln
• Routing und SD-WAN
• Testclient, erwarteter Zugriff und erwarteter Logeintrag

Bei produktiven Änderungen gehören ein aktuelles Backup, ein Rückweg und eine Prüfung unter Object usage dazu.

VLAN anlegen und abnehmen

Ein VLAN bildet eine isolierte Broadcast-Domäne: Broadcasts bleiben innerhalb dieses VLANs. Die Zuordnung mehrerer VLANs zur selben Sicherheitszone hebt diese Layer-2-Trennung nicht auf; die Zone bestimmt den Kontext für Firewall-Regeln und Device Access.

Ein VLAN wird unter Network > Interfaces > Add interface > Add VLAN erstellt. Entscheidend sind:

• Interface: physisches, RED-, Bridge- oder LAG-Interface, auf dem das VLAN getaggt ankommt
• Network zone: Sicherheitsbereich des VLANs
• VLAN ID: muss mit Switch und gegebenenfalls Access Point übereinstimmen
• IPv4/IPv6 configuration: bei internen VLANs meist eine statische Gateway-Adresse

Ein Gäste-VLAN könnte beispielsweise auf Port3 mit VLAN ID 20, Zone Guest und der Gateway-Adresse 192.168.20.1/24 liegen. Am Switch muss VLAN 20 auf dem Uplink zu Port3 tagged sein; ein Client-Port oder die Gäste-SSID ordnet die Endgeräte diesem VLAN zu.

Die Firewall kann das Interface korrekt anzeigen, obwohl der Switch das VLAN am falschen Port, untagged oder mit einer anderen VLAN ID sendet. Deshalb ist ein VLAN erst fertig, wenn der gesamte Pfad getestet wurde:

1. VLAN ID, Parent Interface, Zone, IP-Adresse und Maske auf der Firewall prüfen.
2. Uplink zur Firewall als Trunk mit dem VLAN tagged konfigurieren.
3. Access-Port oder SSID dem richtigen VLAN zuordnen.
4. Mit einem Testclient DHCP, Gateway und DNS prüfen.
5. Einen erlaubten internen Zugriff sowie einen bewusst verbotenen Zugriff testen.
6. Internetzugriff prüfen und im Log Viewer die erwartete Firewall Rule ID bestätigen.

Für internen Traffic ist NAT normalerweise nicht erforderlich. Wenn der Client eine Adresse erhält, aber die Firewall nicht als DNS-Server oder per Ping erreicht, zuerst Device Access prüfen. Der vollständige Ablauf mit Switch-Tagging und DHCP steht in Sophos Firewall VLAN einrichten und testen.

Sophos nennt für XGS Appliances keine feste maximale Anzahl VLANs pro physischem Parent-Port. Trotzdem können mehrere Uplinks oder ein LAG bei hoher Last, vielen VLANs oder HA-Designs Betrieb und Fehlersuche vereinfachen.

Den richtigen Interface-Typ wählen

Virtuelle Interfaces und Aliases werden unter Network > Interfaces über Add interface angelegt. Dort den gewünschten Typ auswählen und dessen Konfiguration öffnen. Die folgenden Abschnitte helfen bei der Typwahl; ein Alias ergänzt eine bestehende Schnittstelle, während beispielsweise VLAN, Bridge und LAG unterschiedliche logische Verbindungen abbilden.

Alias

Ein Alias fügt einem bestehenden Interface eine weitere IP-Adresse hinzu. Das ist besonders nützlich, wenn ein Provider mehrere öffentliche IP-Adressen im gleichen Subnetz bereitstellt.

Wie man die zusätzliche Adresse bindet, für Regeln und NAT als Hostobjekt verwendet sowie ARP und Systemtraffic prüft, zeigt Alias-IP auf Sophos Firewall einrichten und testen.

Mehrere getrennte WAN-Interfaces im gleichen Subnetz können ARP-Probleme und nicht erreichbare Gateways verursachen. In diesem Fall ist ein Alias auf dem bestehenden WAN-Interface oder ein passend geplantes LAG meist die sauberere Lösung. Ein Alias folgt dem Status seines Parent-Interfaces und lässt sich nicht unabhängig deaktivieren.

Bridge

Eine Bridge verbindet mehrere Interfaces auf Layer 2. Sie kann mit einer IP-Adresse für gerouteten Traffic oder ohne IP transparent betrieben werden. Für neue segmentierte Netze sind VLANs meist klarer; Bridges eignen sich eher für Migrationen oder bewusst transparente Designs.

Den vollständigen Ablauf mit Membern, STP, VLAN- und EtherType-Filtern, Regeln und Abnahme beschreibt Bridge-Interface auf Sophos Firewall einrichten.

Dabei gelten wichtige Einschränkungen:

• Eine Bridge unterstützt kein Dynamic DNS, DHCP-Client, PPPoE oder IPsec VPN.
• Für Traffic zwischen Bridge-Membern können weiterhin Firewall-Regeln, beispielsweise LAN-to-LAN, erforderlich sein.
• HA lässt sich nicht aktivieren, solange STP auf einer Bridge aktiv ist.
• Ist ein VLAN-Filter eingeschaltet, aber kein VLAN erlaubt, verwirft die Firewall alle getaggten Frames; untagged Traffic bleibt davon unberührt.
• Traffic über eine Bridge ohne IP kann ohne Logeintrag verworfen werden, wenn er eine Web-Proxy-Regel oder NAT-Regel trifft.

Bei einer transparenten Bridge sollte deshalb geprüft werden, ob Web Proxy Filtering oder Source Translation wirklich erforderlich sind.

Sophos dokumentiert NC-177630 für SFOS 22.0.0 GA-Respin Build 411. Der Fehler kann auftreten, wenn gerouteter Traffic über eine Bridge mit SNAT oder MASQ übersetzt wird und Ein- sowie Ausgang denselben physischen Bridge-Member verwenden. Antwortpakete werden dann vom Hairpin-Filter verworfen, ohne in drppkt zu erscheinen. Das gilt auch, wenn nur ein Bridge-Member aktiv ist. Traffic über unterschiedliche physische Member oder ohne SNAT/MASQ ist nicht betroffen.

Sophos führt SFOS 22.0.1 MR1 Build 490 als Fix-Version. Auf GA-Respin Build 411 darf man SNAT oder MASQ für den betroffenen Flow nur entfernen, wenn die Übersetzung nicht benötigt wird und der Rückweg zur ursprünglichen Client-IP vorhanden ist. Alternativ wird der Traffic über ein dediziertes physisches Interface statt über die Bridge geroutet. Fehlt einer der beschriebenen Auslöser oder tritt das Problem auf MR1 Build 490 beziehungsweise neuer auf, muss nach einer anderen Ursache gesucht werden. Der separate SFOS-22-Fall für VLAN-Traffic zur Firewall ist in Bridge-VLANs nach SFOS 22 prüfen beschrieben.

Eine Bridge über RED kann ein Layer-2-Netz über Standorte verlängern, sollte aber ein begründeter Sonderfall bleiben.

Broadcasts, ARP und unbekannter Unicast-Traffic laufen dabei über die WAN-Verbindung. Ein geroutetes Design mit eigenen Standortsubnetzen und gezielten Firewall-Regeln ist stabiler, skalierbarer und leichter zu untersuchen.

LAG

Eine Link Aggregation Group fasst zwei bis vier physische Interfaces zu einem logischen Uplink zusammen. Darauf können wiederum VLANs betrieben werden.

Die üblichen Betriebsarten sind:

• Active-Backup: Ein Link ist aktiv, ein anderer übernimmt bei Ausfall.
• LACP (802.3ad): Mehrere Links können parallel genutzt werden; Firewall und Switch müssen identisch konfiguriert sein.

Als Mitglieder kommen ungebundene physische Interfaces mit statischer Konfiguration infrage. PPPoE-, Cellular-WAN- und WLAN-Interfaces sind ausgeschlossen. Bei LACP müssen die Ports denselben Typ und dieselbe Geschwindigkeit haben.

Die xmit-hash-policy verteilt Verbindungen auf die Links. Eine einzelne TCP-Verbindung wird dadurch normalerweise nicht schneller, weil sie auf einem Link bleibt. LAG bringt vor allem Redundanz und zusätzliche Gesamtbandbreite für mehrere parallele Verbindungen.

LAG und WAN-Failover lösen unterschiedliche Aufgaben: Ein LAG bündelt physische Links zu einer logischen Verbindung. Unabhängige Internetleitungen werden dagegen über ihre WAN-Gateways unter Network > WAN link manager genutzt. Mehrere aktive Gateways ermöglichen eine Lastverteilung auf die verfügbaren Leitungen; ein Backup-Gateway kann bei einem erkannten Ausfall übernehmen. Das garantiert weder unterbrechungsfreie bestehende Sitzungen noch mehr Bandbreite für eine einzelne Verbindung. Den Ablauf und die Erfolgskontrolle erklärt WAN-Failover mit einer zweiten Internetleitung einrichten.

Cellular WAN und WWAN1

Beim Aktivieren von Cellular WAN erstellt SFOS das Interface WWAN1. Es gehört zur Mobilfunkanbindung und ist nicht mit einem frei angelegten VLAN oder Alias gleichzusetzen. Die unten beschriebenen Einschränkungen für HA sowie der Ausschluss als LAG-Mitglied bleiben zu beachten.

In SFOS 23.0 bietet Network > Interfaces im Menu des WWAN-Interfaces die Aktionen Connect und Disconnect, um das Cellular-WAN-Modem zu verbinden oder zu trennen. Reset startet das Modem neu und ist nur für 5G-Modelle von Quectel und Sierra Wireless verfügbar, nicht für andere Modelle oder USB-Dongles. Diese in SFOS 23.0 beschriebenen Aktionen sind nicht als identischer Klickpfad für SFOS 22.0 vorauszusetzen.

Vor Disconnect oder Reset einen unabhängigen Adminzugang und ein Wartungsfenster sicherstellen, wenn die Mobilfunkverbindung produktiven Traffic oder den Managementzugang trägt. Ein Hardware-Neustart über das Herunterfahren der Firewall unterbricht den gesamten Firewall-Traffic; auch dafür einen unabhängigen Adminzugang und ein Wartungsfenster einplanen. Für einen Hardware-Neustart eines nicht unterstützten Modells die Firewall zuerst herunterfahren, das Modem aus- und wieder einstecken und die Firewall wieder starten; keine physische WWAN-Hardware bei laufender Firewall ändern. Danach den Interface-Status und den benötigten Daten- und Managementpfad prüfen. Ein Modemneustart ist keine zugesicherte Lösung für einen ungeklärten Verbindungsfehler.

TAP / Discover Mode

Ein physischer Port im Discover Mode empfängt eine vom Switch gespiegelte Traffic-Kopie. Er steht nicht inline und kann den beobachteten Traffic weder blockieren noch mit Security Policies steuern. Für eine Bestandsaufnahme oder einen Proof of Concept ist das nützlich, als produktiver Schutzpfad reicht es nicht.

In der Interface-Übersicht ist dieser Port als Discover, physical (TAP) aufgeführt. So lässt er sich von einem normalen Interface im produktiven Datenpfad unterscheiden.

Die vollständige Konfiguration mit SPAN-Port, Device-Console-Befehlen, Packet Capture, Security Audit Report und HA-Grenzen erklärt Discover Mode mit TAP und SPAN einrichten.

XFRM für route-based IPsec

Bei route-based IPsec unterscheidet man zwischen Any-to-any und Verbindungen mit konkreten Traffic Selectors. Sind beide Subnetze auf Any gesetzt, erstellt SFOS automatisch ein XFRM-Interface in der Zone VPN:

• Any-to-any: Dem automatisch erstellten XFRM muss man unter Network > Interfaces eine IP-Adresse zuweisen. Anschliessend bestimmen statische, SD-WAN- oder dynamische Routen den Tunneltraffic.
• Traffic Selectors: Beim Tunnelaufbau erstellt SFOS automatisch eine statische Route. Wird ein XFRM angezeigt, darf man ihm weder eine eigene IP-Adresse noch manuelle Routen zuweisen.

Zur XFRM-Erstellung bei konkreten Subnetzen widersprechen sich die offiziellen SFOS-22- und SFOS-23-Dokumentationen: «Configure an XFRM interface» beschreibt, dass kein XFRM entsteht; «Route-based VPN» beschreibt dagegen die Erstellung eines XFRM pro Konfiguration. Deshalb weder eine stets vorhandene noch eine stets fehlende Schnittstelle voraussetzen. Unter Network > Interfaces das Listening Interface aufklappen und die tatsächliche Sichtbarkeit im installierten Build prüfen. Den bestehenden Sichtbarkeits- und Traffic-Check erklärt Site-to-Site IPsec VPN einrichten im Abschnitt Traffic Selectors.

In beiden Fällen braucht der VPN-Traffic passende Firewall-Regeln. Unter Administration > Device access erlaubt IPsec in der Zone WAN eingehende IPsec-Verbindungsanfragen. Ping auf eine lokale Firewall-Adresse aus der Zone VPN wird separat über Ping/Ping6 unter Administration > Device access freigegeben. Ping zwischen Hosts durch den VPN-Tunnel ist dagegen Durchgangstraffic und benötigt passende Routen und Firewall-Regeln; die Device-Access-Freigabe erlaubt diesen Traffic nicht.

Ein XFRM wird nicht direkt unter Network > Interfaces deaktiviert, sondern über seine Verbindung unter Site-to-site VPN > IPsec. Wenn SSL/TLS Decryption auf IPsec-Traffic angewendet wird, muss die XFRM-MTU laut Sophos mindestens 113 Byte kleiner als die MTU des Listening Interface sein. Bei einer MTU von 1400 am Listening Interface sind für XFRM also höchstens 1287 zulässig. Das ist eine produktspezifische Vorgabe für FastPath Offload, kein allgemeiner Wert für jeden Tunnel. Den vollständigen Prüfablauf für MTU und MSS zeigt MTU und MSS bei VPN-Problemen prüfen.

RED

Ein RED-Interface bindet einen Aussenstandort über einen verschlüsselten Tunnel an. Der Betriebsmodus bestimmt, wie viel Traffic über die Zentrale läuft:

• Standard/Unified: Die zentrale Firewall verwaltet und filtert den gesamten Standorttraffic. Fällt der Tunnel aus, kann auch der Internetzugang ausfallen.
• Standard/Split: Nur definierte Zielnetze laufen durch den Tunnel; Internettraffic geht lokal hinaus und wird nicht zentral gefiltert.
• Transparent/Split: Das RED arbeitet transparent in einem bestehenden Netz. Das ist flexibel, aber schwerer zu planen und zu untersuchen.
• Manual/Split: Die Netzwerkkonfiguration erfolgt stärker manuell und kann lokale Autonomie ermöglichen.

Der RED-Service muss unter System services > RED aktiv sein. Für die Verbindung werden typischerweise TCP 3400, UDP 3410 sowie NTP über UDP 123 benötigt. DNS, korrekte Systemzeit und ausgehender Internetzugriff müssen funktionieren.

Das VLAN-Verhalten hängt von RED-Modell, Betriebsmodus, LAN-Portmodus und WLAN-Konfiguration ab. Sophos empfiehlt Standard/Unified, wenn VLANs hinter dem RED eingesetzt werden; bei einer SD-RED 60 ist VLAN-Tagging nur in diesem Modus möglich. WLAN mit Bridge to VLAN folgt eigenen Regeln. DHCP, Gateway, Internetpfad und Ausfallverhalten der vier Modi erklärt Sophos RED Betriebsarten richtig wählen. Provisionierung, LED-Status und Fehlerbehebung beschreibt Sophos SD-RED einrichten.

Status und Device Access prüfen

Interface-Status

Unter Network > Interfaces zeigen die Statuswerte, ob zuerst der Link oder die Policy untersucht werden sollte:

• Not configured: keine Zone zugewiesen
• Connected: konfiguriert und verbunden
• Connecting: bezieht gerade eine Adresse, beispielsweise per DHCP
• Disconnected: Adresse wurde freigegeben
• Disconnecting: Adresse wird gerade freigegeben
• Unplugged: keine physische Verbindung; bei WiFi gegebenenfalls kein Access Point oder Wireless Network
• Not available: konfigurierter FleXi Port ohne vorhandenes FleXi-Port-Modul

Bei Not configured oder Unplugged sind Firewall-Regeln noch nicht der erste Ansatz. Zuerst Zone Binding, Kabel, SFP, Portgeschwindigkeit, Switch-Port sowie DHCP oder PPPoE prüfen.

Lokale Firewall-Dienste

Unter Administration > Device access wird pro Zone festgelegt, ob lokale Dienste wie HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO oder Wireless Protection erreichbar sind.

Diese Freigaben gelten für die Firewall selbst. Durchgangstraffic zwischen Netzen wird mit Firewall-Regeln gesteuert. HTTPS und SSH sollten nur aus einem Management-Netz oder über eine gezielte Local service ACL exception rule erlaubt sein. DNS wird benötigt, wenn Clients die Firewall als DNS-Server verwenden.

⚠️ Wenn Clients den Web Proxy der Firewall verwenden dürfen, behandelt SFOS HTTP- und HTTPS-Anfragen als interne Proxy-Anfragen. Dadurch können WebAdmin, Captive Portal, VPN Portal oder User Portal erreichbar sein, obwohl der entsprechende Dienst für die Client-Zone deaktiviert ist. In diesem Design müssen Proxyzugriff und lokale Portale separat geprüft werden.

Abhängigkeiten und Änderungen sicher behandeln

Object Usage vor Bearbeiten oder Löschen

Zone Binding, DNS, Gateways, SD-WAN, Interface-Hosts, VLANs, Dynamic DNS, DHCP, Firewall-Regeln, NAT und VPN können vom selben Interface abhängen. Object usage zeigt diese Referenzen.

Der angezeigte Zähler wird automatisch nur einmal täglich aktualisiert. Vor einer Änderung oder Löschung deshalb Refresh anklicken und die wichtigen Abhängigkeiten dokumentieren. Nicht jede Referenz lässt sich im Pop-up bearbeiten. WAN-Gateways und CLI-Konfigurationen müssen auf ihrer jeweiligen Konfigurationsseite beziehungsweise in der CLI geändert werden.

Für bearbeitbare Regel- oder Policy-Referenzen führt der Weg vom Zähler zur konkreten Konfiguration:

1. In der Spalte Usage die Nutzungsanzahl des betroffenen Objekts anklicken. Das Pop-up zeigt, in welchen Konfigurationen das Objekt verwendet wird.
2. Die passende Kategorie über das Plus-Symbol aufklappen, um die zugehörigen Regeln oder Policies anzuzeigen.
3. Die betroffene Regel oder Policy anklicken, um sie zu bearbeiten. Dort die Referenz auf das Objekt entfernen oder durch das gewünschte Ersatzobjekt ersetzen.

Nach der Abhängigkeitsprüfung erfolgt das Ein- oder Ausschalten unter Network > Interfaces im Menu des betroffenen Interfaces mit on beziehungsweise off. Vor off den unabhängigen Adminzugang und den Rückweg sicherstellen; die Aktion kann den gerade verwendeten Datenpfad unterbrechen. Alias und XFRM lassen sich hier nicht unabhängig ausschalten.

Beim Deaktivieren bleibt die Interface-Konfiguration erhalten. IPsec-Tunnel, bei denen die Firewall Initiator ist, werden sofort getrennt. Responder-Tunnel und Remote-Access-Verbindungen enden spätestens durch Inaktivität oder Dead Peer Detection.

Ein virtuelles Interface wird unter Network > Interfaces über Menu > Delete interface gelöscht. Diese Aktion erst nach Refresh unter Object usage, dokumentierter Abhängigkeitsprüfung sowie vorbereitetem Backup und Rückweg ausführen; sie entfernt nicht nur den sichtbaren Interface-Eintrag.

Beim Löschen eines virtuellen Interfaces löscht SFOS alle Firewall-Regeln, in denen es verwendet wird, auch wenn die Regel noch andere Interfaces enthält. Zusätzlich werden abhängige Zone Bindings, DHCP-Server oder Relays, statische und Proxy-ARP-Einträge, Protected Server und darauf basierende Firewall-Regeln, Interface-Hosts und deren Gruppenreferenzen sowie Unicast- und Multicast-Routen entfernt. Alias-Interfaces folgen ihrem Parent; XFRM-Interfaces werden über die IPsec-Verbindung verwaltet.

Auch eine reine Bearbeitung kann Zone Binding, DNS, Gateway, SD-WAN-Routen und -Profile, Interface-Hosts, VLANs und Dynamic DNS beeinflussen. Nach dem Bearbeiten oder Löschen können Verbindungen vorübergehend nicht reagieren oder ausfallen. Nach jeder Änderung deshalb den tatsächlichen Daten- und Managementpfad prüfen, nicht nur den gespeicherten Interface-Eintrag.

Konfiguration eines physischen Ports gezielt entfernen

Ein physischer Port bleibt auf der Appliance vorhanden; nur seine Konfiguration lässt sich entfernen. off und Network zone None sind dabei nicht gleichwertig: off behält die Konfiguration, None entfernt die IP-Konfiguration. Diese Aktion dient zum bewussten Freigeben eines nicht mehr benötigten Ports, nicht als erster Reparaturschritt bei Unplugged oder einem nicht erreichbaren Gateway.

⚠️ Vor dem Entfernen Object usage > Refresh ausführen, die Abhängigkeiten dokumentieren und migrieren sowie Backup und unabhängigen Adminzugang testen. IP-Adressen, Masken oder Präfixe, Zone, Gateways und Aliases für den Rückweg festhalten. Den Port nicht über den einzigen Managementzugang zurücksetzen.

1. Unter Network > Interfaces den betroffenen physischen Port öffnen.
2. Network zone auf None setzen. Bereits in der Maske verschwindet die IP-Konfiguration; vor dem nächsten Schritt nochmals die Port-ID prüfen.
3. Mit Save speichern.
4. In der Übersicht müssen Unbound, Status Disabled und IP-Adresse N/A erscheinen. Anschliessend über den unabhängigen Zugang prüfen, dass die benötigten anderen Daten- und Managementpfade weiterhin funktionieren.

Wurde der falsche Port zurückgesetzt, seine bisherige Zone und IP-Konfiguration über den unabhängigen Zugang oder die Konsole wiederherstellen. Entfernte abhängige Konfigurationen anhand der vorherigen Inventur beziehungsweise des Backups wiederherstellen; das erneute Zuweisen einer Zone ist kein Ersatz dafür. Abschliessend Link, Gateway, DHCP, DNS, Routing, Regeln und Device Access erneut testen.

HA und Remote-Änderungen

Dedizierte HA-Link-Interfaces gehören in eine DMZ-Zone. Andere überwachte oder für Administration verwendete Interfaces können in anderen Zonen liegen.

Für Active-Active HA sind statisch konfigurierte Interfaces erforderlich. Cellular WAN wird bei HA deaktiviert. Active-Passive kann dynamisch adressierte WAN-Interfaces verwenden, Verbindungen wie PPPoE werden bei einem Failover jedoch nicht zwingend samt Sitzung übernommen.

Vor einer produktiven Änderung:

1. Konfiguration und Abhängigkeiten dokumentieren.
2. Wartungsfenster, Rückfallzeitpunkt, Backup und konkreten Rückweg vorbereiten.
3. Einen unabhängigen Admin-Zugang testen, etwa Sophos Fusion (ehemals Sophos Central), zweites WAN, separates Management-Netz oder eine Person vor Ort.
4. Testclient oder eindeutigen Testtraffic vorbereiten; danach die neue Zone oder den neuen Pfad ergänzen und testen.
5. Link, IP, Gateway, DHCP, DNS, Firewall-Regeln, NAT und Device Access kontrollieren.
6. Alte Objekte erst löschen, wenn der neue Pfad stabil läuft.

Bei einem VLAN-Trunk gehören alte VLAN ID, Native VLAN und Switch-Portprofil in den Rückweg. Bei WAN-Änderungen sind Providerwerte und SD-WAN-Routen wichtig; bei XFRM zusätzlich Tunnel, Routing und beide Firewall-Richtungen.

Fehler systematisch finden

Die Ursache lässt sich meist schneller eingrenzen, wenn zuerst das Symptom betrachtet wird:

• Interface ist unbound oder disabled: Zuerst prüfen, ob dem Port bewusst keine Zone zugewiesen oder das Interface ausgeschaltet wurde. War der Port zuvor produktiv, die erwartete Zone und IP-Konfiguration mit der dokumentierten Konfiguration vergleichen und über einen unabhängigen Zugang wiederherstellen. None ist keine Reparatur, sondern entfernt die IP-Konfiguration; den bewussten Ablauf erklärt oben Konfiguration eines physischen Ports gezielt entfernen.
• VLAN funktioniert nicht: VLAN ID, Parent Interface, Trunk, Tagged/Untagged und Native VLAN vergleichen.
• Firewall ist nicht per Ping, HTTPS oder DNS erreichbar: Device Access und Local-Service-ACL prüfen, nicht zuerst eine normale Firewall-Regel.
• Interner Traffic wird blockiert: Source zone, Destination zone, Netzobjekte, Routing, Services und Regelreihenfolge prüfen.
• WAN-Gateway bleibt inaktiv: Link, IP, Gateway, PPPoE-Zugangsdaten und WAN Link Manager prüfen.
• Mehrere WAN-Ports liegen im selben Subnetz: ARP-Probleme vermeiden und Alias oder LAG prüfen.
• SFP oder Port-Speed passt nicht: SFP und SFP+ systematisch prüfen und dabei Transceiver, Kabel, Breakout und Geschwindigkeit auf beiden Seiten vergleichen.
• VPN oder PPPoE wirkt instabil: MTU und MSS prüfen.

Für die eigentliche Fehlersuche ist diese Reihenfolge sinnvoll:

1. Network > Interfaces: Link, IP, Zone und Gateway
2. Network > Zones: Zonentyp und Device Access
3. Hosts and services: Netzwerk- und Serviceobjekte
4. Firewall rules: Richtung, Reihenfolge, Services und Logging
5. NAT rules: Original und Translation
6. Log viewer: Rule ID oder Drop-Grund
7. Diagnostics > Tools > Packet capture: Eingang und Weiterleitung des Pakets

Wenn die Regel korrekt aussieht, aber nicht matched, hilft Firewall-Regel greift nicht. Den Paketfluss erklärt Packet Capture im WebAdmin verwenden.

Betriebscheckliste

• Zonen nach Vertrauensstufe geplant und dokumentiert
• Zone, Interface und Netzwerkobjekt nicht miteinander verwechselt
• VLAN ID, Parent, Trunk und Gateway geprüft
• Device Access besonders für HTTPS, SSH, DNS, Ping und Portale eingeschränkt
• Firewall-Regeln mit konkreten Zonen, Netzen, Diensten und Logging erstellt
• Alias für zusätzliche Provider-IP-Adressen im gleichen Subnetz geprüft
• DHCP, DNS, NTP, Routing und gegebenenfalls NAT getestet
• Object Usage aktualisiert und vor Änderungen kontrolliert
• Unabhängiger Admin-Zugang und Rückweg vorbereitet
• Link-Status, Log Viewer und Packet Capture nach der Änderung geprüft

FAQ