# OPNsense Floating Rules: Globale Policies & Egress-Filtering

TL;DR / Management Summary Während normale Interface-Regeln (Artikel 553) immer am Eingang (Inbound) prüfen, sind Floating Rules die Allrounder. Sie können auf mehrere Interfaces gleichzeitig wirken und sowohl den Eingang (Ingress) als auch den Ausgang (Egress) filtern. Ein Senior Admin nutzt Floating Rules primär für globale Sperrlisten (Geo-IP), zur Priorisierung von Traffic (QoS) und um sicherzustellen, dass kein unverschlüsselter Traffic die Firewall Richtung Internet verlässt.

# 1. Einführung & Logik

Die Ausnahme von der Regel.

Normalerweise gilt: Interface Rule Match = Stop. OPNsense prüft Floating Rules vor den Interface-Regeln, es sei denn, die Option “Quick” ist nicht gesetzt.

# Schlüssel-Optionen

  1. Quick: Wenn aktiviert, bricht die Firewall-Prüfung beim ersten Treffer ab (wie normale Regeln). Wenn deaktiviert, wird die Regel nur gemerkt, und die Prüfung geht weiter (Last Match Wins).
  2. Direction:
    • In: Paket kommt vom Kabel in die Firewall.
    • Out: Paket verlässt die Firewall Richtung Kabel.
  3. Interfaces: Sie können Strg+Klick nutzen, um z.B. WAN1, WAN2 und alle VPN-Tunnel gleichzeitig auszuwählen.

# 2. Anwendungsfälle für Floating Rules

Wann man sie wirklich braucht.

# 1. Globales Blocken (Malware/Geo-IP)

Anstatt auf jedem Interface (WAN, LAN, GUEST) die gleiche Sperrliste zu pflegen:

# 2. Egress Filtering (Ausgangsschutz)

Verhindern Sie, dass interne Server über inoffizielle Wege nach draußen sprechen.

# 3. Traffic Shaping (QoS)

Für die Zuweisung von Paketen in Shaper-Queues (Artikel 552) sind Floating Rules oft zwingend, da nur hier die Direction: Out zuverlässig gefiltert werden kann.

# 3. Deep Dive: ‘Quick’ vs. ‘Non-Quick’

Die Verarbeitungs-Reihenfolge.

Dies ist der häufigste Fehler bei der Nutzung von Floating Rules.

# 4. Day-2 Operations: ICMP Härtung

Ping sinnvoll einschränken.

Nutzen Sie Floating Rules, um ICMP (Ping) global über alle Netze hinweg konsistent zu erlauben oder zu drosseln.

# 5. Troubleshooting & “War Stories”

Wenn die globale Regel alles sperrt.

# Top 3 Fehlerbilder

  1. Symptom: Das Internet ist für alle weg, obwohl die LAN-Regeln auf “Allow Any” stehen.

    • Ursache: Eine Floating Rule mit Quick Option blockiert den Traffic global.
    • Lösung: Firewall -> Diagnostics -> Live View. Filtern Sie nach “Label”, um den Namen der Floating Rule zu finden.

  2. Symptom: Direction: Out Regeln am WAN-Port blockieren den Zugriff auf die Firewall selbst.

    • Lösung: Nutzen Sie Source: WAN address statt Source: Any für Egress-Regeln am WAN.

  3. Symptom: Regeln für IPsec-Tunnel funktionieren nicht.

    • Lösung: IPsec-Traffic wird oft erst nach der Interface-Prüfung entschlüsselt. Floating Rules sind oft der einzige Weg, diesen Traffic sauber zu erfassen.

# “War Story”: Der “Auto-Kill” für das Home Office

Ein Admin wollte verhindern, dass User via VPN den privaten Drucker im LAN nutzen können. Er erstellte eine Floating Rule Direction: Out, Source: VPN_NET, Dest: LAN_NET -> Block. Das Ergebnis: Die User konnten sich einwählen, bekamen aber keine GPOs und kein DNS mehr. Die Ursache: Da der DC im LAN-Netz stand, blockierte die Out-Regel auch die Antworten der Domänencontroller an die VPN-Clients. Lehre: Out Regeln sind extrem mächtig, aber gefährlich, da sie oft den “Rückweg” von Paketen blockieren, an den man im ersten Moment nicht denkt. Nutzen Sie für 90% der Aufgaben lieber In Regeln am Interface.

# 6. Monitoring & Reporting

Transparenz für globale Regeln.

# Custom Log Labels

Geben Sie jeder Floating Rule ein eindeutiges Label (z.B. GLOBAL_GEO_BLOCK).

# 7. Fazit & Empfehlung

Floating Rules sind das “Skalpell” im Werkzeugkasten.

# Anhang: Cheatsheet

Feld Einstellung Wirkung
Interface WAN, LAN, … Gilt für alle markierten Netze
Direction In Bevor das Paket die FW betritt
Direction Out Bevor das Paket die FW verlässt
Quick Yes Sofortiger Abbruch bei Match
Quick No Prüfung geht weiter

# Referenzen