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.

Für eine konkrete Aufgabe helfen die fokussierten Anleitungen:

• VLAN-Interface einrichten und testen
• SFOS-verwaltetes WLAN einrichten und testen
• LAG-Interface konfigurieren
• 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

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.

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.

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.

Die Sophos Known Issues List beschreibt zusätzlich einen build-gebundenen Fehler für SFOS 22.0 GA Build 411 und MR1 Build 490: Wird Traffic über eine Bridge mit SNAT oder MASQ übersetzt und liegen Quelle und Ziel hinter demselben physischen Bridge-Member, können Antwortpakete am Hairpin-Filter verworfen werden, ohne in drppkt zu erscheinen. Das gilt auch, wenn nur ein Bridge-Member aktiv genutzt wird. Nicht betroffen ist Traffic über unterschiedliche physische Member oder ohne SNAT/MASQ. Neuere Builds wie 22.0 MR2 Build 546 sind in der aktuellen Known Issues List nicht als betroffen aufgeführt.

Wenn nur bestimmte Bridge-Verbindungen scheitern, sollte man daher Topologie und NAT gemeinsam prüfen, testweise auf Source Translation verzichten oder ein geroutetes Design verwenden. 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.

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. Die Auswahl des Modus sowie 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 kann SFOS abhängige Firewall-Regeln, DHCP-Konfigurationen, ARP-Einträge, Routen, Interface-Hosts und weitere Referenzen entfernen. 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: Zone Binding und Status prüfen. Ein physischer Port wird nicht gelöscht; seine Konfiguration kann mit Zone None entfernt werden.
• 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