OPNsense HA mit CARP: 3 Fallstricke aus der Praxis

OPNsense-HA mit CARP ist auf dem Papier ein Fünf-Minuten-Setup: zwei identische Appliances, ein WAN-VIP, ein LAN-VIP, ein dediziertes pfSync-Interface, XMLRPC-Sync aktiviert — und der Cluster läuft. In der Praxis sehen wir bei Übernahmen von Bestandsinstallationen jedoch immer wieder dieselben drei Baustellen, die den Failover entweder still verhindern oder im Ernstfall zu Teilausfällen führen. Dieser Beitrag beschreibt die Fallstricke, die wir in unseren Kundenprojekten am häufigsten aufräumen — und wie Sie sie mit überschaubarem Aufwand dauerhaft eliminieren.

Wir gehen davon aus, dass Sie ein klassisches Aktiv/Passiv-Setup mit OPNsense 25.7 oder 26.1 auf zwei Hardware-Appliances (typisch: DEC750, DEC2685 oder generische x86-Boxen mit i226-NICs) betreiben. Der Sync-Link ist ein dediziertes 1G- oder 10G-Interface, VIPs sind pro Subnetz konfiguriert, und High Availability Sync ist unter System > High Availability > Settings aktiv.

Fallstrick 1: Schleichender Config-Drift zwischen Master und Backup

Die XMLRPC-Synchronisation in OPNsense synchronisiert eine ausgewählte Liste von Bereichen — Firewall-Regeln, Aliase, NAT, DHCP-Reservierungen, IPsec, OpenVPN, Users, Certificates. Was sie nicht synchronisiert, ist ebenso wichtig: Interface-Zuordnungen, VLAN-Definitionen, physische Adressen, Gateway-Definitionen, Suricata-Regelwerke (nur teils), Netflow, Systemtunables, Package-Installationen und in vielen Fällen auch die Reihenfolge von Firewall-Kategorien.

In der Praxis bedeutet das: sobald ein Administrator “nur kurz” auf dem Master ein VLAN hinzufügt, ein Interface umlabelt oder ein Plugin installiert, ohne dieselben Schritte auf dem Backup nachzuziehen, entsteht ein Drift, der erst beim Failover sichtbar wird — und dann typischerweise als “Warum funktioniert VLAN 47 nicht mehr?” im Ticketsystem landet.

Unser Vorgehen dagegen ist zweigleisig. Erstens ein monatlicher, automatisierter Config-Diff: die Datei /conf/config.xml beider Nodes wird per SSH abgezogen, an definierten Stellen anonymisiert (Timestamps, RRD-Daten, CARP-Passwörter) und mit diff verglichen. Jede Zeile, die kein reines HA-Delta ist, ist ein Findung.

#!/bin/sh
# carp-drift-check.sh -- Vergleich Master vs Backup
MASTER=fw01.intern.example.de
BACKUP=fw02.intern.example.de
TMPDIR=$(mktemp -d)

for HOST in $MASTER $BACKUP; do
  ssh root@$HOST 'cat /conf/config.xml' \
    | sed -E 's/<time>[0-9]+<\/time>//g' \
    | sed -E 's/<lastchange>[0-9]+<\/lastchange>//g' \
    > "$TMPDIR/$(basename $HOST).xml"
done

diff -u "$TMPDIR/$MASTER.xml" "$TMPDIR/$BACKUP.xml" \
  | grep -vE '^(---|\+\+\+|@@|.*carp_.*password)' \
  > /var/log/carp-drift.log

test -s /var/log/carp-drift.log && \
  mail -s "CARP-Drift auf $MASTER/$BACKUP" ops@example.de < /var/log/carp-drift.log

Zweitens: Interface- und VLAN-Änderungen laufen bei uns immer manuell auf beiden Nodes, in derselben Reihenfolge, mit dem Backup zuerst. So bleibt der Master im Failover-Fall garantiert lauffähig, selbst wenn die Änderung auf dem Backup fehlschlägt.

Fallstrick 2: Sync-Interface unter Last — wenn pfSync die eigene HA sabotiert

pfSync repliziert die State-Table zwischen den Nodes in Echtzeit. Bei einem SMB-Cluster mit 20.000 aktiven States ist das völlig unauffällig. Bei einem Cluster, der 500.000 States hält — typisch bei Terminalserver-Farmen, VoIP-Trunks mit vielen parallelen RTP-Streams oder Backup-Windows mit vielen kleinen SMB-Sessions — kann die Sync-Verbindung zum Flaschenhals werden.

Konkret sehen wir zwei Symptome: erstens sporadische “pfsync: requesting bulk update” im Log, weil der Backup-Node den Anschluss verliert; zweitens im Failover-Fall kurze Reset-Wellen, weil die State-Table beim übernehmenden Node unvollständig war.

Die Ursachen sind fast immer eine der folgenden:

Ursache	Symptom	Fix
Sync-Link über Shared Switch mit VLAN	Latenz-Spikes, Bulk-Updates	Direktes Kabel Node-zu-Node, keine Zwischenswitches
1G-Sync-Interface, >250k States	pfsync-Queue läuft voll	Auf 10G umrüsten oder LACP zweier 1G-Links
MTU-Mismatch (1500 vs 9000)	Bulk-Update bricht ab	Beide Sync-Interfaces auf 1500 oder beide auf 9000
Firewall-Regel blockt pfsync	Backup zeigt “SYNC” statt “MASTER” nach Failover	pfSync-Interface auf “any/any allow” oder Regel explizit auf Protokoll 240

Als Faustregel aus unseren Projekten: für alles über 100.000 States empfehlen wir dediziertes 10G-Sync, direkt verkabelt, mit MTU 9000 auf beiden Seiten. Die Konfiguration erfolgt unter Interfaces > [SYNC] > MTU — und, wichtig, auch auf dem physischen NIC-Treiber via System > Settings > Tunables, falls der Treiber die MTU nicht dynamisch übernimmt.

Für Monitoring hat sich ein simpler Zabbix- oder Checkmk-Check bewährt, der auf beiden Nodes pfctl -s states | wc -l und die pfsync-Queue-Tiefe abfragt. Überschreitet die Queue mehr als 500 Einträge über länger als 30 Sekunden, ist die Sync-Kapazität erschöpft.

Fallstrick 3: DHCP-Failover, das gar keiner ist

Der am häufigsten übersehene Punkt: viele Bestandscluster laufen mit isc-dhcp (oder inzwischen Dnsmasq bzw. Kea) im “Sync”-Modus, aber ohne echten DHCP-Failover-Peer. Das bedeutet: Leases werden über XMLRPC vom Master zum Backup gepushed, aber der Backup vergibt selbst keine neuen Leases. Bei einem Master-Ausfall bekommen neu angeschlossene Geräte keine IP — vorhandene Sessions laufen weiter, alles Neue steht.

Ab OPNsense 25.7 ist Kea DHCP der empfohlene Server, und Kea unterstützt echten HA-Modus (Hot-Standby oder Load-Balancing). Unser Standard-Setup für neue Cluster:

# Kea HA-Konfiguration, konzeptionell
ha:
  mode: hot-standby
  peers:
    - name: fw01
      url: https://10.99.0.1:8000/
      role: primary
    - name: fw02
      url: https://10.99.0.2:8000/
      role: standby
  heartbeat-delay: 10000
  max-response-delay: 60000

In der OPNsense-GUI konfigurieren Sie das unter Services > Kea DHCP > [Subnetz] > High Availability. Wichtig: das Kea-Control-Interface muss auf dem Sync-Link erreichbar sein, nicht über die VIP. Sonst läuft die HA-Kommunikation selbst über das Netz, das im Failover-Fall gerade wechselt — ein klassischer Split-Brain-Auslöser.

Für Cluster, die noch auf ISC-DHCP laufen, empfehlen wir die Migration auf Kea im nächsten Wartungsfenster. ISC-DHCP ist upstream EOL und OPNsense wird die Unterstützung mittelfristig entfernen.

Health-Checks, die wirklich etwas aussagen

Ein CARP-Status “MASTER” auf einem Node sagt noch nichts darüber, ob der Cluster im Ernstfall funktioniert. Unsere Minimal-Checkliste für den monatlichen HA-Test:

1. Simulierter Failover per CLI: pfctl -k auf dem Master, plus configctl carp maintenance on. Der Backup übernimmt binnen 3 Sekunden alle VIPs. Neue TCP-Verbindungen kommen durch, DHCP vergibt neue Leases, IPsec-Tunnel bauen sich neu auf.
2. State-Sync-Verifikation: vor dem Failover State-Count auf beiden Nodes vergleichen — der Backup sollte innerhalb von 5% des Masters liegen.
3. Config-Drift-Report: das Skript aus Fallstrick 1 läuft und meldet null Diffs (außer HA-eigene Felder).
4. DHCP-Failover-Test: neuen Client anschließen während der Master in Maintenance ist; Client bekommt eine Lease.
5. DNS-Resolver-Test: Unbound auf dem Backup antwortet mit denselben Overrides wie der Master.

Wer diese fünf Punkte quartalsweise durchspielt, findet 90% aller HA-Fehler, bevor sie produktionsrelevant werden.

Fazit

OPNsense-HA mit CARP ist stabil, wenn die drei Grundlagen sitzen: identische Konfiguration auf beiden Nodes, dimensionierter Sync-Link und ein DHCP-Server im echten HA-Modus. Die häufigsten Ausfälle, die wir übernehmen, gehen nicht auf Bugs in OPNsense zurück, sondern auf Setups, die einmal aufgesetzt und nie wieder angefasst wurden. Ein monatlicher Config-Diff und ein quartalsweiser Failover-Test sind der Unterschied zwischen einem Cluster, der Ihnen Ausfallzeit spart, und einem, der sie im Ernstfall verdoppelt.

DATAZONE unterstützt Sie beim Design, der Migration und dem Betrieb von OPNsense-HA-Clustern — von der Hardware-Auswahl über die OPNsense-Beratung bis zum langfristigen Monitoring. Wenn Sie einen Bestandscluster übernehmen oder neu aufsetzen wollen, sprechen Sie uns an: Kontakt aufnehmen.