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. Insgesamt unterstützt die Firewall bis zu 100 Zonen.

Physisches Interface konfigurieren

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

1. Einen sprechenden Name 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.

Nur Interfaces in der Zone WAN erhalten eine Gateway-Konfiguration. Interne Interfaces werden normalerweise statisch adressiert; WAN-Verbindungen können statisch, per DHCP oder PPPoE konfiguriert sein.

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. SFOS unterstützt für selbst erzeugten DHCP- und ARP-Traffic keine DSCP-Markierung; eine Policy darf davon keine priorisierte Behandlung erwarten.

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:

set network interface-link Port2 linkmode auto autoneg on
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.

Eine MAC-Adresse wird nur für eine nachgewiesene Designabhängigkeit überschrieben. Die Beispieladresse ist lokal administriert, muss in der realen Umgebung aber trotzdem eindeutig sein:

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

Vor dem Override werden Port Security, DHCP-Bindings, Providerfreigaben, HA und LAG geprüft. default stellt die vorhandene Standard-MAC des Ports wieder her. 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 Neighbor-Solicitation-Nachrichten die Firewall bei der Duplicate Address Detection 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.

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 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

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.

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.

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 einer route-based IPsec-Verbindung erstellt SFOS automatisch ein XFRM-Interface in der Zone VPN. Das gilt sowohl für Any-to-any als auch für Verbindungen mit Traffic Selectors:

• 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: SFOS erstellt das XFRM und beim Tunnelaufbau automatisch eine statische Route. Diesem XFRM kann keine eigene IP-Adresse zugewiesen und keine eigene Route hinzugefügt werden.

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 dem Tunnel wird separat für VPN freigegeben.

Ein XFRM wird nicht direkt unter Network > Interfaces deaktiviert, sondern über seine Verbindung unter Site-to-site VPN > IPsec. Bei Fragmentierungsproblemen sind MTU und MSS relevant; den Prüfablauf 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.

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.

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, ARP-Einträge, Protected Server, Interface-Hosts und deren Gruppenreferenzen sowie Unicast- und Multicast-Routen entfernt. Alias-Interfaces folgen ihrem Parent; XFRM-Interfaces werden über die IPsec-Verbindung verwaltet.

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 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: Ein physischer Port selbst lässt sich nicht löschen. Um nur seine Konfiguration zu entfernen, unter Network > Interfaces den Port öffnen, Network zone auf None setzen und speichern. Danach zeigt SFOS das Interface als Unbound, den Status als Disabled und die IP-Adresse als N/A. Zuvor Object Usage und Admin-Rückweg prüfen.
• 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