OPNsense sauber betreiben: HA, VLANs und Suricata als IDS/IPS

/01Was „sauberer Betrieb" bei OPNsense bedeutet

Eine OPNsense-Firewall direkt aus der Installation heraus filtert Pakete nach Regeln — mehr nicht. Was im Mittelstand tatsächlich gebraucht wird, ist mehr: eine zweite Firewall, die übernimmt, wenn die erste ausfällt und so die Verfügbarkeit der Internetanbindung hält; ein Netz, das nicht aus einem einzigen flachen Segment besteht, in dem jedes Gerät jedes andere sehen kann; und eine Erkennungsschicht, die nicht nur Verbindungen erlaubt oder verbietet, sondern hinschaut, was durch die erlaubte Verbindung tatsächlich läuft.

Diese drei Bausteine — Hochverfügbarkeit, VLAN-Segmentierung und Suricata als Intrusion Detection respektive Prevention System — gehören zum laufenden Betrieb eines Managed Service, nicht zur einmaligen Einrichtung. Sie sind unabhängig voneinander nutzbar, verstärken sich aber gegenseitig: Eine Segmentierung ohne Hochverfügbarkeit hat trotzdem einen Single Point of Failure, eine Hochverfügbarkeit ohne Segmentierung schützt vor Geräteausfall, aber nicht vor einem kompromittierten Gerät im selben flachen Netz. Dieser Artikel geht alle drei durch, mit echten Konfigurationsbeispielen aus der Herstellerdokumentation, nicht mit vereinfachten Dashboards.

/02CARP-Hochverfügbarkeit: drei Teilsysteme im Zusammenspiel

CARP — Common Address Redundancy Protocol — ist laut OPNsense-Dokumentation der Mechanismus, über den zwei Firewalls eine gemeinsame virtuelle IP-Adresse betreiben und per Multicast-Pakete über IP-Protokoll 112 erkennen, welcher Knoten gerade aktiv ist. Jede virtuelle Schnittstelle trägt eine eigene Virtual Host ID (VHID), die auf beiden Firewalls identisch konfiguriert ist; welcher Knoten die Adresse führt, entscheidet der sogenannte Skew-Wert — niedriger Skew bedeutet höhere Priorität, der Master trägt üblicherweise den Wert 0.

CARP allein reicht aber nicht für einen unterbrechungsfreien Wechsel — und ein HA-Paar ist kein Ersatz für Disaster Recovery: Es hält die Internetanbindung bei einem Hardwaredefekt am Laufen, es rettet keine fehlerhaft gelöschte Konfiguration und keinen Datenverlust an anderer Stelle im Netz. Die Unterscheidung lohnt sich, weil beide Themen in Angeboten gern vermischt werden, obwohl sie unterschiedliche Probleme lösen. Zwei weitere Teilsysteme laufen mit: pfSync repliziert die Zustandstabelle laufender Verbindungen auf den passiven Knoten, damit eine bestehende Verbindung bei der Übernahme nicht neu aufgebaut werden muss, und XMLRPC gleicht die Konfiguration — Regeln, NAT, DHCP, virtuelle IPs — vom aktiven auf den passiven Knoten ab. Die OPNsense-Dokumentation empfiehlt für pfSync ausdrücklich ein eigenes, dediziertes Interface zwischen den beiden Firewalls, getrennt vom Produktivnetz, sowohl aus Sicherheits- als auch aus Leistungsgründen — eine Zustandsreplikation über das Produktivnetz ist ein zusätzlicher Angriffsvektor für die Einschleusung gefälschter Zustände.

Ein Missverständnis hält sich hartnäckig: CARP alleine, ohne pfSync, funktioniert bereits — die virtuelle IP wandert bei einem Ausfall zum Backup-Knoten, und neue Verbindungen laufen normal an. Was ohne pfSync verloren geht, sind die Verbindungen, die zum Ausfallzeitpunkt bereits bestanden: Eine laufende Dateiübertragung oder eine gehaltene VPN-Sitzung bricht ab und muss neu aufgebaut werden, statt ohne Unterbrechung weiterzulaufen. Für viele kleinere Umgebungen ist das ein hinnehmbarer Kompromiss; für eine Umgebung mit vielen lang laufenden, zustandsbehafteten Verbindungen — etwa Video- oder VPN-Konzentratoren — ist pfSync kein optionales Extra, sondern der eigentliche Grund, warum sich das HA-Paar lohnt.

/03Ein HA-Paar einrichten: VIPs und Stolperstellen

Die OPNsense-Dokumentation zeigt den Aufbau an einem konkreten Beispiel mit zwei virtuellen IPs, einer je Netzseite:

# System > High Availability > Virtual IPs (Beispielwerte aus der Doku)
WAN-VIP:  172.18.0.100/24   VHID 1   Skew 0   Advertising Base 1
LAN-VIP:  192.168.1.1/24    VHID 3   Skew 0   Advertising Base 1

# dediziertes pfSync-Interface zwischen den Knoten
Master:   10.0.0.1
Backup:   10.0.0.2

Vier Stolperstellen aus der Praxis, die in der Dokumentation als harte Voraussetzung stehen und bei einer Nachrüstung gern übersehen werden: Erstens müssen auf beiden Knoten exakt dieselben Schnittstellen zugeordnet sein — ein WAN-Port, der auf dem Backup-Knoten versehentlich an anderer Stelle hängt, bricht die Übernahme beim Ernstfall, nicht beim Testen vorher. Zweitens müssen die Subnetzmasken von virtueller IP und übergeordnetem Interface übereinstimmen, ein /24-Elternnetz verlangt eine /24-VIP. Drittens muss Preemption aktiv bleiben, damit ein Knoten mit niedrigerem Skew die Führung tatsächlich zurücknimmt, sobald er wieder verfügbar ist — ohne Preemption bleibt der vormalige Backup-Knoten Master, auch wenn der eigentliche Master längst wieder da ist, und niemand bemerkt das ohne gezielte Prüfung. Viertens braucht die vorgelagerte Netzinfrastruktur eine einheitliche Switch-Fabric oder gestapelte Switches — zwei unabhängige Switches ohne Kopplung führen bei CARP-Failover zu MAC-Flapping und im ungünstigsten Fall zu einem Split-Brain, bei dem beide Firewalls sich gleichzeitig für aktiv halten — eine Fehlersuche, die regelmäßig länger dauert als die eigentliche Wiederherstellungszeit bei einem einfachen Hardwaredefekt.

Mit Blick auf die Versionspflege ist eine Randnotiz wichtig: Ab der Community Edition 25.1.4 beziehungsweise Business Edition 25.4 ist laut Release-Dokumentation die automatische Demotion bei reinen Schnittstellenfehlern standardmäßig deaktiviert — in älteren Versionen konnte ein einzelner, kurzzeitiger Link-Fehler bereits einen ungewollten Failover auslösen. Wer eine ältere Installation übernimmt, sollte dieses Verhalten gezielt prüfen, statt sich auf die Standardwerte der eigenen Erinnerung zu verlassen.

Getestet wird ein HA-Paar nicht durch Zuschauen, sondern durch einen kontrollierten Failover: den aktiven Knoten im Wartungsfenster gezielt vom Netz trennen oder herunterfahren und prüfen, ob die virtuelle IP tatsächlich wandert, ob eine laufende SSH-Sitzung über die VIP bestehen bleibt, und ob der Zustand im Firewall-Diagnosebereich auf beiden Knoten übereinstimmt. Ein HA-Paar, das seit der Einrichtung nie einen echten Failover gesehen hat, ist eine Annahme, keine geprüfte Eigenschaft — und die erste echte Bewährungsprobe sollte nicht der tatsächliche Hardwaredefekt sein.

/04VLAN-Segmentierung: aus einem Netz mehrere machen

Ein einzelnes flaches Netz bedeutet: Jedes Gerät sieht jedes andere, und eine Firewall-Regel kann diese Sicht erst an der Grenze nach außen einschränken — innerhalb des Netzes läuft der Verkehr frei. VLANs lösen das, indem sie ein physisches Netz in mehrere logische Broadcast-Domänen aufteilen, jede mit eigenem Layer-3-Netz, zwischen denen die Firewall wieder mitreden kann. Die OPNsense-Dokumentation zeigt dafür das Beispiel dreier Netze: VLAN 5 für das LAN, VLAN 20 für eine DMZ, VLAN 33 für ein Gastnetz.

# Interfaces > Devices > VLAN (Beispielwerte aus der Doku)
Device    Parent   VLAN-Tag   Layer-3-Netz
vlan0.5   igc0     5          192.168.5.0/24   (LAN)
vlan0.20  igc0     20         192.168.20.0/24  (DMZ)
vlan0.33  igc0     33         192.168.33.0/24  (Gast)

Zwei Bedingungen aus der Dokumentation entscheiden, ob das im eigenen Netz überhaupt funktioniert: Der vorgelagerte Switch muss VLANs beherrschen — ein unmanaged Switch kennt keine Tags und reicht alles ungetrennt durch, egal wie sauber die Firewall-Seite konfiguriert ist. Und der Trunk zwischen Switch und Firewall darf nicht gemischt werden: entweder sauber getaggte VLANs oder ein einzelnes untagged Netz auf derselben Leitung, nicht beides gleichzeitig, sonst landet Verkehr im falschen Segment, ohne dass eine Firewall-Regel das verhindern könnte. Nach der Anlage der VLAN-Schnittstellen werden sie unter Interface-Zuweisungen aktiviert und bekommen eigene Firewall-Regelsätze — das Gastnetz braucht in aller Regel nur eine Regel „Internet erlaubt, alles andere verboten", kein Zugriff auf das Drucker- oder Produktionsnetz. Fernzugriffe von Mitarbeitern oder Dienstleistern gehören in dasselbe Schema: ein eigenes VPN-Segment, beispielsweise über IPsec aufgebaut, mit eigenen Firewall-Regeln, nicht ein direkter Durchgriff ins LAN-VLAN.

/05Suricata als IDS/IPS: die Betriebsarten

OPNsense bringt Suricata als integrierte Engine für Intrusion Detection und Prevention mit, und die Dokumentation unterscheidet drei Betriebsarten über die darunterliegende Capture-Methode. Im PCAP-Modus arbeitet Suricata rein überwachend: Es liest eine Kopie des Datenverkehrs mit, erzeugt Alarme, blockiert aber nichts — das klassische IDS-Verhalten, verfügbar auf nahezu jedem Schnittstellentyp. Im Netmap-Modus und im Divert-Modus arbeitet Suricata als IPS: Es sitzt im tatsächlichen Paketpfad und kann Pakete verwerfen, bevor sie ihr Ziel erreichen — der Divert-Modus leitet Pakete dafür über eine Firewall-Regel mit expliziter „divert"-Aktion um.

Für die Regelbasis selbst bietet OPNsense mehrere Quellen: das freie, BSD-lizenzierte ETOpen-Regelwerk mit unvollständiger, aber kostenloser Abdeckung, das kommerzielle ET-Pro-Regelwerk über einen Plugin-gestützten Zugangscode, dessen Signaturen auch auf bekannte CVE-Schwachstellen in verbreiteter Software reagieren, sowie thematische Sammlungen von abuse.ch wie die SSL-Blacklist, den Feodo-Tracker gegen bekannte Botnetz-Infrastruktur und die URLhaus-Liste gegen Malware-Verbreitung über Links. Seit Version 21.1 ordnet ein Policies-System diese Regelsätze feiner, als es die ältere Filterlogik erlaubte — einzelne Regelgruppen lassen sich gezielt aktivieren, deaktivieren oder in ihrer Aktion verändern, statt nur pauschal ein ganzes Regelwerk ein- oder auszuschalten.

Seit der Release-Serie 26.1 (28.01.2026) läuft die Inline-Prüfung auf Basis von Suricata 8, mit dem Divert-Modus als dem dafür vorgesehenen IPS-Pfad; die aktuell gepflegte Serie 26.7 (15.07.2026) liegt mit Stand 30.09.2026 bei Punktversion 26.7.5 und Suricata 8.0.7.

Welche Schnittstelle überhaupt überwacht wird, ist eine eigene Entscheidung: Ein Mitschnitt auf der WAN-Seite hinter der Network Address Translation zeigt nur übersetzte Adressen und damit kaum, welches interne Gerät für einen Treffer verantwortlich ist. Die Dokumentation empfiehlt deshalb ausdrücklich, auf den LAN-seitigen Schnittstellen mitzulesen, wo die tatsächlichen internen Adressen sichtbar sind — eine Regel, die auf „jeder sieht alles" aufsetzt, braucht dieses klare Bild des internen Netzes, sonst bleibt jeder Treffer eine Vermutung statt eines verwertbaren Hinweises.

/06Inline gegen überwachend: Durchsatz und Risiko abwägen

Der Unterschied zwischen IDS und IPS ist kein Konfigurationsdetail, sondern eine Grundsatzentscheidung mit entgegengesetzten Risiken. Im überwachenden PCAP-Modus kann eine fehlerhafte Regel höchstens zu viele Alarme erzeugen — ärgerlich, aber folgenlos für den Datenverkehr selbst. Im Inline-Modus kann dieselbe fehlerhafte Regel legitimen Datenverkehr verwerfen, und zwar in dem Moment, in dem sie aktiv wird, nicht erst, wenn jemand das Protokoll liest. Eine zu aggressiv formulierte Signatur im Divert-Modus kann im ungünstigsten Fall eine Geschäftsanwendung lahmlegen, ohne dass zunächst klar ist, dass die Firewall die Ursache ist.

Durchsatz ist der zweite Faktor: Jedes Paket, das inline geprüft wird, durchläuft die Signaturprüfung, bevor es weitergeleitet wird — bei hoher Bandbreite oder vielen gleichzeitigen Verbindungen kann das zur Engpassstelle werden, während der überwachende Modus parallel zur eigentlichen Weiterleitung mitliest und die Weiterleitung selbst nicht verzögert. Deshalb ist die Empfehlung in der Praxis zweistufig: zunächst im überwachenden Modus starten, die tatsächliche Alarmlast und das eigene Regelwerk über Wochen beobachten, und erst danach gezielt einzelne, gut verstandene Regelgruppen — etwa bekannte Command-and-Control-Signaturen mit geringer Fehlalarmquote — in den Inline-Modus überführen. Ein kompletter Wechsel auf Inline am ersten Tag ist der Weg, der am häufigsten zu ungeplanten Ausfällen führt.

Eine Zwischenlösung, die in der Praxis oft übersehen wird: Nicht die gesamte Firewall muss sich für einen Modus entscheiden. Eine WAN-Schnittstelle mit viel anonymem Internetverkehr verträgt Inline-Schutz eher als eine interne Schnittstelle, über die eine störungsempfindliche Fachanwendung läuft — hier kann der überwachende Modus bewusst dauerhaft bleiben, während die Außengrenze bereits aktiv blockiert. Diese Differenzierung nach Schnittstelle statt nach Firewall insgesamt ist der Unterschied zwischen einer Entscheidung, die zur eigenen Infrastruktur passt, und einer, die nur dem Prospekt folgt.

/07Fehlalarme bändigen: Schwellenwerte und Tracking

Eine Signatur, die bei jedem einzelnen Treffer einen Alarm erzeugt, erstickt den Alarmkanal in Routine — ein einzelner fehlgeschlagener Anmeldeversuch ist noch kein Angriff, erst eine Serie davon. Die Suricata-Dokumentation kennt dafür mehrere Grenzwerttypen. Der Typ „threshold" erzeugt erst ab dem n-ten Treffer einen Alarm, mit dem Beispiel count 10, seconds 60 — zehn gleichartige Treffer in einer Minute, bevor überhaupt etwas gemeldet wird. Der Typ „limit" begrenzt umgekehrt die Gesamtzahl der Alarme in einem Zeitraum, im Beispiel der Dokumentation count 1, seconds 180 — höchstens ein Alarm alle drei Minuten, unabhängig davon, wie oft die Signatur tatsächlich trifft. Der Typ „both" kombiniert beides, und „backoff" verlängert den Abstand zwischen Alarmen exponentiell, solange derselbe Treffer anhält.

Zur Feinsteuerung kommt die Frage hinzu, wie gezählt wird: nach Quell-IP (by_src), Ziel-IP (by_dst), dem Paar aus beiden (by_both), der einzelnen Signatur (by_rule) oder dem konkreten Datenfluss (by_flow). Ein Portscan aus einer einzelnen Quelladresse lässt sich damit anders dämpfen als derselbe Scan, verteilt über viele Quellen — letzteres ist tendenziell das interessantere Muster, nicht das zu unterdrückende.

# Beispielsyntax aus der Suricata-Dokumentation
threshold gen_id 1, sig_id 2010935, type threshold, track by_src, count 10, seconds 60
threshold gen_id 1, sig_id 2010935, type limit,     track by_src, count 1,  seconds 180

Wer diese Schwellenwerte nie anfasst, lebt mit der Standardeinstellung jeder einzelnen Signatur — manche sind bewusst empfindlich eingestellt, weil ihr Hersteller lieber einen Fehlalarm zu viel als einen Angriff zu wenig meldet. Genau dafür lohnt sich die Pflege als eigene Aufgabe, nicht als Nebenprodukt der Ersteinrichtung.

/08Wo es hakt

Vier Punkte, die vor dem produktiven Rollout auf den Tisch gehören.

Inline-IPS kann die eigene Geschäftsanwendung treffen

Wie in Abschnitt 06 beschrieben, ist ein False Positive im Inline-Modus kein harmloser Protokolleintrag, sondern eine verworfene Verbindung. Branchenspezifische Anwendungen mit ungewöhnlichen Protokollmustern — etwa Maschinensteuerungen oder ältere ERP-Schnittstellen — lösen hier überdurchschnittlich oft Fehlalarme aus, weil die mitgelieferten Signaturen für gängigen Unternehmensverkehr geschrieben sind, nicht für Nischenprotokolle. Ein geblockter Geschäftsprozess braucht dann dieselbe schnelle Vorfallsreaktion wie ein echter Sicherheitsvorfall — nur dass die Ursache in diesem Fall die eigene Schutzmaßnahme ist.

Durchsatzverlust ist real, nicht nur theoretisch

Jede zusätzlich aktivierte Regelgruppe im Inline-Pfad erhöht die Prüflast je Paket. Auf unterdimensionierter Hardware zeigt sich das zuerst bei Lastspitzen — nicht im Alltag, sondern genau dann, wenn die Bandbreite ohnehin gebraucht wird. Eine Kapazitätsplanung, die den Inline-Betrieb erst nach der Anschaffung der Firewall mitdenkt, kommt regelmäßig zu spät.

Split-Brain bei unsauberer Netzinfrastruktur

Wie in Abschnitt 03 beschrieben, braucht CARP eine einheitliche Switch-Fabric. Zwei unabhängige, nicht gekoppelte Switches sind kein Hochverfügbarkeitsgewinn, sondern ein zusätzliches Ausfallszenario: Beide Firewalls halten sich im Zweifel gleichzeitig für aktiv, mit widersprüchlichen Zustandstabellen.

VLANs sind kein Ersatz für Rechtevergabe

Ein Gastnetz in einem eigenen VLAN ist vom Produktionsnetz getrennt — das verhindert aber nicht, dass ein kompromittiertes Gerät innerhalb desselben VLANs andere Geräte im selben Segment erreicht. Segmentierung schützt zwischen Netzen, nicht automatisch innerhalb eines Netzes; dafür braucht es zusätzlich Regeln auf Geräte- oder Portebene.

/09Wann sich der Aufwand lohnt — und wann nicht

Keiner der drei Bausteine ist für jede Umgebung die richtige Priorität. Die Entscheidung hängt an der Kritikalität der Anbindung und an der tatsächlich vorhandenen Betriebskapazität.

Dafür spricht

• Geschäftskritische Internetanbindung ohne Ausfallfenster: Ein HA-Paar mit CARP verhindert, dass ein einzelner Hardwaredefekt den gesamten Netzzugang mitreißt.
• Mehrere Nutzergruppen mit unterschiedlichem Vertrauensniveau: Gäste, Produktionsnetz, Verwaltung und Dienstleisterzugänge gehören in getrennte VLANs, sobald mehr als eine Gruppe regelmäßig im Netz ist.
• Erkennbarer Bedarf an Sichtbarkeit in den Datenverkehr: Wer wissen will, was durch erlaubte Verbindungen tatsächlich läuft, kommt am überwachenden Suricata-Betrieb kaum vorbei.

Dagegen spricht

• Sehr kleine, einfache Umgebungen ohne eigene Betriebskapazität: Ein HA-Paar, das nach der Einrichtung nie wieder geprüft wird, ist am Ende schlechter als eine einzelne, sauber gepflegte Firewall.
• Inline-IPS auf nicht ausreichend dimensionierter Hardware: Wer den Durchsatzverlust aus Abschnitt 08 nicht einplant, riskiert mehr Ausfälle durch die Schutzmaßnahme als durch das, wovor sie schützen soll.
• Netzinfrastruktur, die eine saubere Switch-Kopplung nicht hergibt: CARP auf getrennten, nicht synchronisierten Switches schafft ein neues Risiko, statt eines zu beseitigen.

Unsere Praxis-Linie: HA zuerst, weil ein Ausfall die Internetanbindung komplett nimmt; VLAN-Segmentierung als Nächstes, weil sie den Schaden eines kompromittierten Geräts begrenzt; Suricata zunächst überwachend, der Inline-Betrieb erst für sorgfältig geprüfte Regelgruppen und ausreichend dimensionierte Hardware.

/10Häufige Fragen