OPNsense Layer 2 Firewall - Versionsgeschichte

Thomas.will: /* Antwortverkehr */

2026-09-04T04:14:14Z

Antwortverkehr

Thomas.will: /* Was pf auf der Brücke nicht sieht */

2026-09-04T04:12:07Z

Was pf auf der Brücke nicht sieht

Thomas.will: /* Schritt 5: Regeln */

2026-09-04T04:11:17Z

Schritt 5: Regeln

Thomas.will: /* Schritt 3: Bridge anlegen */

2026-09-04T04:08:42Z

Schritt 3: Bridge anlegen

Thomas.will: /* Vorbereitung */

2026-09-04T04:08:18Z

Vorbereitung

Thomas.will: Die Seite wurde neu angelegt: „= Transparente Filterbrücke (Layer-2-Firewall) = * Eine transparente Firewall filtert Verkehr, ohne dass unterschiedliche Subnetze angelegt werden * Die Firew…“

2026-09-04T03:54:18Z

Die Seite wurde neu angelegt: „= Transparente Filterbrücke (Layer-2-Firewall) = * Eine transparente Firewall filtert Verkehr, ohne dass unterschiedliche Subnetze angelegt werden * Die Firew…“

Neue Seite

= Transparente Filterbrücke (Layer-2-Firewall) =
* Eine transparente Firewall filtert Verkehr, ohne dass unterschiedliche Subnetze angelegt werden
* Die Firewall überbrückt dieselbe Broadcast-Domäne über zwei Schnittstellen und filtert auf der Brücke
* Für die Clients ist sie unsichtbar: kein Gateway, keine neue Adresse, keine Routen
* Typische Einsatzfälle:
** Ein einzelnes System oder ein Segment absichern, ohne die vorhandene Adressierung anzufassen
** Altsysteme schützen, die selbst keine Firewall mitbringen
** Verkehr beobachten und per IDS/IPS untersuchen

== Abgrenzung ==
* '''Nicht kompatibel mit Traffic Shaping'''
* '''Nicht kompatibel mit CARP''' – eine Filterbrücke ist keine Option für den HA-Cluster, sondern eine eigene Maschine
* Gefiltert wird weiterhin auf Layer 3 und 4. "Layer 2" beschreibt die Einbindung ins Netz, nicht die Filterkriterien – MAC-Adressen sind mit pf keine Regelkriterien

= Vorbereitung =
* Eine OPNsense-Installation mit '''drei''' Netzwerkkarten
{| class="wikitable"
! Schnittstelle !! Rolle !! Adresse
|-
| em0 || MGMT (Verwaltung) || 172.16.99.1/24
|-
| em1 || Bridge-Mitglied (außen) || keine
|-
| em2 || Bridge-Mitglied (innen) || keine
|}
* Die Verwaltung läuft über eine eigene Karte, weil die Brücke selbst keine Adresse trägt
* Ohne diese dritte Karte sperrst du dich aus, sobald die Mitglieds-Interfaces auf ''None'' stehen

== Hypervisor ==
* Beide Bridge-Mitglieder müssen in den '''Promiscuous-Modus''' geschaltet werden
** VirtualBox: Maschine => Ändern => Netzwerk => Adapter => Erweitert => Promiscuous-Modus: '''Alle erlauben'''
* Eine Brücke leitet Frames fremder MAC-Adressen weiter – ohne Promiscuous verwirft der Hypervisor sie

= Konfiguration =
== Schritt 1: Mitglieds-Interfaces vorbereiten ==
* Interfaces => em1 und Interfaces => em2:
{| class="wikitable"
! Parameter !! Wert
|-
| IPv4 Configuration Type || None
|-
| IPv6 Configuration Type || None
|-
| Block private networks || deaktiviert
|-
| Block bogon networks || deaktiviert
|}
* Ein DHCP-Server, der an eines dieser Interfaces gebunden ist, muss abgeschaltet werden

== Schritt 2: Tunables setzen ==
* System => Settings => Tunables
{| class="wikitable"
! Tunable !! Wert !! Bedeutung
|-
| net.link.bridge.pfil_bridge || 1 || Es wird auf der Brücke gefiltert
|-
| net.link.bridge.pfil_member || 0 || Auf den Mitglieds-Interfaces wird nicht gefiltert
|}
;Achtung
* Nach dieser Einstellung werden Regeln auf den Mitglieds-Interfaces '''ignoriert'''
* Das ist die häufigste Fehlerquelle: Die Regeln stehen unter WAN oder LAN und bleiben wirkungslos

== Schritt 3: Bridge anlegen ==
* Interfaces => Devices => Bridge => '''+'''
{| class="wikitable"
! Parameter !! Wert
|-
| Member Interfaces || em1, em2
|-
| Description || Bridge
|}

== Schritt 4: Bridge zuweisen ==
* Interfaces => Assignments: die neue bridge0 als Schnittstelle zuweisen und aktivieren
* Configuration Type bleibt '''None'''

== Schritt 5: Regeln ==
* Alle Regeln werden auf der '''Bridge''' angelegt
* Zum ersten Test eine Allow-Regel für jeden Verkehr erstellen und die Brücke damit vollständig transparent machen
* Erst danach die eigentlichen Filterregeln schreiben – so lässt sich sauber trennen, ob ein Problem an der Brücke oder an einer Regel liegt

= Funktionstest =
* Client hinter der Brücke behält seine bisherige Adresse, sein bisheriges Gateway und seinen bisherigen DNS-Server
* Erreichbarkeit prüfen:
ping 192.168.HS.254
* Auf der Firewall mitlesen:
tcpdump -n -i bridge0
* Die MAC-Tabelle der Brücke anzeigen:
ifconfig bridge0 addr
* Danach eine Blockregel setzen, etwa auf ICMP, und prüfen, dass der Ping stoppt – der Client merkt dabei nicht, wodurch er blockiert wird

= Debugging =
{| class="wikitable"
! Beobachtung !! Ursache
|-
| Regeln greifen nicht || Regeln liegen auf den Mitglieds-Interfaces statt auf der Bridge
|-
| Kein Verkehr über die Brücke || Promiscuous-Modus im Hypervisor fehlt
|-
| Verwaltung nicht mehr erreichbar || Kein eigenes MGMT-Interface vorhanden
|-
| Einzelne Protokolle kommen nicht durch || Mitglieds-Interface steht noch auf "Block private networks"
|}

* Zustand der Brücke prüfen:
ifconfig bridge0
* Zählen, ob Regeln überhaupt matchen:
pfctl -s rules -v

= IDS/IPS auf der Brücke =
* Der Aufbau ist ausdrücklich dafür gedacht, den gesamten Verkehr zusätzlich per Netmap-Treiber durch IDS/IPS zu schicken
* Suricata wird dabei auf die '''Mitglieds-Interfaces''' gelegt, nicht auf die Brücke
* Siehe [[OPNsense Suricata Einrichtung]]

@@ Zeile 132: / Zeile 132: @@
 * Im Labor mit einer einzelnen Brücke tritt das nicht auf; in der Praxis mit mehreren Wegen durch das Segment schon
-=== Aussperren
+=== Aussperren verhindern ===
 = Funktionstest =

@@ Zeile 83: / Zeile 83: @@
 * Die Richtung lässt sich deshalb nicht mehr über das Interface unterscheiden, sondern nur noch über '''Quell- und Zieladresse'''
 * Das ist der gedankliche Unterschied, der im Betrieb die meisten Fehler verursacht: Regeln, die man von einer routenden Firewall übernimmt, greifen an der falschen Stelle
 === Erste Stufe: transparent schalten ===

@@ Zeile 76: / Zeile 76: @@
 == Schritt 5: Regeln ==
-* Alle Regeln werden auf der '''Bridge''' angelegt
+* Alle Regeln werden auf der '''Bridge''' angelegt, nicht auf em1 oder em2
-* Zum ersten Test eine Allow-Regel für jeden Verkehr erstellen und die Brücke damit vollständig transparent machen
-* Erst danach die eigentlichen Filterregeln schreiben – so lässt sich sauber trennen, ob ein Problem an der Brücke oder an einer Regel liegt
+=== Besonderheit gegenüber einer routenden Firewall ===
 = Funktionstest =

@@ Zeile 66: / Zeile 66: @@
 ! Parameter !! Wert
 |-
-| Member Interfaces || em1, em2
+| Member Interfaces || IN, OUT
 |-
 | Description || Bridge

@@ Zeile 16: / Zeile 16: @@
 * Eine OPNsense-Installation mit '''drei''' Netzwerkkarten
 {| class="wikitable"
-! Schnittstelle !! Rolle !! Adresse
+! Schnittstelle !! Name !! Rolle !! Adresse
 |-
-| em0 || MGMT (Verwaltung) || 172.16.99.1/24
+| em0 || MGMT || (Verwaltung) || 172.16.99.1/24
 |-
-| em1 || Bridge-Mitglied (außen) || keine
+| em1 || OUT || Bridge-Mitglied (außen) || keine
 |-
-| em2 || Bridge-Mitglied (innen) || keine
+| em2 || IN || Bridge-Mitglied (innen) || keine
 |}
 * Die Verwaltung läuft über eine eigene Karte, weil die Brücke selbst keine Adresse trägt