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.

Zusätzlich beschreibt Sophos Legacy CLI VLAN tagging inzwischen als deprecated. Solche Altlasten können Upgrades auf SFOS 22.0 MR2 und spätere Versionen verhindern. Der Check ist deshalb nicht nur Troubleshooting nach einem Upgrade, sondern auch eine sinnvolle Vorbereitung vor dem nächsten Wartungsfenster.

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.
• Ein Upgrade auf SFOS 22.0 MR2 oder später ist geplant oder wird wegen Legacy CLI VLAN tagging blockiert.
• 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.

Die Traffic-Arten unterscheiden sich deutlich:

• Durch die Bridge weitergeleiteter Traffic: Ein Client in VLAN 100 spricht mit einem Server in VLAN 100. Das kann weiterhin funktionieren, beweist aber nicht, dass Traffic zur Firewall funktioniert.
• Traffic zur Firewall: Ein 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: Die Firewall fragt AD, DNS, LDAP, RADIUS, NTP oder Syslog-Ziele ab. Auch das ist 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.

Praktische Einordnung:

• Nur eine einzelne Anwendung zwischen zwei Hosts funktioniert nicht: Wahrscheinlicher sind Firewall-Regel, NAT, Zielsystem oder Rückweg. Zuerst 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 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 prüfen. Tests direkt aus der Firewall-Konfiguration und passende Service-Logs verwenden.
• 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, Filter, lokaler Dienst oder nicht geloggter Bridge-/NAT-Sonderfall prüfen. 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.

Bridge-spezifische Stolperfallen vor der Korrektur

Sophos beschreibt drei Bridge-Einschränkungen, die man vor dem Umbau bewusst prüfen sollte.

Erstens: Eine Bridge ohne IP-Adresse kann Traffic verwerfen, wenn der Traffic eine Firewall-Regel mit Web-Proxy-Filterung oder eine NAT-Regel trifft. Diese Drops werden laut Sophos nicht geloggt. Wenn eine NAT-Regel trotzdem nötig ist, muss sie so scoped sein, dass Source Translation für das Bridge-Interface ohne IP auf Original bleibt. Sonst sucht man im Log Viewer nach einem Drop, der dort nicht auftaucht.

Zweitens: VLAN filtering auf der Bridge betrifft nur gebridgten Traffic, nicht gerouteten Traffic. Wenn Filter VLANs aktiviert ist, aber keine erlaubten VLAN IDs eingetragen sind, wird getaggter Traffic aller VLANs verworfen; ungetaggter Traffic bleibt davon ausgenommen. Das kann beim Testen wie ein inkonsistentes VLAN-Problem wirken.

Drittens: Bridge-Interfaces sind nicht für jedes Design ein Ersatz. Sophos nennt Einschränkungen bei Dynamic DNS, DHCP client, PPPoE und IPsec VPN. Wenn eine dieser Funktionen Teil des Zielbilds ist, sollte man den Bridge-Workaround nicht isoliert anwenden, sondern das Interface-Design neu bewerten.

Workaround und Upgrade-Vorbereitung

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

Neue oder bereinigte Designs sollten nicht mehr auf system vlan-tag aufbauen. Wenn solche CLI-Tags noch vorhanden sind, sollte man sie dokumentieren, in WebAdmin-VLAN-Interfaces überführen und erst danach das Firmware-Upgrade fortsetzen. Das reduziert sowohl den SFOS-22-Bridge-Sonderfall als auch spätere Upgrade-Blocker.

Beispiele:

• VLAN 100: br0.100
• VLAN 200: br0.200

Beim Anlegen in WebAdmin sind drei Felder entscheidend: Interface muss die Bridge sein, Zone muss zum Sicherheitszweck des VLANs passen und VLAN ID muss eindeutig sein. Sophos erlaubt für WebAdmin-VLANs IDs von 1 bis 4094; dieselbe VLAN ID sollte auf demselben Parent Interface nicht mehrfach eingeplant werden.

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:

1. Backup erstellen.
2. Aktuelle Bridge- und VLAN-Konfiguration dokumentieren.
3. Unter Network > Interfaces ein neues VLAN-Interface hinzufügen.
4. Als Parent Interface die Bridge auswählen, zum Beispiel br0.
5. VLAN ID eintragen.
6. Zone bewusst wählen.
7. IP-Adresse auf dem VLAN-Interface setzen, falls die Firewall in diesem VLAN Gateway oder lokaler Dienst sein soll.
8. Device Access für die Zone prüfen.
9. Firewall-Regeln und NAT-Regeln prüfen.
10. 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:

1. Default Gateway erreichen.
2. Firewall-IP auf dem neuen VLAN-Interface per Ping testen, wenn erlaubt.
3. DNS gegen die Firewall testen, falls die Firewall als DNS-Resolver dient.
4. WebAdmin oder Portal nur aus erlaubten Managementnetzen testen.
5. Eine typische Anwendung oder Serververbindung prüfen.
6. 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

Typische Stolperfallen:

• Nur Client-zu-Server-Traffic testen: Die 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: Das 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.
• Bridge-spezifische NAT-/Web-Proxy-Drops und VLAN filtering geprüft.
• Geplantes Upgrade auf SFOS 22.0 MR2 oder später gegen Legacy-CLI-VLAN-Tags geprüft.
• 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