OPNsense - Firewall-Regeln
Auf einen Blick
| Gilt für | OPNsense 26.1 und 26.7 (Firewall → Rules, Aliases, Groups, Categories) |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 30 Minuten (Regelwerk für LAN, DMZ und Gäste) |
| Rechte | Administrator (OPNsense-WebUI) |
| Stand | Oktober 2026 (OPNsense 26.7.5) |
Firewall-Regeln in OPNsense legen fest, welcher Verkehr zwischen Netzen, ins Internet und zur Firewall selbst erlaubt ist. OPNsense arbeitet mit einem zustandsbehafteten Paketfilter (FreeBSD pf): Eine erlaubte Verbindung wird als State gespeichert, die Antworten passieren automatisch. Seit OPNsense 26.7 werden Regeln ausschließlich über die moderne Oberfläche Firewall → Rules mit Schnittstellen-Auswahl, Kategorien, Suche, Statistik und API gepflegt; die alten Regelseiten gibt es nur noch im Plugin os-firewall-legacy.
Dieser Artikel erklärt die Grundlagen (States, Aktionen, Richtung, Reihenfolge), den Aufbau einer Regel, Aliase, Gruppen und Kategorien, ein bewährtes Regelwerk für typische Netze, Logging und Diagnose, die erweiterten Optionen sowie die Migration von Altregeln.
Grundlagen
States
Regeln sind standardmäßig stateful: Ist eine Verbindung einmal erlaubt, merkt sich die Firewall ihren Zustand. Antwortpakete werden ohne eigene Regel zugelassen, und weitere Pakete derselben Verbindung müssen das Regelwerk nicht erneut durchlaufen – das ist schneller und sicherer, da z. B. TCP-Sequenznummern geprüft werden. Nach Regeländerungen können bestehende States weiterlaufen; bei Bedarf unter Firewall → Diagnostics → States zurücksetzen.
Aktionen
| Aktion | Wirkung | Einsatz |
|---|---|---|
| Pass | erlaubt den Verkehr | – |
| Block | verwirft still | nicht vertrauenswürdige Netze (Internet) |
| Reject | verwirft und meldet es dem Absender (TCP-RST bzw. ICMP unreachable) | interne Netze – Clients warten nicht auf ein Timeout |
Richtung und Schnittstelle
Regeln werden standardmäßig auf eingehenden Verkehr (in) der Schnittstelle angewendet, auf der der Verkehr ankommt. Eine Regel „LAN darf ins Internet“ gehört also auf die Schnittstelle LAN, eine Regel „Internet darf auf den Webserver“ auf WAN. Ausgehender Verkehr der Firewall ist standardmäßig erlaubt. Ohne passende Pass-Regel greift am Ende die Default-Deny-Regel – alles Nichterlaubte wird blockiert.
Reihenfolge der Auswertung
Die OPNsense-Dokumentation beschreibt diese Reihenfolge:
- automatische Systemregeln am Anfang,
- Floating-Regeln (Regeln mit mehreren Schnittstellen, einer invertierten Schnittstelle oder ohne feste Schnittstelle),
- Gruppen-Regeln (Regeln auf einer Interface-Gruppe),
- Schnittstellen-Regeln (genau eine Schnittstelle),
- automatische Systemregeln am Ende (u. a. Default Deny).
Innerhalb eines Abschnitts gilt die Sort order (Priorität + Sequence). Mit Quick (Standard) gewinnt die erste passende Regel; ohne Quick gewinnt die letzte. NAT-Regeln werden immer vor den Filterregeln ausgewertet – eine Portweiterleitung mit Pass umgeht damit alle übrigen Regeln (siehe OPNsense - NAT und Portweiterleitungen).
Die Oberfläche: Firewall → Rules
- Schnittstellen-Filter: zeigt alle Regeln, die für eine Schnittstelle gelten – inklusive Floating- und Gruppenregeln. Neue Regeln übernehmen die gewählte Schnittstelle.
- Kategorien (Firewall → Categories): Regeln farbig gruppieren und filtern, z. B. Mailserver, VoIP, Admin; die Baumansicht zeigt Kategorien als Ordner.
- Inspect: blendet alle automatischen Systemregeln und die Statistik je Regel (Pakete, Bytes, States) ein; die Suche findet dann auch IP-Adressen in Aliasen.
- Verschieben: Regeln markieren und mit „Move rule before this rule“ einsortieren oder die Sequence setzen.
- Audit-Historie: wer hat wann was geändert – mit Notizfeld für die Begründung.
Eine Regel anlegen
Die wichtigsten Felder:
| Feld | Hinweis |
|---|---|
| Enabled / Description / Categories | sprechende Beschreibung, z. B. LAN → DMZ HTTPS |
| Interface (rule) | eine Schnittstelle, eine Gruppe oder mehrere (= Floating) |
| Action | Pass, Block oder Reject |
| Quick | aktiv lassen (erste passende Regel gewinnt) |
| Direction | in (Standard) |
| Version / Protocol | IPv4, IPv6 oder beides; TCP, UDP, TCP/UDP, ICMP … |
| Source / Destination | Netz, Host, Alias oder vordefinierte Werte wie LAN net, This Firewall; per Invert umkehrbar |
| Destination Port | Port, Bereich, Name (https) oder Port-Alias – Quellport fast immer any |
| Log | Protokollierung dieser Regel (für Block-Regeln und sensible Freigaben empfohlen) |
| Gateway | default oder ein Gateway bzw. eine Gateway-Gruppe für Policy-based Routing (siehe OPNsense - Gateways und Multi-WAN) |
| Schedule | Regel nur zu bestimmten Zeiten aktiv (Firewall → Settings → Schedules) |
Nach dem Speichern Apply – erst dann ist die Änderung aktiv.
Aliase, Gruppen und Kategorien
Aliase
Firewall → Aliases bündelt Adressen und Ports unter einem Namen (ausführlich im Artikel Aliase in OPNsense) – Regeln bleiben lesbar und Änderungen erfolgen an einer Stelle:
| Typ | Beispiel |
|---|---|
| Host(s) | srv_mail = 192.168.20.25; auch DNS-Namen, die regelmäßig aufgelöst werden
|
| Network(s) | RFC1918 = 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
|
| Port(s) | ports_web = 80, 443 |
| URL Table / URL (IPs) | externe Listen, z. B. Blocklisten oder Cloud-Adressbereiche |
| GeoIP | Länder – siehe OPNsense - Mit GeoIP-Filter |
| URL Table in JSON format, BGP ASN | Adressbereiche aus JSON-Quellen bzw. alle Netze eines autonomen Systems |
| MAC address, Dynamic IPv6 Host, Network group, OpenVPN group, External (advanced), Internal (automatic) | Sonderfälle: Geräte per MAC, IPv6-Hosts mit wechselndem Präfix, verschachtelte Aliase, Benutzergruppen im OpenVPN, von Diensten befüllte Aliase |
Systemaliase wie __captiveportal_zone_0 oder __qfeeds_malware_ip werden von Diensten gepflegt; Firewall → Diagnostics → Aliases zeigt den aktuellen Inhalt.
Interface-Gruppen
Firewall → Groups fasst Schnittstellen zusammen (z. B. alle Gäste- und IoT-VLANs). Regeln auf der Gruppe gelten für alle Mitglieder und werden vor den Schnittstellenregeln ausgewertet – ideal für gemeinsame Sperren wie „keine internen Netze“.
Ein bewährtes Regelwerk
Grundprinzip nach Least Privilege: nur erlauben, was gebraucht wird – der Rest fällt auf Default Deny.
| Schnittstelle | Regeln (Reihenfolge) |
|---|---|
| WAN | nur Freigaben für veröffentlichte Dienste bzw. VPN (z. B. UDP 51820 für WireGuard, UDP 500/4500 für IPsec) – sonst nichts |
| LAN | 1. Pass → Firewall: DNS, NTP; 2. Pass → DMZ: benötigte Dienste (z. B. HTTPS); 3. Pass → Admin-Zugriffe nur aus einem Admin-Netz; 4. Pass → any (Internet) – oder gezielt nur Web, Mail, VPN |
| DMZ | 1. Pass → Firewall: DNS, NTP; 2. Block → RFC1918; 3. Pass → any (Updates) |
| Gäste (Gruppe Untrusted) | 1. Pass → Firewall: DNS; 2. Block → RFC1918 und This Firewall; 3. Pass → any |
| Management | Zugriff auf Weboberfläche und SSH nur von Admin-Arbeitsplätzen |
Weitere Empfehlungen:
- Weboberfläche der Firewall nicht aus allen Netzen erreichbar machen; die automatische Anti-Lockout-Regel auf LAN erst deaktivieren (Firewall → Settings → Advanced), wenn eine eigene Admin-Regel existiert.
- Ausgehend filtern: Statt LAN → any nur benötigte Dienste erlauben; DNS nur zur Firewall zulassen bzw. umleiten (siehe OPNsense - Unbound DNS Resolver).
- Block private networks und Block bogon networks an WAN-Schnittstellen aktiv lassen (Interface-Einstellungen).
- Für Netzsegmentierung siehe OPNsense - VLAN und Netzwerksegmentierung.
Logging und Diagnose
- Firewall → Log Files → Live View: Echtzeitansicht mit Filtern nach Schnittstelle, Aktion, Adressen; ein Klick auf einen Eintrag zeigt die auslösende Regel (auch automatische Regeln mit Bezeichnung).
- Firewall → Log Files → Overview: Statistiken zu Top-Quellen, -Zielen und -Ports.
- Firewall → Diagnostics → States und Sessions: aktive Verbindungen, Top-Nutzer; States gezielt löschen.
- Inspect in der Regelansicht: Zähler je Regel – Regeln mit Zähler 0 greifen nie.
- Für eine zentrale Auswertung Logs an ein SIEM senden, z. B. mit dem Wazuh-Agent.
Erweiterte Optionen
| Option | Zweck |
|---|---|
| Interface (origin) / received-on | seit 26.7.3: Regeln (meist out) auf Pakete beschränken, die ursprünglich auf einer bestimmten Schnittstelle empfangen wurden |
| State type | keep state (Standard), sloppy (asymmetrisches Routing), none (zustandslos) |
| State policy | States nur an der Schnittstelle oder schnittstellenübergreifend (floating) gültig |
| Max states / Max source connections / Max new connections | Schutz gegen Überlastung und Brute Force; mit Overload table werden auffällige Absender automatisch in eine Sperrtabelle (virusprot) übernommen |
| Traffic shaper | Pipe/Queue direkt zuweisen (siehe OPNsense - Traffic Shaper und QoS) |
| Divert-to | Pakete an einen Dienst übergeben, z. B. Suricata im Divert-Modus (siehe OPNsense - Suricata Intrusion Detection und Prevention) |
| Reply-to / Disable reply-to | Rückweg über das Eingangs-Gateway (Multi-WAN) |
| Set priority / Match TOS/DSCP / Tags | Priorisierung (802.1p) und Markierungen über mehrere Regeln hinweg |
| No pfsync / No XMLRPC Sync | Regel bzw. ihre States von der HA-Synchronisation ausnehmen |
Migration alter Regeln
Installationen, die noch Regeln der alten Oberfläche nutzen, übertragen diese mit dem Migrationsassistenten: Export der alten Regeln als CSV, Prüfung (z. B. in einer Tabellenkalkulation), Import in die neue Oberfläche, Kontrolle und anschließend Entfernen der Altregeln. Vorher Konfiguration sichern bzw. ZFS-Snapshot anlegen und über das LAN arbeiten, ohne die Anti-Lockout-Regel zu deaktivieren. Bis zur Migration stehen die alten Seiten über das Plugin os-firewall-legacy zur Verfügung; Floating- und Gruppenregeln beider Oberflächen werden gemeinsam ausgewertet.
Typische Probleme und Lösungen
| Symptom | Ursache und Lösung |
|---|---|
| Regel greift nicht | Falsche Schnittstelle (Regeln gelten eingehend dort, wo der Verkehr ankommt), eine frühere Regel passt zuerst (Quick), Apply vergessen, bestehende States – States löschen. |
| Verkehr wird blockiert, Ursache unklar | Live View öffnen und auf den Eintrag klicken – die blockierende Regel wird angezeigt. |
| Portweiterleitung umgeht Sperren | NAT-Regel mit Pass – auf Manual mit eigener Filterregel umstellen. |
| Interne Netze per Policy-based Routing ins Internet geschickt | Regel mit Gateway fängt internen Verkehr ab – Regel für interne Ziele ohne Gateway davor. |
| Asymmetrisches Routing bricht Verbindungen | State type sloppy für die betroffene Regel oder Routing korrigieren. |
| Weboberfläche nach Regeländerung nicht erreichbar | Konsole nutzen; Anti-Lockout bzw. Admin-Regel wiederherstellen. |
| Alias-Inhalt fehlt (DNS-Namen, URL-Tabellen) | Auflösung/Download fehlgeschlagen – Firewall → Diagnostics → Aliases prüfen. |
Fazit
Ein gutes Regelwerk auf der OPNsense folgt wenigen Prinzipien: Regeln dort anlegen, wo der Verkehr ankommt, nur Benötigtes erlauben, Aliase und Gruppen für Übersicht und Wiederverwendung nutzen und Freigaben protokollieren. Die neue Regeloberfläche von OPNsense 26.7 unterstützt das mit Kategorien, Inspect-Ansicht, Statistiken, Audit-Historie und API – und macht Fehlersuche über das Live-Log zur Sache weniger Klicks.
Unterstützung von m.a.x. it
Sie möchten Ihr Regelwerk überprüfen, auf die neue Oberfläche migrieren oder nach dem Least-Privilege-Prinzip neu aufbauen? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.
Siehe auch
- OPNsense - Aliase
- Firewall
- Least Privilege
- Zero Trust
- OPNsense - NAT und Portweiterleitungen
- OPNsense - VLAN und Netzwerksegmentierung
- OPNsense - Gateways und Multi-WAN
- OPNsense - Mit GeoIP-Filter
- OPNsense - Eine kurze Einführung
Links und Quellen
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
