Sophos Firewall Bridge-Interface einrichten und testen
Ein Bridge-Interface verbindet mehrere physische oder virtuelle Interfaces auf Layer 2. Damit lässt sich eine Sophos Firewall transparent in einen bestehenden Pfad einsetzen oder ein bewusst geroutetes Bridge-Gateway aufbauen. Die zentrale Entscheidung fällt vor dem Anlegen: Soll die Bridge nur Frames weiterleiten oder selbst eine IP-Adresse besitzen und routen?
⚠️ Eine falsche Bridge-Konfiguration kann eine Layer-2-Schleife, einen Broadcast Storm oder den Verlust des Managementzugangs verursachen. Vor der Verkabelung braucht es ein Backup, ein Wartungsfenster, einen unabhängigen Adminzugang und einen klaren Rückweg. Redundante Layer-2-Pfade werden erst aktiviert, wenn STP und das HA-Design geklärt sind.
Transparent oder geroutet
Eine transparente Bridge ohne IP-Adresse leitet Frames zwischen ihren Membern weiter. Sie kann Netze verbinden, ohne selbst als Gateway aufzutreten. Das passt zu kontrollierten Migrationen oder zu einem Inline-Pfad, in dem die bestehende IP-Architektur unverändert bleiben soll.
Eine geroutete Bridge mit IP-Adresse wird unter Enable routing on this bridge pair aktiviert. Die Bridge-IP kann dann Gateway oder lokaler Firewall-Endpunkt sein. VLAN-Filtering auf der Bridge betrifft nur gebridgten Traffic, nicht gerouteten Traffic.
Auf unterstützten XGS-Modellen kann ein hardwareseitig festgelegtes Bridge-Portpaar zusätzlich als Fail-to-Wire-Pfad dienen. LAN Bypass einrichten und kontrolliert testen erklärt Modellgrenze, FTW-Portpaar, ungescannten Ausfalltraffic und die Rückkehr in den geschützten Betrieb. Zwei beliebige Bridge-Member erhalten diese Hardwarefunktion nicht.
Eine Bridge ist kein universeller Ersatz für ein eigenes WAN- oder VPN-Interface. Sophos unterstützt auf Bridge-Interfaces weder Dynamic DNS noch DHCP client, PPPoE oder IPsec VPN. Für neue segmentierte Netze sind VLANs und Routing häufig leichter zu betreiben. Die Auswahl zwischen Alias, Bridge, LAG, VLAN, XFRM und RED erklärt Zonen und Interfaces auf Sophos Firewall.
Beispiel und Member planen
Das Beispiel verbindet Port3 und Port4 transparent. Beide Ports liegen im selben geplanten Layer-2-Pfad; die Bridge erhält keine IP-Adresse. Die Werte sind Beispiele und werden durch die reale Verkabelung, Zonen und Managementstrategie ersetzt.
SFOS erlaubt bis zu 64 Member. Als Member kommen physische Interfaces, RED, LAG sowie VLAN-Interfaces auf einem physischen Interface, RED oder LAG infrage. Jeder Member wird vorab auf bestehende IP-Adressen, VLANs, DHCP, NAT, Regeln, Routing und Adminzugriffe geprüft.
Member-Zonen bleiben für Firewallregeln relevant. Eine Bridge erlaubt den Traffic nicht automatisch. Liegen beide Member beispielsweise in LAN, braucht der gewünschte Datenstrom trotzdem eine passende LAN-to-LAN-Regel.
Erweiterte Bridge-Kontrollen in der Device Console
Die normale Bridge-Konfiguration bleibt im WebAdmin. Die Device Console stellt zusätzlich drei systemweite beziehungsweise tiefgreifende Kontrollen bereit. Vor ihrer Verwendung werden Bridge-Name, Hardware-Name, Member, Port-IDs, MAC-Tabelle, Managementpfad und aktueller CLI-Status gesichert. Diese Befehle sind keine Abkürzung für fehlende Firewall-Regeln oder ein ungeklärtes Layer-2-Design.
Unbekannten nicht routbaren Traffic behandeln
bypass-firewall-policy betrifft nicht routbaren Bridge-Traffic, auf den keine Security Policy angewendet wird. SFOS unterscheidet dabei dynamic und static. Der aktuelle Status beider Kategorien wird zuerst gelesen:
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 ist sicherheitsrelevant, weil dieser Traffic ausdrücklich ohne Firewall-Policy weitergeleitet werden kann. Die SFOS-22-Hilfe nennt weder einen Standardwert noch erklärt sie die genaue Abgrenzung von dynamic und static. Deshalb wird keine Kategorie auf Verdacht geändert. Falls Sophos Support einen Wechsel vorgibt, wird in derselben Syntax show durch allow oder drop ersetzt und danach mit Status, Packet Capture und einem positiven sowie negativen 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 nur gezielt setzen
Die Bridge Forwarding Table lernt MAC-Adressen normalerweise dynamisch und entscheidet damit, über welchen Port Frames weitergeleitet werden. static-entry kann eine MAC-Adresse mit Bridge, Interface und Port fest verknüpfen. 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 sind Syntaxbeschreibung und werden nicht mitkopiert. Vor add werden die realen IDs mit show, Tab-Vervollständigung und der WebAdmin-Zuordnung geprüft. Ein falscher oder veralteter statischer Eintrag kann Frames auf den falschen Port lenken oder den Zielhost unerreichbar machen. Für den Rückbau wird genau der dokumentierte Eintrag mit delete entfernt. Danach müssen MAC-Lernen, Hin- und Rückweg sowie der Managementzugang wieder stimmen.
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 zusätzlich reset bereit:
system bridge max_bridge_members set limit <2-256>
system bridge max_bridge_members reset
Das ist nicht mit der veröffentlichten WebAdmin-Grenze gleichzusetzen. Sophos nennt für ein Bridge-Interface weiterhin maximal 64 Member. Der grössere CLI-Wertebereich ist deshalb kein unterstütztes Planungsziel für eine Bridge mit 256 Interfaces. Er wird nur für einen belegten Sonderfall und nach Abstimmung mit Sophos Support verändert. Da die Hilfe den resultierenden Standard nach reset nicht nennt, wird vorab festgehalten, ob der Ausgangszustand ein eigener Wert oder der Default war. Der Rückbau stellt genau diesen Zustand wieder her.
Bridge im WebAdmin anlegen
- Network > Interfaces > Add interface > Add bridge öffnen.
- Einen sprechenden Name mit höchstens 58 Zeichen vergeben, beispielsweise
Bridge_Inline. - Einen unveränderlichen Hardware name mit höchstens 10 Zeichen aus Buchstaben, Zahlen und
_festlegen, beispielsweisebrinline. Systemnamen wieall,ipsec0,xfrm,Port,eth,WLANoderHalinksind gesperrt. - Enable routing on this bridge pair nur aktivieren, wenn die Bridge bewusst eine IP-Adresse erhalten und routen soll.
- Die vorbereiteten Member interfaces und deren Zonen hinzufügen.
- Bei einer gerouteten Bridge IPv4 oder IPv6 sowie bei WAN-Membern den geplanten Gateway eintragen.
- VLAN-, ARP-, STP-, MTU-, MSS- und EtherType-Einstellungen prüfen.
- Save wählen und danach Link, Regeln und echten Datenfluss kontrollieren.
Ein frei gewählter Anzeigename lässt sich später ändern. Der Hardware name bleibt dagegen unveränderlich und sollte vor dem Speichern zur Namenskonvention passen.
VLAN- und EtherType-Filter verstehen
Mit Filter VLANs werden nur die unter Permitted VLAN ID or ID range eingetragenen VLANs weitergeleitet. Bereiche wie 20-35 sind möglich. Bleibt die Liste bei aktivem Filter leer, verwirft SFOS sämtlichen getaggten VLAN-Traffic; ungetaggter Traffic bleibt davon unberührt.
Dieser Filter wirkt nur auf gebridgte Frames. Er ist keine Firewallregel für gerouteten Traffic. Der versionsgebundene Sonderfall mit alten system vlan-tag-Konfigurationen wird separat unter Bridge-VLANs nach SFOS 22 prüfen behandelt.
Mit Filter Ethernet frames kann die Bridge EtherTypes einschränken. Ohne erlaubte Werte werden alle Frames ausser den immer erlaubten Typen ARP, IPv4, IPv6, 8021Q und EXTE verworfen. Weitere Typen werden als vierstellige Hex-ID eingetragen, beispielsweise 809B, 8138, 8863 oder 8864. Solche Freigaben werden nur aufgrund einer konkreten Protokollanforderung ergänzt.
ARP, STP, MTU und MAC Aging
Permit ARP broadcast ist standardmässig aktiv. Ohne ARP-Broadcast kann die Bridge keine normale MAC-Tabelle über ARP aufbauen. Das Abschalten ist deshalb kein allgemeiner Broadcast-Schutz, sondern eine enge Massnahme bei einem belegten Storm und verlangt passende statische Einträge unter Neighbors (ARP–NDP).
Spanning Tree Protocol (STP) schützt vor Layer-2-Schleifen und kann einen redundanten Pfad übernehmen. Bei aktiviertem HA lässt sich STP auf Bridge-Interfaces jedoch nicht einschalten. Ein Design darf deshalb nicht gleichzeitig auf eine unbekannte Schleifenvermeidung und HA vertrauen. STP max age steht standardmässig auf 20 Sekunden und wird nur passend zur gesamten STP-Domäne verändert.
MAC aging entfernt inaktive MAC-Adressen standardmässig nach 300 Sekunden. Kürzere Werte können in dynamischen Netzen sinnvoll sein, längere in stabilen Netzen. Änderungen werden mit Switch- und Anwendungszustand begründet, nicht als pauschaler Performance-Tipp.
Weichen MTU der Bridge und ihrer Member voneinander ab, übernimmt die Bridge den kleineren Wert. Ein Member mit MTU 1500 begrenzt damit auch eine Bridge, die auf 9000 konfiguriert wurde. Override MSS wird nur bei einem belegten TCP-/MTU-Problem verwendet. Der kontrollierte Prüfweg steht unter MTU und MSS auf Sophos Firewall prüfen.
Regeln, NAT und Web Proxy
Traffic zwischen Bridge-Membern benötigt eine passende Firewallregel zwischen den beteiligten Zonen. Source, Destination und Service werden so eng wie möglich gewählt; Logging bleibt während der Abnahme aktiv. Die allgemeine Regelmechanik erklärt Firewallregeln auf Sophos Firewall.
Bei einer Bridge ohne IP-Adresse gibt es eine wichtige Stop-Bedingung: Trifft der Traffic eine Firewallregel mit Web Proxy Filtering oder eine NAT-Regel, kann SFOS die Pakete ohne Logeintrag verwerfen. Die sichtbare Regelwirkung wird deshalb nicht mit einem gewöhnlichen Drop im Log Viewer verwechselt.
Ist eine NAT-Regel im Pfad unvermeidbar, wird für genau diese Bridge unter Override source translation for specific outbound interfaces das Outbound interface auf die Bridge und Translated source (SNAT) auf Original gesetzt. Eine breite NAT-Änderung ist kein sicherer Test. Web Proxy Filtering wird auf einer transparenten Bridge nur eingesetzt, wenn das Design dafür ausdrücklich geeignet ist.
Bridge kontrolliert testen
Nach dem Speichern werden Control Plane und Nutztraffic getrennt geprüft:
- Unter Network > Interfaces Bridge, Member, Zonen, IP-Modus und Linkstatus mit dem Plan vergleichen.
- Die erwartete Firewall Rule ID mit einem einzelnen kontrollierten Testfluss bestätigen.
- Eingang und Ausgang im Packet Capture vergleichen; MAC-Adressen, VLAN-Tag und EtherType müssen zum Design passen.
- Einen erlaubten Dienst in beide Richtungen testen und einen bewusst nicht erlaubten Dienst negativ prüfen.
- Bei STP redundante Pfade nur im Wartungsfenster einzeln aktivieren und Topologie sowie Failover messen.
- Bei HA nach einem kontrollierten Rollenwechsel Bridge, Member, MAC-Lernen und Anwendungen erneut prüfen.
Für Bridge-ACL-Drops wird unter System services > Log settings > Firewall die Komponente Bridge ACLs aktiviert. Im Log Viewer lässt sich danach nach Log component > Bridge ACLs und den Subtypen ARP broadcasts, EtherType filtering oder VLAN filtering filtern.
Bleibt der Datenfluss unklar, zeigt Packet Capture auf Sophos Firewall, wie Ein- und Ausgangsinterface, Rule ID, Status und Reason zusammen gelesen werden.
Sicher zurückbauen
Vor dem Löschen werden Object Usage, Regeln, NAT, VLANs, DHCP, Routen, Hosts und Managementzugang der Bridge und aller Member dokumentiert. Zuerst wird ein Ersatzpfad eingerichtet und mit echtem Traffic getestet. Erst danach werden produktive Abhängigkeiten entfernt, die Bridge gelöscht und die Member kontrolliert neu gebunden.
Ein einzelner erfolgreicher Ping genügt nicht als Rollback-Beweis. Nach dem Rückbau werden Gateway, DNS, Management, produktive Anwendungen, Firewall Rule ID und Rückweg erneut geprüft.