OPNsense HA mit CARP: 3 Fallstricke aus der Praxis

OPNsense-HA mit CARP ist auf dem Papier ein Fuenf-Minuten-Setup: zwei identische Appliances, ein WAN-VIP, ein LAN-VIP, ein dediziertes pfSync-Interface, XMLRPC-Sync aktiviert — und der Cluster laeuft. In der Praxis sehen wir bei Uebernahmen von Bestandsinstallationen jedoch immer wieder dieselben drei Baustellen, die den Failover entweder still verhindern oder im Ernstfall zu Teilausfaellen fuehren. Dieser Beitrag beschreibt die Fallstricke, die wir in unseren Kundenprojekten am haeufigsten aufraeumen — und wie Sie sie mit ueberschaubarem 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 ausgewaehlte 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 Faellen auch die Reihenfolge von Firewall-Kategorien.

In der Praxis bedeutet das: sobald ein Administrator “nur kurz” auf dem Master ein VLAN hinzufuegt, 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-Passwoerter) 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-Aenderungen laufen bei uns immer manuell auf beiden Nodes, in derselben Reihenfolge, mit dem Backup zuerst. So bleibt der Master im Failover-Fall garantiert lauffaehig, selbst wenn die Aenderung auf dem Backup fehlschlaegt.

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 voellig unauffaellig. Bei einem Cluster, der 500.000 States haelt — 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 uebernehmenden Node unvollstaendig war.

Die Ursachen sind fast immer eine der folgenden:

Ursache	Symptom	Fix
Sync-Link ueber Shared Switch mit VLAN	Latenz-Spikes, Bulk-Updates	Direktes Kabel Node-zu-Node, keine Zwischenswitches
1G-Sync-Interface, >250k States	pfsync-Queue laeuft voll	Auf 10G umruesten 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: fuer alles ueber 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 uebernimmt.

Fuer Monitoring hat sich ein simpler Zabbix- oder Checkmk-Check bewaehrt, der auf beiden Nodes pfctl -s states | wc -l und die pfsync-Queue-Tiefe abfragt. Ueberschreitet die Queue mehr als 500 Eintraege ueber laenger als 30 Sekunden, ist die Sync-Kapazitaet erschoepft.

Fallstrick 3: DHCP-Failover, das gar keiner ist

Der am haeufigsten uebersehene 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 ueber XMLRPC vom Master zum Backup gepushed, aber der Backup vergibt selbst keine neuen Leases. Bei einem Master-Ausfall bekommen neu angeschlossene Geraete keine IP — vorhandene Sessions laufen weiter, alles Neue steht.

Ab OPNsense 25.7 ist Kea DHCP der empfohlene Server, und Kea unterstuetzt echten HA-Modus (Hot-Standby oder Load-Balancing). Unser Standard-Setup fuer 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 ueber die VIP. Sonst laeuft die HA-Kommunikation selbst ueber das Netz, das im Failover-Fall gerade wechselt — ein klassischer Split-Brain-Ausloeser.

Fuer Cluster, die noch auf ISC-DHCP laufen, empfehlen wir die Migration auf Kea im naechsten Wartungsfenster. ISC-DHCP ist upstream EOL und OPNsense wird die Unterstuetzung mittelfristig entfernen.

Health-Checks, die wirklich etwas aussagen

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

1. Simulierter Failover per CLI: pfctl -k auf dem Master, plus configctl carp maintenance on. Der Backup uebernimmt 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 laeuft und meldet null Diffs (ausser HA-eigene Felder).
4. DHCP-Failover-Test: neuen Client anschliessen waehrend 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 fuenf 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 haeufigsten Ausfaelle, die wir uebernehmen, gehen nicht auf Bugs in OPNsense zurueck, 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 unterstuetzt Sie beim Design, der Migration und dem Betrieb von OPNsense-HA-Clustern — von der Hardware-Auswahl ueber die OPNsense-Beratung bis zum langfristigen Monitoring. Wenn Sie einen Bestandscluster uebernehmen oder neu aufsetzen wollen, sprechen Sie uns an: Kontakt aufnehmen.