Sophos Firewall Bridge-VLANs nach SFOS 22 prüfen

Bridge-Interfaces auf Sophos Firewall sind praktisch, wenn ein bestehendes Layer-2-Netz transparent weitergeführt oder eine Migration ohne sofortige IP-Änderung umgesetzt werden soll. Mit VLANs auf einer Bridge wird das Design aber schnell fehleranfällig: Es gibt dann Forwarding zwischen Netzen, Traffic zur Firewall selbst, Device Access, DNS, AD, Authentifizierung und oft noch alte CLI-Konfigurationen.

Genau an dieser Stelle gibt es bei SFOS 22 einen wichtigen Betriebsfall. Sophos listet in der aktuellen Known-Issues-Liste ein Problem, bei dem Bridge-Interfaces mit CLI VLAN tag configurations in SFOS 22.0 GA und SFOS 22.0 MR1 VLAN-getaggten Traffic nicht korrekt verarbeiten, wenn dieser Traffic von der Sophos Firewall selbst ausgeht oder auf der Firewall endet. Das kann zum Beispiel Active Directory, DNS, Device Access, STAS, LDAP, RADIUS oder Managementzugriff betreffen, obwohl normaler Traffic durch die Bridge weitergeleitet wird.

Dieser Artikel ist kein allgemeines VLAN-Grundlagenkapitel. Für die Planung von Zonen, Interfaces, VLANs, Bridges und LAGs passt zuerst Sophos Firewall Zonen und Interfaces konfigurieren. Hier geht es gezielt um den Bridge-VLAN-Sonderfall nach SFOS 22.

Wann dieses Thema relevant ist

Der Check ist sinnvoll, wenn mehrere Punkte zusammenkommen:

Die Firewall läuft auf SFOS 22.0 GA oder SFOS 22.0 MR1.
Es gibt ein Bridge-Interface, zum Beispiel br0.
VLANs wurden historisch per CLI VLAN tag configuration wie system vlan-tag gebaut oder aus einer alten Konfiguration übernommen.
Dienste der Firewall selbst müssen ein getaggtes VLAN erreichen.
Nach einem Upgrade funktionieren AD, DNS, Authentifizierung, Monitoring oder Managementzugriff nur teilweise.
Normaler Client-Traffic durch die Bridge scheint weiterhin zu laufen.

Der letzte Punkt ist wichtig: Wenn die Bridge weiterhin Traffic zwischen Netzen weiterleitet, wirkt das Problem zuerst nicht wie ein Bridge-Fehler. In der Praxis sucht man dann schnell an der falschen Stelle, etwa bei Firewall-Regeln, DNS, STAS oder dem Domain Controller.

Betroffene Traffic-Richtung verstehen

Man muss drei Traffic-Arten sauber trennen.

Traffic-Art	Beispiel	Warum wichtig?
Durch die Bridge weitergeleiteter Traffic	Client in VLAN 100 spricht mit Server in VLAN 100	Kann weiterhin funktionieren. Das beweist nicht, dass Traffic zur Firewall funktioniert.
Traffic zur Firewall	Client nutzt die Firewall als DNS-Server oder WebAdmin-Ziel	Genau dieser Traffic kann betroffen sein, weil er auf der Firewall endet.
Traffic von der Firewall	Firewall fragt AD, DNS, LDAP, RADIUS, NTP oder Syslog-Ziel ab	Ebenfalls kritisch, weil die Firewall selbst der Absender ist.

Wenn nur eine Anwendung zwischen zwei Hosts getestet wird, erkennt man den Fehler deshalb nicht sicher. Der Test muss bewusst einen Dienst einbeziehen, der auf der Sophos Firewall endet oder von der Firewall erzeugt wird.

Typische Symptome

Mögliche Anzeichen sind:

Benutzerbasierte Regeln funktionieren nicht mehr zuverlässig, weil AD, STAS oder LDAP nicht stabil erreichbar sind.
DNS-Abfragen an die Firewall schlagen aus einzelnen VLANs fehl.
Ping oder HTTPS auf lokale Firewall-Dienste funktioniert aus einem VLAN nicht, obwohl die Firewall-Regeln plausibel aussehen.
Monitoring oder Syslog wirkt unvollständig, wenn die Firewall ein Ziel in einem getaggten VLAN erreichen muss.
Packet Capture zeigt, dass Traffic zwischen Endsystemen sichtbar ist, aber Dienste der Firewall selbst nicht wie erwartet antworten.
Nach einem SFOS-22-Upgrade treten die Symptome auf, ohne dass am Switch oder an den Firewall-Regeln bewusst etwas geändert wurde.

Solche Symptome sollten nicht sofort mit breiten Allow-Regeln oder Device-Access-Freigaben beantwortet werden. Zuerst muss klar sein, ob das Interface-Design selbst betroffen ist.

Schnellabgrenzung vor dem Umbau

Bevor man eine Bridge-IP verschiebt oder neue VLAN-Interfaces auf der Bridge erstellt, sollte man die Ursache eingrenzen. Nicht jedes Problem nach einem Upgrade ist automatisch der SFOS-22-Bridge-VLAN-Fall.

Beobachtung	Wahrscheinlicher Bereich	Nächster sinnvoller Check
Nur eine einzelne Anwendung zwischen zwei Hosts funktioniert nicht	Firewall-Regel, NAT, Zielsystem oder Rückweg	Firewall-Regel testen und bei Drops verworfene Pakete analysieren
WebAdmin, DNS oder Ping zur Firewall aus einem VLAN funktioniert nicht	Device Access, Zone, lokaler Dienst oder Bridge-VLAN-Sonderfall	Zone und Administration > Device access prüfen, danach Traffic zur Firewall separat testen
Firewall erreicht AD, LDAP, RADIUS, DNS oder Syslog im VLAN nicht	Traffic von der Firewall, Routing, DNS oder Bridge-VLAN-Sonderfall	Test direkt aus der Firewall-Konfiguration und passende Service-Logs prüfen
Normaler Client-Traffic läuft, aber Dienste der Firewall selbst nicht	Bridge-VLAN-Sonderfall wird wahrscheinlicher	Bridge-Design, alte CLI VLAN tag configuration und VLAN-Interface auf Bridge prüfen
Es gibt gar keine passenden Logeinträge	Logging, falscher Filter, lokaler Dienst oder nicht geloggter Bridge-/NAT-Sonderfall	Log Viewer, Packet Capture und relevante Sophos Firewall Service-Logs kombinieren

Für DNS-Probleme ist zusätzlich wichtig, ob Clients die Firewall als Resolver nutzen oder ob die Firewall selbst DNS Request Routes zu internen Servern verwendet. Der zweite Fall betrifft Traffic von der Firewall und kann bei Bridge-VLAN-Problemen anders aussehen als normaler Client-Traffic. Die Grundlagen stehen in DNS Request Routes auf Sophos Firewall einrichten.

Wenn die Schnellabgrenzung klar auf lokale Firewall-Dienste oder von der Firewall erzeugten Traffic zeigt, sollte der Umbau trotzdem geplant werden. Eine Bridge-Korrektur ohne Backup, Wartungsfenster und alternativen Zugriffspfad ist bei produktiven Netzen zu riskant.

Bestehendes Design aufnehmen

Vor Änderungen sollte man den Ist-Zustand dokumentieren. Besonders wichtig sind:

Name des Bridge-Interfaces, zum Beispiel br0.
Bridge Members, also beteiligte physische Interfaces, VLANs, RED-Interfaces oder LAGs.
IP-Adresse der Bridge, falls vorhanden.
VLAN IDs, die über die Bridge laufen.
Switch-Portprofil: Tagged VLANs, Native VLAN, Trunk oder Access Port.
Dienste, die auf der Firewall enden: DNS, Ping, HTTPS, SSH, User Portal, VPN Portal.
Dienste, die die Firewall erreichen muss: AD, LDAP, RADIUS, DNS, NTP, Syslog, Central, Monitoring.

Wenn der Aufbau aus einer alten Migration stammt, sollte man zusätzlich prüfen, ob VLANs per CLI-Konfiguration eingerichtet wurden. Genau diese Altlast ist oft nicht mehr im Kopf, wenn die Firewall über Jahre nur aktualisiert wurde.

⚠️ An Bridge-Interfaces und VLANs sollte man nicht spontan im Tagesbetrieb experimentieren. Eine falsche Änderung kann Managementzugriff, DNS, Authentifizierung oder ganze Client-Netze betreffen. Vor der Korrektur braucht es ein Backup, ein Wartungsfenster und einen alternativen Zugriffspfad.

Workaround: VLAN-Interfaces auf der Bridge erstellen

Ein praktischer Weg ist, VLAN-Interfaces in Network > Interfaces zu erstellen und dabei das Bridge-Interface als Parent Interface zu verwenden.

Beispiele:

VLAN	Neues Interface-Beispiel
VLAN 100	`br0.100`
VLAN 200	`br0.200`

Der Ablauf hängt davon ab, ob die Bridge selbst bereits eine IP-Adresse trägt.

Wenn die Bridge keine IP-Adresse braucht

Wenn die Bridge nur transparent weiterleiten soll, kann sie ohne eigene IP-Adresse betrieben werden. Die IP-Adresse für das betroffene VLAN liegt dann auf dem VLAN-Interface, zum Beispiel br0.100.

Praktischer Ablauf:

Backup erstellen.
Aktuelle Bridge- und VLAN-Konfiguration dokumentieren.
Unter Network > Interfaces ein neues VLAN-Interface hinzufügen.
Als Parent Interface die Bridge auswählen, zum Beispiel br0.
VLAN ID eintragen.
Zone bewusst wählen.
IP-Adresse auf dem VLAN-Interface setzen, falls die Firewall in diesem VLAN Gateway oder lokaler Dienst sein soll.
Device Access für die Zone prüfen.
Firewall-Regeln und NAT-Regeln prüfen.
Mit einem Testclient validieren.

Die Zone ist nicht nur Ordnung im WebAdmin. Diese Entscheidung beeinflusst Firewall-Regeln, Device Access, Logs und viele spätere Troubleshooting-Schritte. Wenn ein VLAN als Management-, Server- oder Client-Netz gedacht ist, sollte das in der Zone sichtbar werden.

Wenn die Bridge bisher die produktive IP-Adresse hatte

Wenn die Bridge aktuell die IP-Adresse nutzt, die künftig im VLAN erreichbar sein muss, sollte man besonders vorsichtig vorgehen. Für den Umbau gibt es zwei saubere Varianten: Die Bridge erhält eine andere IP-Adresse, oder die Bridge bleibt ohne IP-Adresse. Die bisherige produktive Adresse wird anschliessend dem VLAN-Interface zugewiesen.

Das ist ein Change mit Ausfallrisiko. Vorher sollte geklärt sein:

Über welche Adresse wird WebAdmin erreicht?
Welche Clients verwenden die Firewall als Default Gateway?
Welche DNS- oder DHCP-Einstellungen zeigen auf diese Adresse?
Welche Device-Access-Regeln hängen an der bisherigen Zone?
Gibt es einen zweiten Managementzugang aus einem nicht betroffenen Netz?

Bei Remote-Standorten sollte diese Änderung nicht ohne lokalen Rückweg geplant werden. Wenn WebAdmin und SSH über genau die betroffene Bridge-IP laufen, kann ein Fehler den administrativen Zugriff unterbrechen.

Device Access und Firewall-Regeln danach prüfen

Nach dem Anlegen des VLAN-Interfaces reicht es nicht, nur die IP-Adresse zu testen. Device Access und Firewall-Regeln müssen zum neuen Interface- und Zonendesign passen.

Zu prüfen:

Administration > Device access: Sind Ping/Ping6, DNS, HTTPS, SSH, User Portal oder VPN Portal nur in den richtigen Zonen erlaubt?
Rules and policies > Firewall rules: Gibt es Regeln für die neue Zone?
Rules and policies > NAT rules: Wird Traffic unerwartet übersetzt?
Network > DNS oder DNS Request Routes: Erreicht die Firewall die richtigen DNS- oder AD-Server?
Authentication > Servers: Sind AD, LDAP oder RADIUS nach der Umstellung erreichbar?

Für lokale Firewall-Dienste ist Device Access auf Sophos Firewall sicher konfigurieren der passende Vertiefungsartikel. Für die Regelanalyse hilft Sophos Firewall Regel testen mit Log Viewer und Packet Capture.

Validierung nach der Korrektur

Ein sauberer Test sollte mehr als einen Ping enthalten.

Test aus dem betroffenen VLAN

Von einem Client im betroffenen VLAN prüfen:

Default Gateway erreichen.
Firewall-IP auf dem neuen VLAN-Interface per Ping testen, wenn erlaubt.
DNS gegen die Firewall testen, falls die Firewall als DNS-Resolver dient.
WebAdmin oder Portal nur aus erlaubten Managementnetzen testen.
Eine typische Anwendung oder Serververbindung prüfen.
Log Viewer auf passende Rule ID und Zone kontrollieren.

Test von der Firewall aus

Für Traffic, den die Firewall selbst erzeugt, braucht es separate Tests:

AD- oder LDAP-Server in Authentication > Servers testen.
DNS-Auflösung über die Firewall prüfen.
NTP, Syslog oder Monitoring-Ziel prüfen, wenn diese Dienste im VLAN liegen.
Packet Capture auf dem VLAN-Interface verwenden, wenn unklar ist, ob Pakete die Firewall verlassen.

Wenn STAS oder benutzerbasierte Regeln betroffen sind, sollte zusätzlich STAS auf Sophos Firewall einrichten geprüft werden. Bei SFOS-22-Upgrades gehört dieser Punkt auch in den SFOS 22 Upgrade Check.

Häufige Fehler

Fehler	Wirkung	Besserer Ansatz
Nur Client-zu-Server-Traffic testen	Bridge wirkt gesund, obwohl lokale Firewall-Dienste betroffen sind	Auch Traffic zur und von der Firewall testen
Bridge-IP ohne Plan verschieben	WebAdmin, DNS oder Gateway kann ausfallen	Backup, Wartungsfenster und alternativen Zugriff vorbereiten
Zone beim neuen VLAN-Interface falsch wählen	Regeln, Device Access und Logs passen nicht	Zone nach Sicherheitszweck wählen, nicht nach Gewohnheit
Device Access zu breit öffnen	Problem scheint gelöst, aber Managementdienste sind unnötig erreichbar	Local Service ACL gezielt planen
Switch-Port nicht prüfen	VLAN kommt falsch oder ungetaggt an	Tagged/Untagged, Native VLAN und Trunk-Profil validieren
Alte CLI-Konfiguration ignorieren	Fehler bleibt nach dem Upgrade unerklärlich	Altdesign dokumentieren und auf WebAdmin-VLAN-Interfaces migrieren

Checkliste

SFOS-Version und Known-Issue-Relevanz geprüft.
Bridge-Interface, Bridge Members und VLAN IDs dokumentiert.
Geklärt, ob alte CLI VLAN tag configuration verwendet wurde.
Betroffene Dienste zur Firewall und von der Firewall identifiziert.
Backup und alternativer Managementzugang vorhanden.
VLAN-Interface mit Bridge als Parent Interface geplant.
Zone, Device Access, Firewall-Regeln und NAT-Regeln geprüft.
Tests aus dem VLAN und von der Firewall aus durchgeführt.
Ergebnis im Change-Log oder in der Netzwerkdokumentation festgehalten.

FAQ

Warum funktioniert normaler Traffic durch die Bridge, aber DNS zur Firewall nicht?

Bei diesem SFOS-22-Sonderfall kann durchgeleiteter VLAN-Traffic weiterhin funktionieren, während VLAN-getaggter Traffic, der auf der Firewall endet oder von der Firewall ausgeht, betroffen ist. Deshalb muss man lokale Firewall-Dienste separat testen.

Sollte man Bridge-VLANs auf Sophos Firewall generell vermeiden?

Nicht generell. Bridges können bei Migrationen oder transparenten Designs sinnvoll sein. Für neue segmentierte Netze sind eigene VLAN-Interfaces mit klaren Zonen aber meistens übersichtlicher und leichter zu betreiben.

Kann man das Problem mit einer Firewall-Regel lösen?

Nicht zuverlässig. Wenn das Interface-Design betroffen ist, ändert eine zusätzliche Allow-Regel nicht die Ursache. Zuerst sollte geprüft werden, ob das VLAN korrekt als Interface auf der Bridge angelegt werden muss.

Was sollte man vor einer Änderung an der Bridge-IP prüfen?

Man sollte klären, ob WebAdmin, DNS, DHCP, Default Gateway, Authentifizierung oder Monitoring diese Adresse verwenden. Zusätzlich braucht es ein aktuelles Backup und einen alternativen Zugriffspfad.