OPNsense Layer 2 Firewall

Aus Xinux Wiki
Version vom 4. September 2026, 03:54 Uhr von Thomas.will (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „= Transparente Filterbrücke (Layer-2-Firewall) = * Eine transparente Firewall filtert Verkehr, ohne dass unterschiedliche Subnetze angelegt werden * Die Firew…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

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
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:
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
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 => +
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

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