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.

Warum Zonen wichtig sind

Zonen sind auf der Sophos Firewall mehr als nur eine optische Gruppierung. Sie definieren Sicherheitsbereiche und werden an mehreren Stellen verwendet:

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

Standard-Zonen verstehen

Sophos Firewall bringt mehrere Standard-Zonen mit:

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. Sophos weist in der Dokumentation ausdrücklich darauf hin, dass Traffic zwischen zwei LAN-Zone-Interfaces nicht automatisch erlaubt ist, sondern eine passende LAN-to-LAN-Regel benötigt.

Zonen vor dem Anlegen planen

Vor dem Anlegen sollte man notieren, welche Netze unterschiedliche Sicherheitsanforderungen haben. Typische Beispiele:

• Arbeitsplatz-LAN
• Servernetz
• Management-Netz
• DMZ
• Gäste-WLAN
• VoIP
• Kamera- oder IoT-Netz
• Produktionsnetz
• VPN-Clients
• MPLS- oder Standortverbindungen

Eine eigene Zone ist sinnvoll, wenn ein Netz eigene Regeln, eigenen Device Access oder eine andere Vertrauensstufe braucht. Mehrere VLANs können aber auch in derselben Zone liegen, wenn sie gleich behandelt werden sollen. Zu viele Zonen machen eine Konfiguration nicht automatisch sicherer. Sie helfen nur, wenn dahinter klare Regeln stehen.

Für viele kleinere und mittlere Umgebungen ist diese Grundstruktur ein guter Start:

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:

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.

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:

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:

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.

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.

VLAN-Interface erstellen

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.

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.

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.

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 werden. Sie können 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.
• VLAN-Filter und EtherType-Filter können helfen, den durch eine Bridge laufenden Layer-2-Traffic einzugrenzen.
• Sophos weist darauf hin, dass Traffic über Bridge-Interfaces ohne IP-Adresse verworfen werden kann, 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.

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:

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

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

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.

Abhängigkeiten im Hinterkopf behalten

Änderungen an Interfaces sind selten isoliert. Sophos weist darauf hin, dass Interface-Änderungen abhängige Konfigurationen betreffen können, zum Beispiel:

• Zone Binding
• DNS
• Gateways
• SD-WAN routes
• Interface-basierte Hosts
• VLAN-Interfaces
• Dynamic DNS
• Firewall Regeln
• NAT Regeln

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.

Typische Stolpersteine

Interface ist unbound oder disabled: Prüfe, 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: Prüfe VLAN ID, Switch-Port, Tagged/Untagged-Konfiguration, Native VLAN und ob das VLAN auf dem richtigen Parent-Interface angelegt wurde.

Clients erreichen die Firewall nicht per Ping oder HTTPS: Prüfe nicht zuerst normale Firewall Regeln. Prüfe Administration > Device access und lokale ACL-Ausnahmen.

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

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

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: Prüfe MTU und MSS. Bei VPN-Traffic kann ein zu hoher MTU-Wert zu Paketverlusten führen, die im Alltag wie zufällige Verbindungsprobleme aussehen.

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.

Wenn Zonen und Interfaces sauber angelegt sind, wird der nächste Schritt deutlich einfacher: Sophos Firewall-Regeln verstehen und richtig konfigurieren. Falls Traffic trotz scheinbar korrekter Zone nicht funktioniert, hilft die Checkliste Firewall-Regel greift nicht: Reihenfolge, Matching und Logs prüfen. Für tiefere Analyse kann man zusätzlich Packet Capture im WebAdmin verwenden und bei Übersetzungen oder Portweiterleitungen den Artikel NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT heranziehen.

Weitere Informationen

• Sophos Firewall - Add a zone
• Sophos Firewall - Interfaces
• Sophos Firewall - Bridge interfaces
• Sophos Firewall - Link aggregation groups
• Sophos Firewall - Add a link aggregation group
• Sophos Firewall - XFRM interfaces
• Sophos Firewall - RED interfaces
• Sophos Firewall - Add a RED interface