Sophos Firewall Bridge-Interface einrichten und testen

Ein Bridge-Interface verbindet zwei oder mehr Interfaces auf Layer 2. Damit lässt sich eine Sophos Firewall in einen bestehenden Netzwerkpfad einsetzen, ohne das Subnetz oder den Default Gateway der Clients zu ändern. Die Bridge kann transparent ohne IP-Adresse arbeiten oder mit einer eigenen IP-Adresse routen.

Das Beispiel in diesem Artikel setzt die Firewall zwischen einen bestehenden Router und den Core Switch. Port4 zeigt zum Router und gehört zur Zone WAN, Port3 zum internen Switch und zur Zone LAN. Die Bridge selbst erhält keine IP-Adresse. WebAdmin bleibt über einen separaten Managementport erreichbar.

⚠️ Beim Speichern übernimmt die Bridge ihre Member-Interfaces. Eine falsche Zone, ein fehlender Managementpfad oder ein redundanter Layer-2-Pfad kann den Zugriff unterbrechen oder eine Schleife auslösen. Vorher ein Backup erstellen, die Verkabelung dokumentieren und einen unabhängigen Adminzugang testen. Einen zweiten physischen Pfad erst anschliessen, wenn STP und ein mögliches HA-Design geklärt sind.

Welcher Bridge-Betrieb passt zum Ziel?

Transparente Bridge ohne IP-Adresse

Eine transparente Bridge leitet Ethernet-Frames zwischen ihren Membern weiter, tritt aber nicht als Gateway auf. IP-Adressen, Subnetz und Default Gateway der Endgeräte bleiben unverändert. Das eignet sich für eine kontrollierte Migration oder für eine zusätzliche Security-Schicht zwischen einem bestehenden Router und dem internen Netz. Je nach Regel und Lizenz kann SFOS dort DPI, IPS, Malware-Scanning und E-Mail-Prüfung anwenden, obwohl der vorhandene Router das Gateway bleibt.

Transparent bedeutet nicht ungefiltert. Die Zonen der Member bestimmen, welche Firewallregel greifen kann. Für den Beispielpfad von Port3 in der Zone LAN zu Port4 in der Zone WAN braucht es eine passende LAN-to-WAN-Regel. Liegen beide Member in LAN, ist stattdessen eine LAN-to-LAN-Regel nötig.

Wie man Vertrauensbereiche auswählt, eigene Zonen anlegt und Interfaces zuordnet, erklärt Zonen und Interfaces auf Sophos Firewall planen. Die Bridge-spezifischen Entscheidungen stehen vollständig in diesem Artikel; der Grundlagenartikel hilft bei einem neuen oder uneinheitlichen Zonenmodell.

Ohne Bridge-IP sollte die Administration über ein anderes Interface erfolgen. Im Beispiel verwendet Port2 ein separates Managementnetz. So bleibt WebAdmin erreichbar, auch wenn die Bridge, ihre Regeln oder die Verkabelung noch nicht stimmen.

Geroutete Bridge mit IP-Adresse

Mit Enable routing on this bridge pair erhält die Bridge eine IP-Adresse und kann als Gateway oder lokaler Firewall-Endpunkt arbeiten. Das ändert die Aufgabe grundlegend: Neben dem Layer-2-Forwarding entstehen gerouteter Traffic, lokale Dienste und gegebenenfalls Gateway-Abhängigkeiten.

VLAN-Filtering auf der Bridge gilt weiterhin nur für gebridgte Frames. Es filtert keinen Traffic, den die Bridge routet. Wer die Bridge als Gateway verwendet, muss deshalb Routing, Device Access, Firewallregeln und NAT zusätzlich prüfen.

Die SFOS-22-Hilfe ist bei DHCP nicht eindeutig. Sie führt für die IP-Zuweisung einer gerouteten Bridge Static und DHCP auf, nennt DHCP clients im selben Dokument aber als nicht unterstützte Bridge-Funktion. Für ein planbares produktives Design wird daher eine statische Adresse verwendet. DHCP auf einer Bridge sollte nur nach Prüfung der konkreten SFOS-Version und einer Bestätigung durch Sophos eingesetzt werden.

Bridge-Modus im Einrichtungsassistenten

Der Bridge Mode im ersten Einrichtungsassistenten und ein später unter Network > Interfaces erstelltes Bridge-Interface verwenden dasselbe Layer-2-Prinzip, sind aber nicht derselbe Arbeitsablauf.

Bei einer neuen Appliance startet Port A standardmässig mit 172.16.16.16/24, Port B bezieht seine Adresse per DHCP. Für die Ersteinrichtung wird ein Computer beispielsweise auf 172.16.16.2/24 gesetzt und mit Port A verbunden. WebAdmin ist dann unter https://172.16.16.16:4444 erreichbar. Im Assistenten wird Internet gateway (Bridge Mode) gewählt. Nach Registrierung, Schutz- und Benachrichtigungseinstellungen wendet SFOS die Konfiguration an und startet neu.

Dieser Modus ist für eine komplette Erstbereitstellung gedacht. Eine vorhandene Firewall wird für ein einzelnes neues Bridge-Paar nicht erneut durch den Assistenten geschickt. Wird der Assistent nach einer bereits eingerichteten HA-Konfiguration ausgeführt, schaltet er HA aus.

Bridge Mode unterstützt HA. Gleichzeitig lässt sich die STP-Funktion von SFOS auf keinem Bridge-Interface aktivieren, solange HA eingeschaltet ist. Das Weiterleiten von STP-, RSTP- und Multicast-Routing-Paketen ist davon zu unterscheiden. Eine transparente Bridge kann solche Frames passieren lassen, ohne selbst mit der SFOS-Option Turn on Spanning Tree Protocol (STP) an der Schleifenvermeidung teilzunehmen.

Beispiel vor der Konfiguration planen

Topologie und Beispielwerte

Der bestehende Router bleibt Default Gateway für das Netz 10.20.0.0/24. Die Firewall wird transparent in dessen LAN-Pfad gesetzt:

Internet
   |
Bestehender Router: 10.20.0.1
   |
Port4, Zone WAN
[ Bridge_Inline / brinline / keine IP-Adresse ]
Port3, Zone LAN
   |
Core Switch und Clients: 10.20.0.0/24

Separater Managementpfad:
Port2, Zone LAN, 10.99.0.1/24

Ein Client mit 10.20.0.50/24 verwendet nach dem Einbau weiterhin 10.20.0.1 als Gateway. Die Bridge erhält weder eine Adresse aus 10.20.0.0/24 noch eine Default Route. Angepasst werden müssen Portnummern, Zonen, Managementnetz und Regeln. Das Beispielnetz darf nicht blind in eine produktive Umgebung übernommen werden.

Vor dem Umbau hält man zwei Zustände fest: Welche Verbindungen funktionieren vor dem Einbau, und über welchen Pfad lässt sich die Firewall administrieren, wenn der produktive Datenpfad ausfällt? Dazu gehören mindestens DNS, Gateway, eine typische Anwendung, der erwartete Durchsatz und der Zugriff auf WebAdmin.

Member, Zonen und Abhängigkeiten prüfen

Eine Bridge kann bis zu 64 Member enthalten. Als Member kommen infrage:

• physische Interfaces;
• RED-Interfaces;
• LAGs;
• VLAN-Interfaces auf einem physischen Interface, RED oder LAG.

Mehr Member sind kein Qualitätsmerkmal. Jede zusätzliche Verbindung vergrössert die Layer-2-Domäne, die MAC-Tabelle und die Zahl möglicher Schleifen. Für einen Inline-Pfad genügen normalerweise zwei Member.

Vor dem Hinzufügen prüft man jedes Interface auf bestehende IP-Adressen, VLANs, DHCP, Gateways, NAT, Firewallregeln, Routing, Device Access und Object Usage. Die bisherige Funktion eines Ports verschwindet nicht automatisch aus allen abhängigen Objekten, nur weil der Port Teil einer Bridge wird.

Bridge-Interfaces unterstützen laut Sophos kein Dynamic DNS, PPPoE oder IPsec VPN. Auch die DHCP-Angaben sind, wie oben beschrieben, widersprüchlich. Eine Bridge ist deshalb kein universeller Ersatz für ein WAN- oder VPN-Interface. Für neue, klar segmentierte Netze sind VLANs und Routing oft leichter zu betreiben.

LAN Bypass ist eine getrennte Hardwarefunktion und nicht die normale Wirkung einer beliebigen Bridge. Welche Modelle und Portpaare diese Funktion unterstützen und wie sich der Fehlerfall verhält, erklärt LAN Bypass einrichten und kontrolliert testen.

Bridge im WebAdmin anlegen

Name, Hardware-Name und Member

1. Network > Interfaces > Add interface > Add bridge öffnen.
2. Als Name beispielsweise Bridge_Inline eintragen. Der Anzeigename darf bis zu 58 Zeichen lang sein und lässt sich später ändern.
3. Als Hardware name beispielsweise brinline eintragen. Der Wert darf höchstens 10 Zeichen enthalten und nur aus Buchstaben, Zahlen und _ bestehen. Nach dem Speichern lässt er sich nicht mehr ändern.
4. Enable routing on this bridge pair für das transparente Beispiel deaktiviert lassen.
5. Port3 mit Zone LAN und Port4 mit Zone WAN als Member interfaces hinzufügen.
6. VLAN-, ARP-, STP-, MAC-, MTU-, MSS- und EtherType-Einstellungen prüfen.
7. Save erst wählen, wenn der separate Managementzugang funktioniert und die beiden Kabel eindeutig beschriftet sind.

SFOS sperrt reservierte Hardware-Namen. Die vollständige Liste aus der SFOS-22-Hilfe lautet:

all, gre, oct, mv-pcimux0, mvmgmt0, pport_, lo, ipsec0, tun, ppp,
imq, ifb, mast, sit, WWAN1, _ppp, vxlan, xfrm, USB, erspan0, Port,
MGMT, eth, GE, gretap0, ip6tnl0, host, reds, wlnet, WLAN, Sophos,
GuestAP, spq, Halink

Bei einer gerouteten Bridge werden zusätzlich IPv4 oder IPv6 eingetragen. Enthält die Bridge WAN-Member, erscheinen auch Gateway-Felder. Diese Werte müssen zum echten Routingdesign passen. Für die transparente Beispiel-Bridge bleiben sie leer.

VLAN- und EtherType-Filter

Filter VLANs beschränkt getaggten Traffic auf die unter Permitted VLAN ID or ID range eingetragenen IDs. Einzelwerte und Bereiche wie 20-35 sind möglich. Ist der Filter aktiv, aber die Liste leer, verwirft SFOS sämtlichen getaggten VLAN-Traffic. Untagged Traffic läuft weiter. Genau diese Mischung kann bei der Fehlersuche täuschen.

Der VLAN-Filter gilt nur für Frames, welche die Bridge weiterleitet. Er ersetzt weder Firewallregeln noch die Kontrolle gerouteten Traffics. Historische CLI-VLAN-Tags benötigen unter SFOS 22 eine eigene Prüfung. Der Ablauf unter Bridge-VLANs nach SFOS 22 prüfen behandelt diesen Sonderfall mit den zugehörigen Versionsangaben.

Mit Filter Ethernet frames lassen sich EtherTypes einschränken. Ohne Filter erlaubt die Bridge alle Ethernet-Frames. Ist der Filter aktiv und enthält keine freigegebenen Typen, bleiben nur ARP, IPv4, IPv6, 8021Q und EXTE erlaubt. Weitere Protokolle werden als vierstellige Hex-ID eingetragen, beispielsweise 809B für AppleTalk, 8138 für Novell sowie 8863 und 8864 für PPPoE.

Einen EtherType gibt man nicht vorsorglich frei. Zuerst muss im Packet Capture sichtbar sein, welches Protokoll tatsächlich fehlt. Sonst entsteht eine schwer nachvollziehbare Ausnahmeliste, die später niemand mehr sicher zuordnen kann.

ARP, STP und MAC Aging

Permit ARP broadcast ist standardmässig aktiv. Die Bridge benötigt ARP, um IP- und MAC-Zuordnungen zu lernen und ihre Forwarding-Tabelle aufzubauen. Das Abschalten ist kein allgemeiner Broadcast-Schutz. Es passt nur zu einem belegten ARP-Storm und verlangt statische Bindings unter Network > Neighbors (ARP–NDP).

Turn on Spanning Tree Protocol (STP) schützt vor Schleifen, wenn mehr als ein Layer-2-Pfad zwischen denselben Bereichen existiert. STP kann einen redundanten Pfad sperren und bei Ausfall des aktiven Pfads umschalten. Die Option ist auf Bridge-Interfaces nicht verfügbar, solange HA aktiv ist. Ein HA-Cluster mit redundanter Verkabelung braucht deshalb ein Design, bei dem Switches, Portpfade und Schleifenvermeidung zusammen geplant sind.

STP max age steht standardmässig auf 20 Sekunden. SFOS verwendet BPDUs, um Topologieinformationen zwischen Bridges auszutauschen. Der Wert wird nicht isoliert auf der Firewall optimiert, sondern muss zur gesamten STP-Domäne passen.

MAC aging entfernt inaktive MAC-Adressen standardmässig nach 300 Sekunden. Ein niedrigerer Wert kann in einem sehr dynamischen Gäste- oder Testnetz schneller auf wechselnde Geräte reagieren. In einem stabilen Rechenzentrumsnetz vermeidet ein höherer Wert unnötiges Neulernen. Man ändert den Wert nur, wenn MAC-Flapping, häufige Standortwechsel oder eine konkrete Betriebsanforderung dies begründen.

MTU und MSS

Weichen MTU der Bridge und ihrer Member voneinander ab, übernimmt die Bridge den kleineren Wert. Eine Bridge mit MTU 9000 bleibt effektiv bei 1500, wenn ein Member nur 1500 unterstützt. Der geerbte Wert ist in der Interface-Tabelle sichtbar.

Override MSS betrifft TCP. Der Wert begrenzt die Nutzdaten pro TCP-Segment, damit zusätzliche Header oder Tunnelkapselung die wirksame MTU nicht überschreiten. Das hilft bei einem nachgewiesenen MTU- oder Fragmentierungsproblem, repariert aber kein falsches VLAN, keine fehlende Regel und keinen defekten Rückweg. UDP-Traffic wird durch MSS-Clamping nicht kleiner. Der ausführliche Diagnoseweg steht unter MTU und MSS bei VPN-Problemen prüfen.

Firewallregeln, NAT und Web Proxy

Die Bridge umgeht die Stateful Firewall nicht. Im Beispiel benötigt der Client-Traffic eine Regel von LAN nach WAN. Als Source Network wird 10.20.0.0/24 oder ein engeres Objekt verwendet, als Destination und Service nur der tatsächlich benötigte Umfang. Logging bleibt während der Abnahme aktiv.

Wer Regelreihenfolge, Zonen-Matching oder Schutzfunktionen noch festlegen muss, findet den vollständigen Grundlagenablauf unter Firewallregeln auf Sophos Firewall konfigurieren. Für die Bridge bleibt massgebend, über welche Member-Zonen der konkrete Frame ein- und austritt.

Antwortpakete einer erlaubten, von innen aufgebauten Verbindung laufen über den bestehenden Zustand zurück. Eine breite WAN-to-LAN-Regel ist dafür nicht nötig. Neue eingehende Verbindungen benötigen dagegen eine eigene, bewusst begrenzte Regel.

Bei einer Bridge ohne IP-Adresse gibt es eine ungewöhnliche Fehlerklasse. Trifft der Traffic eine Firewallregel mit Web Proxy Filtering oder eine NAT-Regel, kann SFOS die Pakete ohne Eintrag im Log Viewer verwerfen. Ein leeres Log beweist in diesem Fall nicht, dass keine Regel beteiligt ist.

Ist die NAT-Regel erforderlich, wird in genau dieser Regel Override source translation for specific outbound interfaces aktiviert. Outbound interface wird auf die Bridge gesetzt und Translated source (SNAT) auf Original. Damit bleibt die Quelladresse für diesen Ausgang erhalten. Eine globale NAT-Änderung wäre ein schlechter Test, weil sie andere Datenpfade beeinflusst und den eigentlichen Fehler verdeckt.

Web Proxy Filtering wird auf einer transparenten Bridge ohne IP nur eingesetzt, wenn das Design und die verwendete SFOS-Version dies ausdrücklich vorsehen. Für gewöhnliche Inline-Inspection sind DPI-basierte Regeln der besser nachvollziehbare Ausgangspunkt.

Datenpfad abnehmen und Fehler eingrenzen

Abnahme nach dem Speichern

Nach dem Speichern werden Konfiguration, Nutztraffic und Fehlerfall getrennt geprüft:

1. Unter Network > Interfaces Bridge-Name, Hardware-Name, Member, Zonen, IP-Modus, geerbte MTU und Linkstatus mit dem Plan vergleichen.
2. Vom Testclient einen benötigten Dienst aufbauen und im Log Viewer die erwartete Firewall Rule ID bestätigen.
3. Eingang und Ausgang im Packet Capture vergleichen. Source und Destination MAC, VLAN-Tag, EtherType und Interface müssen zur Topologie passen.
4. Einen erlaubten Dienst in beide Richtungen testen. Danach einen bewusst nicht erlaubten Dienst starten und den erwarteten Drop prüfen.
5. DNS, Default Gateway und eine typische Fachanwendung testen. Ein einzelner Ping reicht nicht.
6. Managementzugang über den unabhängigen Port erneut prüfen.
7. Bei STP einen redundanten Pfad nur im Wartungsfenster zuschalten und Umschaltzeit sowie Paketverlust messen.
8. Bei HA nach einem kontrollierten Rollenwechsel Bridge, Member, MAC-Lernen und Anwendungen erneut testen.

Kein Traffic und kein Logeintrag

Wenn weder Allow noch Drop im Log Viewer erscheint, werden zuerst die Bridge-Sonderfälle geprüft:

• Hat die Bridge keine IP-Adresse?
• Trifft der Flow eine NAT-Regel?
• Verwendet die Firewallregel Web Proxy Filtering?
• Ist der SNAT-Override für diese Bridge auf Original gesetzt?
• Sieht das Packet Capture den Frame am Eingangs-, aber nicht am Ausgangsmember?

Erst danach lohnt sich die Suche nach einer gewöhnlichen Regelreihenfolge oder einem Rückwegproblem. Das verhindert, dass man eine nicht geloggte Bridge-Verwerfung mit immer breiteren Allow-Regeln beantwortet.

VLAN oder EtherType wird verworfen

Unter System services > Log settings > Firewall wird die Komponente Bridge ACLs aktiviert. Im Log Viewer kann danach nach Log component > Bridge ACLs und zusätzlich nach den Subtypen ARP broadcasts, EtherType filtering oder VLAN filtering gefiltert werden.

Bei VLAN-Problemen werden Tagged/Untagged-Zustand, erlaubte VLAN-Liste und Switch-Portprofil gemeinsam geprüft. Bei EtherType-Problemen zeigt das Packet Capture, welche vierstellige ID tatsächlich auftritt. Filter und Gegenstelle müssen denselben Datenpfad beschreiben.

Traffic funktioniert nur in eine Richtung

Ein einseitiger Flow passt meist zu einer falschen Zone, einer fehlenden Regel, asymmetrischem Routing oder einem nicht gelernten MAC-Eintrag. Im Packet Capture werden Hin- und Rückweg auf beiden Membern verglichen. Anschliessend werden Rule ID, Source NAT, Gateway und MAC-Tabelle geprüft.

Schleife oder flappende MAC-Adressen

Viele Broadcasts, wechselnde MAC-Zuordnungen und instabile Links sprechen für eine Schleife oder falsch verkabelte Redundanz. Der zweite Pfad wird getrennt, bevor weitere Filter geändert werden. Danach werden Switch-STP, SFOS-STP, HA-Verkabelung und die tatsächlichen Bridge-Member als ein gemeinsamer Aufbau geprüft.

Ein HA-Design darf nicht davon ausgehen, dass die Firewall gleichzeitig ihre eigene STP-Option aktiviert. Wenn die Switches die Schleifenvermeidung übernehmen, muss der Failover-Test zeigen, dass weder eine Schleife noch ein dauerhaft gesperrter produktiver Pfad entsteht.

Für die detaillierte Zuordnung von Interface, Rule ID, Status und Reason kann der Ablauf unter Packet Capture auf Sophos Firewall ergänzend verwendet werden. Die Bridge-Abnahme oben bleibt trotzdem vollständig auf dieser Seite beschrieben.

Erweiterte Kontrollen in der Device Console

Die normale Konfiguration gehört in den WebAdmin. system bridge stellt drei zusätzliche Kontrollen bereit. Diese Befehle ersetzen keine fehlende Firewallregel und kein ungeklärtes Layer-2-Design. Vor Änderungen werden Bridge-Name, Hardware-Name, Member, Port-IDs, MAC-Tabelle, Managementpfad und aktueller CLI-Status festgehalten.

Unbekannten nicht routbaren Traffic behandeln

bypass-firewall-policy betrifft nicht routbaren Bridge-Traffic, auf den keine Security Policy angewendet wird. SFOS unterscheidet dynamic und static. Den aktuellen Zustand zeigen:

system bridge bypass-firewall-policy unknown-network-traffic show dynamic
system bridge bypass-firewall-policy unknown-network-traffic show static

Die möglichen Aktionen sind allow und drop. allow leitet den betroffenen Traffic ausdrücklich ohne Firewall-Policy weiter. Die SFOS-22-Hilfe nennt weder einen Standardwert noch die genaue Abgrenzung von dynamic und static. Eine Änderung gehört deshalb in einen konkreten, von Sophos Support begleiteten Fall. Danach werden CLI-Status, Packet Capture sowie je ein erlaubter und blockierter Testfluss geprüft.

Dieser Schalter ist weder LAN Bypass noch eine stateful Firewall Bypass Rule. Er aktiviert keinen Fail-to-Wire-Pfad und nimmt keine bekannte Verbindung aus der Stateful Inspection.

Statische MAC-Einträge gezielt setzen

Die Bridge Forwarding Table lernt MAC-Adressen normalerweise dynamisch. static-entry bindet eine MAC-Adresse fest an Bridge, Interface und Port. Die offizielle Befehlsschablone lautet:

system bridge static-entry [add | delete | show] [interface] {interface ID} [bridge name] [Port] {PortID} [macaddr] {MAC Address} [priority] [dynamic | static]

Die Klammern beschreiben die Syntax und werden nicht mitkopiert. Vor add werden die realen IDs mit show und der WebAdmin-Zuordnung geprüft. Ein falscher oder veralteter Eintrag kann Frames auf den falschen Port lenken. Für den Rückbau wird genau der dokumentierte Eintrag mit delete entfernt. Danach werden MAC-Lernen, Hin- und Rückweg sowie Managementzugang erneut getestet.

Member-Limit nicht als Skalierungsziel verwenden

Den aktuellen internen Grenzwert zeigt:

system bridge max_bridge_members show

Die Device Console akzeptiert für max_bridge_members Werte von 2 bis 256 und stellt reset bereit:

system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset

Die beiden offiziellen Grenzen passen nicht ohne Erklärung zusammen. Die WebAdmin-Hilfe nennt maximal 64 Member, während die Device-Console-Hilfe Werte von 2 bis 256 dokumentiert. Sie erklärt nicht, wie sich diese Angaben zueinander verhalten. Deshalb wird ein Wert oberhalb von 64 nicht allein aus der CLI-Spanne als zulässiges Produktdesign abgeleitet.

Vor einer Änderung hält man den aktuellen Zustand mit show fest. War vorher der Default aktiv, führt der Rückweg über reset. War ein eigener Grenzwert gesetzt, wird genau dieser Wert mit set limit <vorheriger Wert> wiederhergestellt. Anschliessend bestätigt ein erneutes show den erwarteten Zustand.

Bridge sicher zurückbauen

Vor dem Löschen werden Object Usage, Regeln, NAT, VLANs, DHCP, Routen, Hosts, Member-Zonen und Managementzugang dokumentiert. Zuerst entsteht ein Ersatzpfad, der mit echtem Traffic getestet wird. Erst danach werden produktive Abhängigkeiten entfernt, die Bridge gelöscht und die Member kontrolliert neu gebunden.

Nach dem Rückbau werden Gateway, DNS, Management, produktive Anwendungen, Firewall Rule ID und Rückweg erneut geprüft. Erst wenn diese Tests dem dokumentierten Ausgangszustand entsprechen, ist der Change abgeschlossen.

Häufige Fragen