Sophos Firewall Zonen und Interfaces konfigurieren

Zonen und Interfaces gehören zu den wichtigsten Grundlagen einer Sophos Firewall. Wer sie sauber plant, macht spätere Firewall Regeln, NAT, VPN, Web Protection und Troubleshooting deutlich einfacher. Wer sie zu schnell zusammenklickt, baut sich dagegen oft eine Umgebung, in der Regeln unübersichtlich werden oder Management-Dienste an falschen Stellen erreichbar sind.

Eine Zone ist eine logische Sicherheitsgruppe. Ein Interface ist ein physischer oder virtueller Anschluss, zum Beispiel Port1, ein VLAN, eine Bridge, ein LAG, ein Alias, ein RED-Interface oder ein XFRM-Interface für route-based VPN. Jedes Interface ist genau einer Zone zugeordnet. Firewall Regeln arbeiten später stark mit diesen Zonen, deshalb sollte die Zonenstruktur nicht nur technisch, sondern sicherheitlich geplant werden.

Welcher Netzwerkdesign-Artikel passt?

Zonen und Interfaces sind oft der Startpunkt, aber nicht immer das eigentliche Ziel der Konfiguration. Je nach Aufgabe passt ein spezifischerer Artikel besser:

• Zonen, Interfaces, VLANs, Bridges, LAG oder RED grundsätzlich planen: Dieser Artikel.
• VLAN-Interface mit Parent Interface, DHCP, Device Access und Regeln einrichten: Sophos Firewall VLAN einrichten und testen.
• Firewall-Regeln zwischen Zonen erstellen und verstehen: Sophos Firewall-Regeln verstehen und richtig konfigurieren.
• VLAN-Bridge-Verhalten nach SFOS 22 prüfen: Sophos Firewall Bridge mit VLAN Tagging einsetzen.
• Management-Dienste wie WebAdmin, SSH, User Portal oder DNS absichern: Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.
• NAT, SNAT, DNAT oder MASQ mit Interfaces und Zonen einordnen: NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.
• Internen Server über WAN oder DMZ veröffentlichen: Server per DNAT auf Sophos Firewall veröffentlichen.
• DNS für interne Domains oder AD-Zonen steuern: DNS Request Routes auf Sophos Firewall einrichten.
• DHCP-Optionen für VoIP, PXE oder spezielle Clients setzen: DHCP Options auf Sophos Firewall konfigurieren.
• Site-to-Site VPN mit Tunnel-Interfaces planen: Sophos Firewall Site-to-Site IPsec VPN einrichten.
• Traffic kommt nicht über die erwartete Zone oder Regel: Sophos Firewall Regel greift nicht: Ursachen prüfen.

Diese Trennung verhindert typische Designfehler. Eine Zone ersetzt keine Firewall-Regel, ein VLAN ersetzt kein Sicherheitskonzept, und Device Access ist nicht dasselbe wie normaler Traffic zwischen zwei Netzen. Zuerst sollte klar sein, welche Sicherheitsbereiche existieren. Danach werden Interfaces, VLANs, Regeln, NAT, DNS und Management-Zugriffe passend dazu gebaut.

Warum Zonen wichtig sind

Zonen sind auf der Sophos Firewall mehr als nur eine optische Gruppierung. Damit werden Sicherheitsbereiche definiert, die an mehreren Stellen verwendet werden:

• Firewall Regeln arbeiten mit Source zone und Destination zone.
• Device Access steuert pro Zone, welche lokalen Firewall-Dienste erreichbar sind.
• NAT, SD-WAN, VPN, Web Protection und Logs werden durch saubere Zonen einfacher nachvollziehbar.
• Troubleshooting wird klarer, weil man sofort sieht, aus welchem Sicherheitsbereich ein Paket kommt und wohin es gehen soll.

Eine gute Zonierung verhindert nicht automatisch jeden Fehler, aber sie zwingt zu klaren Grenzen. Ein Client-Netz, ein Servernetz, ein Gäste-WLAN und eine DMZ sollten nicht einfach alle als „LAN“ behandelt werden, wenn sie unterschiedliche Risiken und Regeln haben. Sonst entstehen später grosse Allow-Regeln, unklare Ausnahmen und unnötig offene Management-Zugriffe.

Gute Zonen beantworten immer diese Frage: Welche Netze haben dieselbe Vertrauensstufe und dürfen ähnlich behandelt werden? Wenn zwei Netze unterschiedliche Zugriffsrechte, Logging-Anforderungen oder Management-Zugriffe brauchen, ist eine eigene Zone oder zumindest ein sehr bewusstes Regelkonzept sinnvoll.

Wichtig ist die Trennung zwischen Zone und Netzobjekt. Die Zone beschreibt, über welchen Sicherheitsbereich ein Paket in die Firewall kommt oder wohin es gehen soll. Das Netzobjekt beschreibt die konkrete IP-Quelle oder das konkrete Ziel. Eine Regel wird erst sauber, wenn beides stimmt: Source zone darf nicht nur grob LAN heissen, während Source networks and devices pauschal Any bleibt. Umgekehrt hilft ein korrektes Netzobjekt wenig, wenn der Traffic über eine andere Zone eintritt als erwartet.

Standard-Zonen verstehen

Sophos Firewall bringt mehrere Standard-Zonen mit:

• LAN: Interne Netze, Clients, Server und Management-Netze.
• WAN: Internet-Uplinks, Provider-Router, PPPoE, DHCP oder statische WAN-Adressen.
• DMZ: Öffentlich erreichbare Server, Reverse Proxies und isolierte Dienste.
• WiFi: WLAN-Netze, Sophos Access Points und drahtlose Segmente.
• VPN: Remote Access VPN, Site-to-Site VPN und andere Tunnel-Kontexte.

Die Standard-Zonen findet man unter Network > Zones. Eigene Zonen können als Typ LAN oder DMZ angelegt werden. Weitere WAN- oder VPN-Zonen lassen sich nicht einfach frei erstellen, weil diese Zonentypen besondere Funktionen in der Firewall haben.

Wichtig ist: Eine Zone ist keine automatische Erlaubnis. Auch zwischen zwei Interfaces in derselben Zone braucht es je nach Richtung und Szenario passende Firewall Regeln. Traffic zwischen zwei LAN-Zone-Interfaces ist nicht automatisch erlaubt, sondern braucht eine passende LAN-to-LAN-Regel.

Sophos Firewall unterstützt eigene Zonen, aber nicht unbegrenzt als Ersatz für saubere Regeln. Die offizielle Grenze liegt bei maximal 100 Zonen. In der Praxis sollte man diese Grenze nicht ausreizen. Wenn fast jedes VLAN eine eigene Zone bekommt, obwohl viele davon identische Regeln und denselben Device Access benötigen, wird das Regelwerk oft nicht sicherer, sondern schwerer wartbar.

Zonen vor dem Anlegen planen

Vor dem Anlegen sollte man nicht zuerst über Portnummern oder VLAN IDs nachdenken, sondern über Sicherheitsbereiche. Eine Zone sollte beantworten: Welche Netze haben dieselbe Vertrauensstufe und werden ähnlich geschützt?

Für Zonennamen empfehlen wir kurze englische Funktionsnamen. Das passt zur englischen Sophos-Oberfläche, bleibt auch bei späteren Standort- oder VLAN-Änderungen verständlich und wirkt im Regelwerk sauberer als gemischte Namen wie Büro-LAN, VLAN20 oder Netzwerk intern.

Ein praxistaugliches Namensschema ist:

Als Minimum empfehlen wir in produktiven Umgebungen diese Trennung:

• Client für normale Arbeitsplätze.
• Server für interne Dienste.
• Management für Admin-Zugriff, Switches, Access Points, Monitoring und Firewall-Verwaltung.
• Guest für Gäste, BYOD oder untrusted WLAN.
• DMZ für veröffentlichte oder stärker exponierte Systeme.
• WAN für Internet- und Provider-Anbindungen.
• VPN oder eigene VPN-Zonen für Remote Access und Standorttunnel.

Wenn eine Umgebung sehr klein ist, kann Server am Anfang fehlen. Management und Guest sollten trotzdem nicht im normalen Client-Netz untergehen. Genau diese beiden Bereiche sehen wir in der Praxis am häufigsten zu offen: Admin-Dienste sind aus zu vielen Netzen erreichbar, oder Gäste-/IoT-Geräte stehen näher an internen Systemen, als sie sollten.

Eigene Zonen sind besonders sinnvoll für:

• Management-Zugriffe: WebAdmin, SSH, Switches, APs, Hypervisor, Backup und Monitoring.
• Gäste und BYOD: Geräte, die nicht verwaltet werden und nur Internet benötigen.
• DMZ und veröffentlichte Systeme: Webserver, Reverse Proxies, WAF-Backends oder DNAT-Ziele.
• IoT, Kameras und Drucker: Geräte mit hohem Risiko, schwacher Update-Pflege oder unnötigem Ost-West-Traffic.
• Backup-Infrastruktur: Backup-Ziele sollten nicht aus jedem Netz erreichbar sein.
• OT, Produktion und Labor: Netze mit eigenen Betriebsrisiken oder längeren Wartungszyklen.
• VPN und RED-Standorte: Externe oder entfernte Netze sollten nicht automatisch dieselben Rechte wie lokale Clients bekommen.

Nicht jedes VLAN braucht automatisch eine eigene Zone. Wenn mehrere Client-VLANs exakt dieselben Firewall Regeln, dieselbe Web Policy und denselben Device Access bekommen, können sie in einer gemeinsamen Client-Zone bleiben. Wenn ein VLAN aber Server erreichen darf, ein anderes nur Internet, und ein drittes gar keinen Zugriff auf lokale Firewall-Dienste haben soll, sollte man die Trennung bewusst modellieren.

Ein gutes Muster ist:

• Andere Vertrauensstufe: eigene Zone prüfen.
• Eigene Management-Zugriffe auf die Firewall: eigene Zone oder eigene ACL-Regel prüfen.
• Anderes Logging oder andere Schutzfunktionen: eigene Zone kann sinnvoll sein.
• Nur andere IP-Range, aber gleiche Security Policy: gemeinsame Zone und saubere Netzobjekte reichen oft.

Zonenmodell in eine Zugriffsmatrix übersetzen

Nach der Zonenplanung sollte man kurz festlegen, welche Zone mit welcher anderen Zone sprechen darf. Diese Zugriffsmatrix ist oft hilfreicher als sofort im WebAdmin Regeln anzulegen, weil sie Widersprüche sichtbar macht.

Ein einfaches Beispiel:

• Client zu WAN: Erlaubt für Web, DNS, NTP und benötigte Anwendungen.
• Client zu Server: Nur definierte Applikationsports, nicht Any.
• Guest zu WAN: Erlaubt, meist mit Web Policy und Logging.
• Guest zu Server: Normalerweise blockiert.
• IoT zu Server: Nur zu genau definierten Diensten, zum Beispiel MQTT, DNS oder NTP.
• Management zu LAN, Server, DMZ: Administrativer Zugriff, eng und geloggt.
• DMZ zu LAN: Standardmässig blockiert, nur explizite Rückverbindungen erlauben.
• VPN zu Server: Nur benötigte interne Ziele und Dienste.

Die Matrix muss nicht gross sein. Wichtig ist, dass jede erlaubte Richtung einen Zweck hat. Wenn ein Eintrag nicht erklärt werden kann, sollte er nicht als breite Firewall Regel entstehen.

Für jede Zeile sollte man zusätzlich notieren:

• benötigte Dienste und Ports
• ob Benutzer- oder Gruppenmatching nötig ist
• ob NAT beteiligt ist
• ob Logging dauerhaft aktiv bleiben soll
• welche Security Features passen, zum Beispiel IPS, Web Policy oder Application Control
• wer den Zugriff fachlich verantwortet

Aus dieser Matrix entstehen danach die eigentlichen Firewall Regeln. Die Detailoptionen und typische Fehler bei Regelreihenfolge, Source, Destination, NAT und Logging sind in Sophos Firewall-Regeln verstehen und richtig konfigurieren beschrieben.

Planungscheck vor Änderungen

Bevor Zonen oder Interfaces angelegt, verschoben oder gelöscht werden, sollte man die Abhängigkeiten schriftlich klären. Viele spätere Störungen entstehen nicht durch die IP-Adresse selbst, sondern durch vergessene Firewall Regeln, NAT-Regeln, DHCP-Server, Device Access oder Routing-Entscheidungen.

Für jede neue Zone oder jedes neue Interface sollten mindestens diese Fragen beantwortet sein:

• Vertrauensstufe des Netzes: Davon hängen Zone, Firewall Regeln und Device Access ab.
• Benutzer und Systeme im Netz: Clients, Server, Gäste, IoT, VoIP und Management brauchen unterschiedliche Regeln.
• Default Gateway: Bei VLANs ist die Firewall oft Gateway, bei Migrationen manchmal nicht.
• DHCP-Quelle: Sophos Firewall, interner DHCP-Server oder DHCP Relay müssen bewusst geplant sein.
• DNS-Server: DNS beeinflusst Webfilter, Namensauflösung und Troubleshooting.
• Lokale Firewall-Dienste: Device Access für DNS, Ping, HTTPS, SSH oder Portale muss passen.
• Regeln und NAT-Pfade: Ohne passende Firewall- und NAT-Regeln ist das Interface nur technisch vorhanden.
• Testablauf: Ein Testclient, ein Testziel und ein erwarteter Logeintrag sparen viel Suchzeit.

Für produktive Änderungen sollte zusätzlich ein aktuelles Backup vorhanden sein. Wenn Interfaces schon verwendet werden, ist Object usage Pflicht, bevor man Namen, Zone Binding, IP-Adresse oder Interface-Typ ändert.

Neue Zone erstellen

Man öffnet Network > Zones und klickt auf Add.

1. Einen kurzen, eindeutigen Namen vergeben, zum Beispiel Server, Guest, Management oder MPLS.
2. Als Typ LAN oder DMZ wählen.
3. Unter Device Access bewusst festlegen, welche lokalen Dienste der Firewall aus dieser Zone erreichbar sein dürfen.
4. Speichern.

Nach dem Speichern sollte die Zone direkt in zwei Bereichen geprüft werden: unter Network > Zones für Name, Typ und Device Access sowie später in einer Test-Firewall-Regel als auswählbare Source zone oder Destination zone. Wenn die Zone zwar existiert, aber kein Interface darin liegt, wird noch kein produktiver Traffic darüber laufen.

LAN oder DMZ als Zonentyp?

Bei eigenen Zonen kann man auf der Sophos Firewall in der Regel zwischen LAN und DMZ wählen. Beide Typen gruppieren Interfaces, damit man sie später in Regeln, Device Access und Policies sauber verwenden kann. Der Unterschied liegt vor allem in der Sicherheitsidee hinter der Zone.

LAN verwendet man für interne, grundsätzlich vertrauenswürdige Netze. Dazu gehören zum Beispiel Client-Netze, interne Servernetze, Management-Netze, VoIP, Drucker oder interne VLANs. Auch bei einer LAN-Zone gilt: Traffic zwischen Interfaces ist nicht automatisch erlaubt. Wenn zwei LAN-Zonen oder zwei Interfaces innerhalb einer LAN-Zone miteinander sprechen sollen, braucht es passende Firewall Regeln.

DMZ verwendet man für Netze mit höherem Risiko oder klarer Isolation. Typische Beispiele sind öffentlich erreichbare Webserver, Reverse Proxies, Mail-Gateways, Jump Hosts oder Systeme, die aus mehreren Sicherheitsbereichen erreichbar sein müssen. Eine DMZ sollte so geplant werden, dass sie nur die notwendigen Verbindungen nach innen erhält. Wenn ein kompromittierter Server in der DMZ steht, darf daraus nicht automatisch ein breiter Zugriff ins interne LAN entstehen.

Als einfache Faustregel:

• LAN: interne Netze, denen man grundsätzlich vertraut und die vor allem ausgehend oder intern kommunizieren.
• DMZ: exponierte oder besonders zu isolierende Netze, bei denen Zugriffe nach innen streng begrenzt werden sollen.

HA-Interfaces gehören ebenfalls in eine DMZ-Zone. Für normale Admin- oder Client-Netze ist LAN meistens der passendere Typ.

Für ein internes Admin-Netz kann HTTPS sinnvoll sein. Für normale Client- oder Gäste-Netze sollte man Management-Zugriff vermeiden. Ping/ping6 ist für Troubleshooting oft hilfreich, sollte aber bewusst aktiviert werden. DNS wird nur benötigt, wenn Clients in dieser Zone die Firewall als DNS-Server verwenden.

⚠️ Device Access ist nicht dasselbe wie eine Firewall Regel. Zugriffe auf lokale Dienste der Firewall, zum Beispiel WebAdmin, SSH, User Portal, DNS oder Ping, werden über Administration > Device access und lokale ACL-Ausnahmen gesteuert.

Interface konfigurieren

Interfaces findet man unter Network > Interfaces. Ein physischer Port kann zum Beispiel als LAN, WAN oder DMZ betrieben werden. Virtuelle Interfaces wie VLAN, Bridge, LAG, RED oder XFRM werden zusätzlich angelegt.

Für ein physisches Interface sind diese Punkte besonders wichtig:

• Name: sprechender Name für spätere Regeln und Logs.
• Hardware: physischer Port, zum Beispiel Port1, Port2 oder PortA.
• Network zone: Sicherheitszone, in der das Interface liegt.
• IPv4 configuration: Static, DHCP oder PPPoE.
• IPv6 configuration: Static, DHCP oder Delegated, je nach Umgebung.
• Gateway: nur bei WAN-Interfaces relevant.
• MTU / MSS: wichtig bei PPPoE, VPN, SD-WAN und Fragmentierungsproblemen.

Nur Interfaces in der WAN Zone erhalten eine Gateway-Konfiguration. Interne Interfaces werden meistens statisch adressiert. Bei Provider-Anbindungen kann DHCP oder PPPoE sinnvoll sein.

Wenn der Provider IPv6 per Prefix Delegation bereitstellt, sollte man die Einschränkungen und den Ablauf separat planen. Der praktische Artikel dazu ist IPv6 Prefix Delegation auf Sophos Firewall konfigurieren.

Sprechende Namen sind wichtig. PortD sagt in sechs Monaten wenig aus. Server VLAN, MPLS Provider, Guest WiFi oder Core Switch Trunk helfen im Betrieb deutlich mehr.

Ein bestehendes physisches Interface bearbeitet man so:

1. Network > Interfaces öffnen.
2. Beim gewünschten Port das Menü öffnen und Edit interface wählen.
3. Name, Network zone, IP-Konfiguration, Gateway und MTU/MSS prüfen.
4. Bei WAN-Interfaces zusätzlich Gateway-Name und Gateway-IP kontrollieren.
5. Speichern und danach Link-Status, Gateway-Status und Log Viewer prüfen.

Vor Änderungen an einem produktiven Interface sollte Object usage geöffnet werden. Interface-Änderungen können Zone Binding, DNS, Gateways, SD-WAN Routes, Interface-basierte Hosts, VLAN-Interfaces, Dynamic DNS, Firewall Regeln und NAT betreffen. Beim Löschen eines virtuellen Interfaces entfernt Sophos zudem abhängige Konfigurationen wie Firewall-Regeln, DHCP- oder Routing-Bezüge. Genau dort entstehen die unangenehmen Ausfälle, wenn man nur den Portnamen im Kopf hatte.

Vor Firmware-Upgrades sollte man zusätzlich darauf achten, dass Interface-Namen, Hardware-Namen und Branch-Namen nicht mit einem langen Zahlenblock enden. In den SFOS-Release-Notes ist ein WebAdmin-Anzeigefehler dokumentiert, wenn solche Namen mit zehn oder mehr Ziffern abschliessen, zum Beispiel VLAN_1234567890. Für Upgrade-Planung und konkrete Prüfungen passt Sophos Firewall vor SFOS 22 Upgrade prüfen.

VLAN-Interface erstellen

Für einen fokussierten Ablauf mit Parent Interface, Switch-Tagging, DHCP, Device Access, Firewall-Regeln und Tests passt Sophos Firewall VLAN einrichten und testen. Der folgende Abschnitt ordnet VLANs im grösseren Interface- und Zonenmodell ein.

Ein VLAN-Interface erstellt man unter Network > Interfaces > Add interface > Add VLAN. Wichtig sind vor allem Parent Interface, Zone, VLAN ID und IP-Konfiguration.

Das Parent Interface ist der physische Port oder ein LAG, auf dem das VLAN getaggt ankommt. Wenn der Switch das VLAN auf einem anderen Port, untagged oder mit falscher VLAN ID sendet, sieht die Firewall zwar ein VLAN-Interface, aber die Clients erreichen es nicht zuverlässig.

Für interne VLANs verwendet man meistens eine statische IP-Adresse auf der Firewall, zum Beispiel als Default Gateway für dieses VLAN. Die Zone entscheidet später, welche Firewall Regeln, Web Policies und Device Access Einstellungen greifen. Genau deshalb sollte man beim Erstellen eines VLANs nicht nur die IP-Adresse eintragen, sondern direkt überlegen, ob das VLAN eher Client, Server, Management, Guest, DMZ oder eine andere Zone benötigt.

Ein konkretes Praxisbeispiel mit Switch-Portprofilen, Tagged/Untagged-Verhalten, DHCP und Testablauf steht in VLAN auf Sophos Firewall und UniFi Switch konfigurieren.

Auf XGS-Hardware gibt Sophos keine fixe harte Anzahl von VLAN-Interfaces pro physischem Interface an. Das bedeutet aber nicht, dass ein einzelner Parent-Port immer die beste Betriebsentscheidung ist. Für Performance, Fehlersuche und Wartbarkeit sollten VLANs sinnvoll über physische Ports oder LAGs verteilt werden, besonders wenn sehr viele VLANs, hohe Ost-West-Last oder HA-Designs im Spiel sind.

VLAN-Rollout sauber abnehmen

Ein VLAN gilt erst dann als fertig, wenn nicht nur das Interface angelegt ist, sondern auch Switch, DHCP, DNS, Firewall-Regel und Logging zusammenpassen. Gerade bei neuen Netzen wird sonst schnell an der falschen Stelle gesucht: Die Firewall-Regel sieht korrekt aus, aber der Switch sendet untagged. Oder der Client bekommt eine IP-Adresse, aber Device Access erlaubt keinen DNS-Zugriff auf die Firewall.

Für jedes neue VLAN sollten diese Punkte geprüft werden:

• Firewall Interface: VLAN ID, Parent Interface, Zone, IP-Adresse und Subnetzmaske passen zum Design.
• Switch-Port: Uplink zur Firewall ist als Trunk konfiguriert und trägt das VLAN tagged.
• Access-Port oder SSID: Client-Port oder WLAN-SSID ordnet Clients dem richtigen VLAN zu.
• Gateway: Die Firewall-IP im VLAN ist das erwartete Default Gateway oder das Routing ist anders dokumentiert.
• DHCP: DHCP-Server, DHCP Relay oder externer DHCP-Server verteilt richtige IP, Gateway, DNS und Lease.
• DNS: Clients können interne und externe Namen wie geplant auflösen.
• Device Access: Nur benötigte lokale Firewall-Dienste sind aus der Zone erlaubt, zum Beispiel DNS oder Ping.
• Firewall Regel: Source zone, Source network, Destination zone, Services und Logging passen zum Testflow.
• NAT: Nur aktiv, wenn Traffic wirklich übersetzt werden muss. Für normalen internen Traffic ist NAT meist falsch.
• Test: Log Viewer zeigt die erwartete Firewall Rule ID; bei Bedarf bestätigt Packet Capture den Paketfluss.

Als Abnahmetest reicht nicht, dass ein Client irgendeine IP-Adresse erhält. Ein sinnvoller Test besteht aus mehreren Schritten: Client per DHCP verbinden, Gateway anpingen, DNS prüfen, eine erlaubte interne Verbindung testen, einen verbotenen Zugriff bewusst blockiert sehen und danach den Internetzugriff prüfen. So erkennt man, ob VLAN, Zone, Device Access, Firewall-Regel und NAT wirklich zusammenpassen.

Wenn mehrere VLANs gleichzeitig erstellt werden, sollte man pro VLAN einen eigenen Testclient oder mindestens eine eindeutige Test-IP verwenden. Sonst werden Log Viewer und Packet Capture unnötig unübersichtlich. Für die eigentliche Paketflussprüfung passt Firewall-Regel testen mit Log Viewer, Policy Test und Packet Capture.

Interface-Status richtig lesen

Unter Network > Interfaces zeigt die Sophos Firewall Statusmeldungen an. Diese Statusmeldungen sind beim Troubleshooting sehr hilfreich, weil man schnell sieht, ob ein Interface nur falsch konfiguriert ist oder ob wirklich kein Link besteht.

• Not configured: Das Interface ist keiner Zone zugewiesen. Es ist also nicht sinnvoll nutzbar, bis eine Zone gebunden wurde.
• Connected: Das Interface ist konfiguriert und verbunden.
• Connecting: Eine neue IP-Adresse wird gerade bezogen, zum Beispiel per DHCP.
• Disconnected: Die IP-Adresse wurde freigegeben.
• Disconnecting: Die IP-Adresse wird gerade freigegeben.
• Unplugged: Es besteht keine physische Verbindung. Bei WiFi kann es auch bedeuten, dass kein Access Point verbunden oder kein Wireless Network zugewiesen ist.
• Not available: FleXi Ports wurden konfiguriert, aber das entsprechende FleXi Port Modul ist nicht mehr vorhanden.

Wenn ein Interface unerwartet Not configured oder Unplugged zeigt, sollte man nicht zuerst Firewall Regeln suchen. Zuerst prüft man Zone Binding, Link, SFP/Transceiver, Kabel, Switch-Port und bei DHCP/PPPoE die Adressvergabe.

VLAN, Bridge, LAG, Alias und RED einordnen

Sophos Firewall unterstützt verschiedene Interface-Typen. Für Beginner ist vor allem wichtig, wann welcher Typ sinnvoll ist.

• VLAN: Standard für segmentierte Netze auf einem Trunk-Port.
• Bridge: Transparente Verbindung mehrerer Ports, oft für einfache Setups oder Migrationen.
• LAG: Bündelung mehrerer physischer Links für Redundanz oder Bandbreite.
• Alias: zusätzliche IP-Adresse auf einem bestehenden Interface.
• RED: Remote Ethernet Device für Aussenstandorte.
• XFRM: Route-based IPsec VPN Interface.

Alias-Interfaces werden oft unterschätzt. Besonders nützlich sind sie, wenn ein Provider mehrere öffentliche IP-Adressen im gleichen Subnetz bereitstellt. Mehrere getrennte WAN-Interfaces im gleichen Subnetz führen auf Sophos Firewall zu ARP-Problemen und nicht erreichbaren Gateways. In solchen Designs ist meist ein Alias auf dem bestehenden WAN-Interface oder ein sauber geplantes LAG die bessere Wahl.

Für neue Installationen ist VLAN auf einem klar definierten Uplink zum Switch meistens sauberer als eine grosse Bridge über viele Ports. Eine Bridge kann bei Migrationen oder sehr einfachen Setups praktisch sein, weil mehrere Ports wie ein gemeinsames Layer-2-Segment behandelt werden. Genau das ist aber auch der Nachteil: Sicherheitsgrenzen, Broadcast-Domänen und Fehlerquellen werden weniger klar sichtbar.

Wir empfehlen Bridges deshalb nur gezielt und nicht als Standarddesign. In der Praxis haben Bridges mehrere Nachteile:

• Mehrere Ports teilen sich dasselbe Layer-2-Segment, wodurch Broadcasts und Störungen leichter mehrere Geräte betreffen.
• Firewall Regeln werden weniger übersichtlich, weil die Trennung nicht mehr sauber über eigene Interfaces, VLANs und Zonen sichtbar ist.
• Troubleshooting wird schwieriger, da Paketfluss, MAC-Learning, STP-Themen und Switch-Konfiguration zusammen betrachtet werden müssen.
• Spätere Segmentierung wird aufwendiger, wenn aus einer einfachen Bridge später doch getrennte Client-, Server-, Gäste- oder Management-Netze entstehen sollen.
• HA-, VLAN-, DHCP- oder Device-Access-Designs werden schnell unübersichtlich, wenn zu viele Funktionen über eine Bridge laufen.

Bridges können auf der Sophos Firewall über physische Interfaces, RED-Interfaces, VLANs oder LAGs erstellt und mit oder ohne eigene IP-Adresse betrieben werden. Genau hier entstehen oft Missverständnisse:

• Ohne IP-Adresse arbeitet die Bridge transparent, kann aber nicht wie ein normales routed Interface verwendet werden.
• Wenn Routing auf einer Bridge benötigt wird, muss der Bridge eine IP-Adresse zugewiesen werden.
• Für Traffic zwischen Bridge-Membern braucht es weiterhin passende Firewall Regeln zwischen den beteiligten Zonen, zum Beispiel LAN zu LAN.
• STP kann sinnvoll sein, wenn redundante Pfade vorhanden sind und Bridge-Loops verhindert werden sollen. Bei aktivierter HA lässt sich STP auf Bridge-Interfaces jedoch nicht aktivieren.
• VLAN-Filter und EtherType-Filter können helfen, den durch eine Bridge laufenden Layer-2-Traffic einzugrenzen. Wenn ein VLAN-Filter aktiviert ist, aber keine erlaubten VLANs eingetragen sind, verwirft die Firewall getaggten Traffic aller VLANs. Untagged Traffic ist davon nicht betroffen.
• Traffic über Bridge-Interfaces ohne IP-Adresse kann verworfen werden, wenn er eine Firewall Regel mit Web Proxy Filtering oder eine NAT Regel trifft. Solche Drops werden nicht geloggt. Bei NAT muss man dann besonders auf die Source Translation beziehungsweise Override Source Translation achten.

Dieser letzte Punkt ist wichtig: Wenn man über eine Bridge plötzlich keine Logs sieht, obwohl Traffic offenbar nicht funktioniert, liegt das Problem nicht immer am Log Viewer. Es kann an der Bridge-Betriebsart, NAT oder Web Proxy Filtering liegen.

Wenn bereits VLANs auf dem Switch existieren, sollte die Firewall diese VLANs bewusst als eigene VLAN-Interfaces übernehmen. Das ergibt klarere Zonen, sauberere Firewall Regeln und ist langfristig meist besser wartbar.

SFOS 22: Bridge, SNAT und Hairpin-Traffic prüfen

Bei SFOS 22 gibt es einen zusätzlichen Bridge-Sonderfall, der in Migrationen schnell übersehen wird. Routing über ein Bridge-Interface kann fehlschlagen, wenn SNAT oder MASQUERADE auf Traffic über die Bridge angewendet wird und Source und Destination über denselben physischen Bridge Member erreichbar sind. In diesem Hairpin-Szenario können Reply Packets auf der Bridge verworfen werden, ohne dass der Drop sauber in drppkt sichtbar wird.

Das ist kein normales Regel-Matching-Problem. Wenn der Log Viewer wenig zeigt, die Regel korrekt aussieht und trotzdem nur bestimmte Verbindungen über eine Bridge scheitern, sollte man NAT und Bridge-Topologie zusammen prüfen:

• Wird auf Bridge-Traffic wirklich SNAT oder MASQUERADE benötigt?
• Kommen Source und Destination über denselben physischen Bridge Member?
• Gibt es nur einen aktiv genutzten Bridge Member?
• Wäre ein geroutetes Design oder ein dediziertes physisches Interface sauberer?
• Lässt sich der Traffic ohne Source Translation testen?

Für VLAN-getaggten Traffic zur Firewall selbst gibt es zusätzlich einen eigenen SFOS-22-Fall. Der praktische Ablauf steht in Sophos Firewall Bridge-VLANs nach SFOS 22 prüfen.

RED Bridge: Netzwerk über Standorte strecken

Es ist technisch möglich, RED-Interfaces in eine Bridge aufzunehmen und damit ein Layer-2-Netz über mehrere Standorte zu strecken. Das kann bei Spezialfällen helfen, zum Beispiel wenn eine Applikation zwingend im gleichen Subnetz bleiben muss oder eine Migration ohne sofortige IP-Änderungen erfolgen soll.

Empfehlen würden wir dieses Design nur sehr zurückhaltend. Eine Bridge über RED verlängert die Layer-2-Domäne über den Tunnel. Dadurch laufen Broadcasts, ARP, unbekannte Unicast-Pakete und andere Layer-2-Effekte über eine WAN- oder Internetverbindung. Das kann die Performance verschlechtern und Fehler schwerer nachvollziehbar machen. Wenn der RED-Tunnel instabil ist, wirkt sich das zudem direkt auf das gestreckte Netz aus.

Besser ist in den meisten Fällen ein routed Design: Jeder Standort hat eigene Subnetze, die Firewall routet zwischen den Netzen und Firewall Regeln definieren gezielt, was erlaubt ist. Das ist sauberer, besser skalierbar und beim Troubleshooting deutlich angenehmer.

LAG: Redundanz und Bandbreite richtig planen

Eine Link Aggregation Group (LAG) fasst mehrere physische Ports zu einem logischen Interface zusammen. Das ist sinnvoll, wenn man Redundanz zum Core-Switch braucht oder mehr Bandbreite zwischen Firewall und Switch bereitstellen möchte. LAG ersetzt aber keine saubere Zonierung. Das LAG-Interface ist am Ende trotzdem nur ein Interface, auf dem man dann zum Beispiel VLANs betreibt oder eine Zone zuweist.

Sophos Firewall unterstützt vor allem zwei typische Betriebsarten:

• Active-Backup: Ein Link ist aktiv, ein anderer übernimmt bei Ausfall. Das ist einfach und gut für Redundanz.
• LACP (802.3ad): Mehrere Links können parallel genutzt werden. Das braucht LACP auf beiden Seiten, also auf Firewall und Switch.

Wichtig ist: LACP funktioniert nur sauber, wenn die Gegenseite korrekt konfiguriert ist. Auf dem Switch müssen die Ports in derselben LAG-Gruppe liegen, dieselbe Geschwindigkeit und denselben Duplex-Modus verwenden und zur Firewall-Konfiguration passen. Wenn man nur auf der Firewall eine LAG erstellt, aber den Switch nicht passend konfiguriert, entstehen oft schwer nachvollziehbare Paketverluste oder asymmetrische Verbindungsprobleme.

Für LAGs gelten einige praktische Grenzen:

• Eine LAG besteht auf der Sophos Firewall aus zwei bis vier physischen Interfaces.
• Als Mitglieder eignen sich nur ungebundene physische Interfaces mit statischer Konfiguration.
• PPPoE-, Cellular-WAN- und WLAN-Interfaces können nicht als LAG-Mitglieder verwendet werden.
• Bei LACP (802.3ad) müssen die Member-Ports denselben Typ und dieselbe Geschwindigkeit haben.
• Die xmit-hash-policy bestimmt, wie Sessions auf die Links verteilt werden. Eine einzelne TCP-Session wird dadurch normalerweise nicht plötzlich schneller, weil sie meist auf einem Link bleibt.

Für kleine Umgebungen ist ein einzelner sauberer Trunk-Port oft ausreichend. LAG lohnt sich vor allem dann, wenn der Core-Switch redundant angebunden werden soll, viele VLANs über denselben Uplink laufen oder die Firewall wirklich mehr Durchsatz zum Switch benötigt.

XFRM: Route-based IPsec als Interface verstehen

Ein XFRM-Interface gehört zum Thema route-based IPsec VPN. Es wird nicht wie ein normales VLAN oder ein physischer Port geplant, sondern entsteht im Kontext einer IPsec-Verbindung. Die Sophos Firewall erstellt ein XFRM-Interface automatisch, wenn bei einer IPsec-Verbindung sowohl die lokalen als auch die entfernten Subnetze auf Any gesetzt sind.

Das ist ein wichtiger Unterschied zu klassischen policy-based IPsec-Tunneln. Bei route-based VPN entscheidet nicht nur die IPsec Policy, sondern auch Routing, Firewall Regeln und das XFRM-Interface, wohin Traffic geht. Das macht komplexere Standortverbindungen flexibler, verlangt aber eine saubere Planung:

• Das XFRM-Interface liegt in der Zone VPN.
• Unter Administration > Device access muss für die WAN Zone IPsec erlaubt sein, damit die Verbindung aufgebaut werden kann.
• Wenn lokale oder entfernte Subnetze nicht Any sind, wird kein XFRM-Interface erstellt.
• MTU und MSS sind bei route-based VPN besonders wichtig, weil IPsec zusätzlichen Overhead erzeugt. Der praktische Prüfablauf steht in Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.
• Deaktiviert wird ein XFRM-Interface nicht direkt unter Network > Interfaces, sondern über die zugehörige IPsec-Verbindung unter Site-to-site VPN > IPsec.

Für Admins ist XFRM vor allem dann relevant, wenn SD-WAN-Routing, dynamisches Routing oder mehrere Netze über einen Standorttunnel sauber gesteuert werden sollen. Wenn man nur eine sehr einfache Site-to-Site-Verbindung mit zwei festen Netzen braucht, ist ein klassischer policy-based Tunnel oft leichter zu verstehen.

RED: Aussenstandorte als eigenes Interface-Konzept

RED-Interfaces sind kein normaler Switch-Port. RED steht für Remote Ethernet Device und wird verwendet, um einen Aussenstandort über einen verschlüsselten Tunnel mit der Sophos Firewall zu verbinden. Das kann mit dedizierter SD-RED-Hardware oder mit Firewall-zu-Firewall-RED-Verbindungen umgesetzt werden.

Für die eigentliche Inbetriebnahme mit Provisioning, Betriebsmodus, LED-Status und typischen Verbindungsproblemen passt die Anleitung Sophos SD-RED einrichten und Fehler beheben.

Vor der Planung sollte klar sein, welcher Betriebsmodus benötigt wird:

• Standard/Unified: Die Firewall verwaltet das entfernte Netz. Traffic läuft über die zentrale Firewall. Sehr gut kontrollierbar, aber abhängig vom Tunnel.
• Standard/Split: Nur definierte Zielnetze laufen durch den Tunnel, Internet-Traffic geht lokal am Standort raus. Weniger Bandbreite über die Zentrale, aber weniger zentrale Kontrolle.
• Transparent/Split: RED hängt transparent in einem bestehenden Netz. Gut für Spezialfälle, aber schwieriger zu verstehen und nicht für jedes Design geeignet.
• Manual/Split: Mehr manuelle Netzwerkkonfiguration. Der Standort kann lokal weiterarbeiten, wenn der Tunnel ausfällt.

Für viele Firmen ist Standard/Unified die sauberste Variante, wenn der Standort vollständig über die zentrale Firewall geschützt werden soll. Der Nachteil ist klar: Fällt der RED-Tunnel aus, verliert der Standort je nach Design auch den zentral gesteuerten Internetzugang. Standard/Split reduziert diese Abhängigkeit, bedeutet aber auch, dass lokaler Internet-Traffic nicht mehr vollständig über die zentrale Sophos Firewall gefiltert und geloggt wird.

Bei RED sollte man diese Punkte früh prüfen:

• Der RED-Service muss unter System services > RED aktiviert sein.
• Für die Verbindung werden typischerweise TCP 3400, UDP 3410 und NTP 123 benötigt.
• SD-RED-Geräte brauchen korrekte Zeit, weil sonst TLS-Handshake und Tunnelaufbau scheitern können.
• Bei Erstinbetriebnahme ist DHCP am Uplink meist einfacher, weil das Gerät die Provisionierung erreichen muss.
• VLANs sind nicht in jedem RED-Modus gleich sinnvoll. Standard/Split und Transparent/Split sind nicht für VLAN-Tagged Frames gedacht. Wenn VLANs hinter einer SD-RED benötigt werden, sollte man den Betriebsmodus besonders sorgfältig wählen.
• Wenn ein RED-Gerät hinter einem Provider-Router steht, müssen ausgehende Verbindungen und DNS/NTP funktionieren.

RED ist sehr praktisch für kleine Standorte, aber man sollte es nicht wie ein normales LAN-Kabel behandeln. Entscheidend ist, ob der Standort zentral geschützt, lokal autonom oder nur teilweise über den Tunnel angebunden werden soll. Diese Entscheidung beeinflusst DHCP, DNS, VLANs, Routing, Firewall Regeln, Logging und Troubleshooting.

Device Access sauber einschränken

Unter Administration > Device access sieht man, welche lokalen Dienste der Firewall aus welchen Zonen erreichbar sind. Dazu gehören unter anderem:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

Für produktive Umgebungen gilt: Je weniger lokale Dienste aus einer Zone erreichbar sind, desto besser. Besonders HTTPS und SSH sollten nur aus vertrauenswürdigen Management-Netzen oder über eine Local service ACL exception rule erlaubt werden.

Wenn SSH gebraucht wird, hilft diese Anleitung: SSH-Verbindung zur Sophos Firewall herstellen.

Bei eigenen Zonen kann Device Access auch direkt beim Erstellen oder Bearbeiten der Zone sichtbar sein. Technisch geht es trotzdem um lokale Dienste der Firewall, nicht um normalen Durchgangstraffic. Wenn Clients die Firewall als DNS-Server verwenden, muss DNS für diese Zone erlaubt sein. Wenn Admins WebAdmin erreichen sollen, sollte das nicht pauschal für die ganze Client-Zone passieren, sondern über ein Management-Netz oder eine Local-Service-ACL-Ausnahme.

Abhängigkeiten im Hinterkopf behalten

Änderungen an Interfaces sind selten isoliert. Zone Binding, DNS, Gateways, SD-WAN Routes, interface-basierte Hosts, VLAN-Interfaces, Dynamic DNS, Firewall Regeln und NAT Regeln können vom gleichen Interface abhängen. Vor grösseren Änderungen sollte man deshalb unter Object usage prüfen, wo ein Interface, eine Zone oder ein Host-Objekt bereits verwendet wird. Die Sophos Firewall zeigt die Nutzung von Objekten an und verlinkt direkt zu vielen abhängigen Konfigurationen.

Beim Deaktivieren oder Löschen muss man besonders vorsichtig sein:

• Wenn ein Interface deaktiviert wird, bleibt die Konfiguration erhalten und der Status ist weiterhin sichtbar.
• Site-to-site IPsec Tunnel, bei denen die Firewall der Initiator ist, werden sofort getrennt.
• Site-to-site IPsec Tunnel als Responder und Remote Access Verbindungen trennen sich spätestens durch Inaktivität oder Dead Peer Detection.
• Alias- und XFRM-Interfaces lassen sich nicht direkt wie normale Interfaces deaktivieren. Alias-Interfaces folgen dem physischen Interface, XFRM-Interfaces werden über Site-to-site VPN > IPsec deaktiviert.
• Wenn ein virtuelles Interface gelöscht wird, können abhängige Firewall Regeln, DHCP-Konfigurationen, ARP-Einträge, Routen, Interface-Hosts und weitere Referenzen mit entfernt werden.

Deshalb sollte man vor dem Löschen immer prüfen, ob das Interface in Firewall Regeln, NAT Regeln, DHCP, Routing, SD-WAN, Dynamic DNS oder Host-Objekten verwendet wird. Ein unbedachtes Löschen kann mehr entfernen als nur das Interface selbst.

Änderungen sicher umsetzen

Interface-Änderungen sollten schrittweise erfolgen. Besonders kritisch sind Remote-Standorte, HA-Cluster, WAN-Interfaces, VLAN-Trunks, XFRM-Interfaces und Management-Netze. Eine kleine Änderung am Zone Binding kann ausreichen, damit Firewall Regeln, Device Access oder SD-WAN Routes nicht mehr wie erwartet greifen.

Bewährter Ablauf:

1. Aktuelle Interface- und Zonenkonfiguration dokumentieren.
2. Abhängigkeiten über Object usage prüfen und die wichtigsten Treffer direkt notieren.
3. Backup erstellen.
4. Wartungsfenster oder Rückfallzeitpunkt definieren.
5. Neue Zone oder neues Interface zuerst ergänzen, nicht sofort alte Konfiguration löschen.
6. Testclient oder Testtraffic vorbereiten.
7. Nach der Änderung Link-Status, IP-Adresse, Gateway, DHCP und DNS prüfen.
8. Firewall-Regel, NAT-Regel und Device Access mit Log Viewer oder Packet Capture validieren.
9. Alte Regeln, Interfaces oder Objekte erst entfernen, wenn der neue Pfad stabil läuft.

Ein Backup ist dabei nur ein Teil des Rückwegs. Vor kritischen Interface- oder Zonenänderungen sollte zusätzlich dokumentiert sein, welche alte IP-Adresse, Zone, VLAN ID, Gateway, Route, SD-WAN Route, Firewall-Regel und NAT-Regel bei einem Abbruch wiederhergestellt werden muss. Für den eigentlichen Backup- und Restore-Prozess passt Sophos Firewall Backup erstellen oder wiederherstellen.

• Management-Zone oder Device Access wird angepasst: Alternativer Admin-Zugriff ist getestet, bevor die alte Erreichbarkeit entfernt wird.
• WAN-Interface oder Gateway wird geändert: Alter Providerpfad, PPPoE/DHCP/static Werte und SD-WAN Route sind dokumentiert.
• VLAN-Trunk wird umgebaut: Alte VLAN ID, Native VLAN, Switch-Portprofil und Firewall-Interface sind nachvollziehbar.
• Bridge, LAG oder RED wird geändert: Link-Status, beteiligte Ports und Standortzugriff können unabhängig geprüft werden.
• XFRM- oder VPN-Interface wird geändert: Tunnel, Routing und Firewall-Regeln werden vor dem Löschen des alten Pfads validiert.

Bei VLAN-Migrationen sollte man besonders auf Tagged/Untagged-Verhalten achten. Wenn Switch und Firewall unterschiedliche VLAN IDs, Native VLANs oder Trunk-Profile verwenden, sieht die Firewall entweder gar keinen Traffic oder Traffic landet in der falschen Zone.

Bei Remote-Standorten sollte immer ein Zugriffspfad ausserhalb des gerade geänderten Interfaces vorhanden sein. Das kann Sophos Central, ein zweiter WAN-Zugang, ein lokaler Admin vor Ort oder ein separates Management-Netz sein.

Typische Stolpersteine

Interface ist unbound oder disabled: Zuerst prüfen, ob eine Zone zugewiesen ist. Eine physische Schnittstelle kann nicht gelöscht werden, aber ihre Konfiguration kann entfernt werden, indem die Zone auf None gesetzt wird.

VLAN funktioniert nicht: VLAN ID, Switch-Port, Tagged/Untagged-Konfiguration, Native VLAN und Parent Interface prüfen.

Clients erreichen die Firewall nicht per Ping oder HTTPS: Nicht zuerst normale Firewall Regeln prüfen. Entscheidend sind Administration > Device access und lokale ACL-Ausnahmen.

Traffic zwischen zwei internen Netzen funktioniert nicht: Source zone, Destination zone, Netzobjekte, Routing und Position der Firewall Regel prüfen.

WAN-Gateway wird nicht aktiv: IP-Konfiguration, Gateway-IP, Link-Status, PPPoE-Zugangsdaten, DNS und gegebenenfalls WAN link manager prüfen.

Mehrere WAN-Interfaces im gleichen Subnetz: Wenn mehrere WAN-Interfaces IP-Adressen aus demselben Subnetz verwenden, kann es zu ARP-Problemen kommen und Gateways werden unter Umständen nicht erreichbar. Wenn ein Provider mehrere öffentliche IPs im gleichen Subnetz liefert, sind Alias- oder LAG-Interfaces meistens sauberer als mehrere getrennte WAN-Interfaces im selben Netz.

SFP, Port-Speed oder Breakout passt nicht: Die Port-Geschwindigkeit auf Switch, Router, Transceiver und Firewall muss zusammenpassen. Ein 25-Gbit/s-Port kann nicht ohne passende Technik direkt an einen 40-Gbit/s-Port angeschlossen werden. Bei Modellen mit 40G- oder 100G-Ports können Breakout-Kabel relevant sein, wenn ein Port in mehrere kleinere Ports aufgeteilt werden soll.

MTU-Probleme bei VPN oder PPPoE: MTU und MSS prüfen. Bei VPN-Traffic kann ein zu hoher MTU-Wert zu Paketverlusten führen, die im Alltag wie zufällige Verbindungsprobleme aussehen. Für die systematische Eingrenzung passt Sophos Firewall MTU und MSS bei VPN-Problemen prüfen.

Troubleshooting

Für die Fehlersuche ist diese Reihenfolge praktisch:

1. Network > Interfaces: Link-Status, IP-Adresse, Zone und Gateway prüfen.
2. Network > Zones: Device Access und Zonentyp prüfen.
3. Hosts and services: Prüfen, ob Host- und Service-Objekte korrekt sind.
4. Rules and policies > Firewall rules: Source zone, Destination zone, Services und Reihenfolge prüfen.
5. Rules and policies > NAT rules: Falls NAT im Spiel ist, Original und Translated sauber vergleichen.
6. Log viewer: Prüfen, welche Regel oder welcher Drop greift.
7. Diagnostics > Tools > Packet capture: Prüfen, ob Pakete überhaupt ankommen und wohin sie weitergeleitet werden.

Je nach Fehlerbild passt danach einer dieser nächsten Schritte:

• Regelaufbau verstehen: Wenn die Zone stimmt, aber noch unklar ist, wie Source, Destination, Service, Logging und Security Features zusammenhängen, hilft Sophos Firewall-Regeln verstehen und richtig konfigurieren.
• Regel matched nicht: Wenn Traffic trotz scheinbar korrekter Zone nicht durch die erwartete Regel läuft, passt Firewall-Regel greift nicht: Reihenfolge, Matching und Logs prüfen.
• Paketfluss prüfen: Wenn unklar ist, ob Pakete überhaupt ankommen oder wohin sie weitergeleitet werden, hilft Packet Capture im WebAdmin verwenden.
• NAT oder Portweiterleitung prüfen: Wenn DNAT, SNAT, MASQ, PAT oder Loopback beteiligt sind, ist NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT der bessere Einstieg.

Betriebscheckliste

• Zonenmodell dokumentiert: Client, Server, Management, Guest, DMZ, WAN und VPN bewusst getrennt oder bewusst zusammengefasst.
• Neue VLANs mit VLAN ID, Parent Interface, Switch-Portprofil und Gateway-IP dokumentiert.
• Zone und konkretes IP-Host-Objekt pro wichtigem Netz dokumentiert.
• Device Access pro Zone geprüft, besonders für HTTPS, SSH, DNS, Ping, User Portal und VPN Portal.
• Firewall Regeln mit Source zone, Destination zone, Services und Logging erstellt.
• Alias statt zusätzlichem WAN-Interface geprüft, wenn mehrere öffentliche IPs im gleichen Provider-Subnetz verwendet werden.
• NAT-Regeln geprüft, falls Internetzugriff, DNAT, SNAT oder VPN beteiligt ist.
• DHCP, DNS und NTP für neue Netze getestet.
• Object usage vor Änderungen an bestehenden Interfaces geprüft.
• Link-Status, Log Viewer und Packet Capture nach Änderungen kontrolliert.
• Management-Zugriff über einen unabhängigen Pfad sichergestellt.
• Backup vor grösseren Änderungen vorhanden.

FAQ