Ein Firewall-Ausfall ist selten „nur“ ein Ausfall. Oft hängt gleich alles dran: Internet, VPN, VoIP, Standortkopplung, Zugriff auf Cloud-Dienste. Wer OPNsense produktiv einsetzt, will daher meist zwei Dinge: planbare Wartungsfenster und ein Failover, das ohne hektische DNS-Umschaltungen oder manuelle Eingriffe funktioniert.
In diesem Beitrag zeige ich einen praxistauglichen Aufbau, um einen OPNsense HA-Cluster (High Availablility/HA) mit CARP aufzusetzen: mit dediziertem Sync-Interface, sauberer Regelbasis für CARP, virtuellen IPs auf WAN und LAN, passendem Outbound NAT und dem häufig vergessenen Punkt „Failover-IP im DHCP“.
Zielbild: Was ein OPNsense HA-Cluster leistet
Ein HA-Setup ersetzt nicht jedes Designproblem, aber es löst ein sehr konkretes: Fällt die aktive Firewall aus oder wird neu gestartet, übernimmt die zweite Instanz die virtuelle IP (CARP-VIP) und kann – wenn State-Sync sauber läuft – bestehende Verbindungen weitgehend weiterführen.
Für den Alltag sind drei Bereiche entscheidend:
- Datenpfad (VIPs): Clients und Upstream kennen nur die virtuellen IPs, nicht die realen Node-IPs.
- Zustandsdaten (pfsync): Damit Verbindungen beim Failover nicht „hart“ abbrechen.
- Konfiguration (XMLRPC-Sync): Damit Regeln, NAT, DHCP etc. konsistent bleiben.
Voraussetzungen, die in der Praxis wirklich zählen
Gleiche Netze, klare Rollen, gleiche Features
Beide OPNsense-Nodes sollten:
- im selben Layer-2 pro Interface hängen (LAN <-> LAN, WAN <-> WAN),
- dieselben Interface-Namen/Zuordnungen haben,
- dieselben Plugins/Features nutzen (sonst driftet die Konfiguration).
Wenn Sie virtualisiert arbeiten: Stellen Sie sicher, dass VLANs/Trunks und Promisc/Multicast sauber funktionieren. CARP nutzt Multicast (224.0.0.18), und „halb kaputte“ vSwitch-Einstellungen sind eine typische Fehlerquelle.
Dediziertes CARP-/Sync-Interface direkt verkabeln
Aus dem Feldbetrieb: Der stabilste Ansatz ist ein dediziertes Sync-Interface, idealerweise direkt zwischen den beiden Firewalls verkabelt (1G reicht, 10G schadet nicht). Darüber laufen:
- pfsync (State-Sync)
- optional Management/Sync-Kommunikation (je nach Sicherheitsmodell)
Vorteile: Sie entlasten LAN/WAN, vermeiden Latenzspitzen und reduzieren die Angriffsfläche.
HA-Modus aktivieren und konfigurieren
Der High Availability Modus wird in OPNsense unter „System → High Availability → Settings“ aktiviert. Hier legen Sie fest, wie die beiden Nodes miteinander kommunizieren und synchronisieren. Diese Einstellung dürfen Sie nur auf der Master Node durchführen, das Backup Node wird nicht konfiguriert!
Einstellungen unter High Availability:
- Synchronize all states via CARP <- Auswählen
- Synchronisationsinterface: Wählen Sie das dedizierte Sync-Interface, über das der State- und Config-Sync (pfsync und XMLRPC) läuft. Idealerweise das direkt verbundene Sync-Netz.
- Peer IP: Hier können Sie die Multicast IP 224.0.0.240 lassen wenn Sie ein dediziertes Interface verwenden.
- Remote System Username: Ein Benutzer mit Admin Rechten auf beiden Systemen.
- Remote System Password: Das Passwort des Benutzers mit Admin Rechten auf beiden Systemen.
- Weitere Optionen wie Zeitüberschreitungen oder Retry-Verhalten kann man je nach Bedarf anpassen.
- Services hier kann Select All ausgewählt werden
CARP richtig anlegen: virtuelle IPs auf LAN und WAN
Reale IPs vs. virtuelle IPs
Planen Sie pro Segment immer drei Adressen:
- Node A: reale IP (z. B. LAN 192.168.10.11)
- Node B: reale IP (z. B. LAN 192.168.10.12)
- CARP-VIP: virtuelle IP (z. B. LAN 192.168.10.1)
Gleiches Prinzip auf WAN: Auch dort bekommt die Umgebung eine VIP, die Ihr Upstream-Router oder Ihr Provider als „die Firewall“ sieht.
CARP-VIPs anlegen (WAN & LAN)
In OPNsense legen Sie CARP-VIPs unter den virtuellen IPs auf allen OPNsense Firewalls an. Achten Sie dabei auf:
- VHID eindeutig pro Broadcast-Domain
- Passwort identisch auf beiden Nodes
- Advertising base/skew so setzen, dass Node A primär wird (kleineres skew), Node B sekundär
Praxis-Tipp: Benennen Sie VIPs eindeutig, z. B. VIP_LAN, VIP_WAN. Später bei NAT/Regeln sparen Sie Zeit.
Firewall-Regeln: CARP-Verkehr explizit erlauben
Ein Punkt, der gerne übersehen wird: Wenn Sie ein dediziertes CARP/pfsync-Sync-Interface verwenden, braucht es dort passende Regeln.
CARP erlauben
CARP nutzt IP-Protokoll 112. Auf dem Sync-Interface sollte mindestens zwischen den Node-IPs erlaubt sein:
- Quelle: Node A Sync-IP
- Ziel: Node B Sync-IP
- Protokoll: CARP (bzw. IP Proto 112)
pfsync erlauben
State-Sync läuft über pfsync (eigenes Protokoll). Auch das muss auf dem Sync-Interface zwischen den Nodes erlaubt sein.
Am einfachsten ist es jedoch den Traffic auf dem Interface vollständig zu erlauben, da dort außer für die Synchronisation kein weiterer Traffic geroutet wird.
Outbound NAT: für virtuelle IPs bewusst setzen
Sobald Sie eine WAN-VIP nutzen, müssen Sie sich um NAT Gedanken machen. Viele Installationen laufen im „Automatic outbound NAT“ und funktionieren zunächst scheinbar. Im HA-Betrieb kann das aber schiefgehen, wenn Regeln an der falschen Source-IP hängen.
Mein Standardansatz:
- Wechsel auf Manual outbound NAT.
- Erstellen Sie NAT-Regeln, die als Übersetzungsadresse die WAN-CARP-VIP nutzen.
Warum? Damit ausgehender Traffic stets mit der virtuellen WAN-Adresse kommt, unabhängig davon, welcher Node gerade aktiv ist.
Beispiel (sinngemäß, je nach UI-Feldnamen):
- Interface: WAN
- Source: LAN-Netze (z. B. 192.168.10.0/24)
- Translation / Address:
VIP_WAN
Wenn Sie mehrere öffentliche IPs haben (z. B. für 1:1 NAT oder Services): Legen Sie diese als zusätzliche VIPs an und bauen Sie NAT-Regeln bewusst darum.
Konfig-Sync: Cronjob für regelmäßigen HA-Sync
OPNsense synchronisiert Konfigurationen typischerweise per XMLRPC-Sync (Master -> Backup). In der Praxis klappt das gut, trotzdem sehe ich zwei wiederkehrende Probleme:
- Änderungen werden „vergessen“, weil Sync nicht sauber eingerichtet wurde.
- Anpassungen erfolgen auf dem falschen Node.
Ein Cronjob für regelmäßigen HA Sync kann als Sicherheitsnetz dienen, wenn Sie in Ihrer Umgebung öfter Änderungen haben oder mehrere Admins arbeiten. Er ersetzt keine saubere Betriebsdisziplin, aber er reduziert Drift.
Wichtig dabei:
- Synchronisieren Sie nur von der vorgesehenen Master-Instanz.
- Übernehmen Sie nicht blind alles (z. B. Schnittstellenzustände), wenn Ihre Umgebung Besonderheiten hat.
Wenn Sie ohnehin Monitoring einsetzen: Überwachen Sie auch den HA-Status und die CARP-Rollen. Passend dazu kann unser Beitrag zur Überwachung hilfreich sein, z. B. über ein Plugin: Checkmk-Plugin zur Überwachung von OPNsense installieren.
DHCP im HA-Betrieb: Gateway-IP im DHCP hinterlegen
Der Klassiker: OPNsense HA-Cluster ist eingerichtet, Failover klappt, aber Clients verlieren trotzdem die Verbindung. Ursache ist oft nicht CARP selbst, sondern das Default-Gateway in den Clients.
Wenn Clients per DHCP ihre Gateway-IP bekommen, muss dort die LAN-CARP-VIP eingetragen sein, nicht die reale Node-IP.
- DHCP „Router/Gateway“ =
VIP_LAN
Das gilt sinngemäß auch für DNS-Server-Adressen, wenn Sie interne Resolver über die Firewall anbieten.
Testplan: so prüfen Sie, ob der Cluster wirklich trägt
Testen Sie strukturiert, sonst erhalten Sie ein „es scheint zu gehen“, das im Ernstfall nicht trägt:
- CARP-Rollen prüfen: Node A = MASTER, Node B = BACKUP (auf LAN/WAN-VIP).
- Failover erzwingen: CARP auf Master deaktivieren oder Interface kurz trennen.
- Session-Test: Während eines Downloads oder VPN-Pings failovern. Beobachten, ob Verbindungen überleben (pfsync).
- NAT-Check: Externe Dienste prüfen (Portweiterleitungen, Outbound). Kommt der Traffic von der WAN-VIP?
- DHCP-Clients: Ein Client renewen lassen und Gateway/DNS prüfen.
Wenn Sie zusätzlich Dienste wie Reverse Proxy/Load Balancing auf OPNsense nutzen, müssen diese Komponenten in den Test rein. Für HAProxy-Setups finden Sie bei uns eine passende Schrittfolge: HAProxy auf OPNsense Schritt für Schritt.
Typische Stolpersteine aus Admin-Sicht
Asymmetrisches Routing und „falsche“ Rückwege
Im HA-Betrieb fällt asymmetrisches Routing schneller auf. Wenn Rückverkehr über den passiven Node läuft, während der aktive Node die VIP hält, wirken Sessions „instabil“. Prüfen Sie Upstream-Routen, Policy Based Routing und Multi-WAN-Konstrukte besonders sorgfältig.
State-Sync zu „groß“ oder zu „klein“
Wenn pfsync über ein belastetes Netz läuft, verschlechtert sich das Failover-Verhalten. Darum lohnt sich das dedizierte Sync-Interface. Umgekehrt: Wenn pfsync zu restriktiv gefiltert wird, sehen Sie zwar CARP-Failover, aber keine sauberen Sessions.
Monitoring fehlt
Ein HA-Cluster, den niemand beobachtet, fällt gern erst beim echten Ausfall auf. Neben VIP-Status gehören auch Paketverlust/Latency auf dem Sync-Link und Interface-Fehler in die Überwachung. Wenn Sie Checkmk einsetzen, ist auch unser Beitrag zur direkten OPNsense-Überwachung eine gute Ergänzung: OPNsense mit Checkmk überwachen.
Wer den Aufbau eines OPNsense HA / High Availablility Cluster nicht nur „zum Laufen“ bringen will, sondern sauber dokumentiert und testbar betreiben möchte, findet weitere praxisnahe Artikel im ADMIN INTELLIGENCE Blog unter https://blog.admin-intelligence.de/. Wenn Sie beim Design (VIP-Plan, NAT, Multi-WAN, VLAN) oder bei der Umsetzung im Rechenzentrum Unterstützung brauchen, erreichen Sie uns direkt über https://www.admin-intelligence.de/kontakt/ – oder schauen Sie sich unsere OPNsense-Leistungen an: https://www.admin-intelligence.de/opnsense/.
