# OPNsense HA-Cluster: Architektur für Null-Downtime

TL;DR / Management Summary Ein High Availability (HA) Cluster ist die Versicherungspolice für das Netzwerk. Wir koppeln zwei identische OPNsense-Instanzen zu einem Verbund. Durch den Einsatz von CARP für virtuelle IP-Adressen und XMLRPC zur Konfigurations-Synchronisation stellen wir sicher, dass bei einem Hardware-Defekt oder Update der Backup-Knoten die Arbeit innerhalb von 1-3 Sekunden übernimmt. Ein Senior Admin betreibt HA-Cluster bevorzugt auf getrennten physischen Proxmox-Knoten, um auch Hypervisor-Ausfälle abzufedern.

# 1. Einführung & Topologie

Redundanz auf allen Ebenen.

Ein OPNsense-Cluster benötigt mindestens drei Netzwerkpfade:

1. WAN-Trunk: Gemeinsame Verbindung zum Internet.
2. LAN-Trunk: Gemeinsame Verbindung zum internen Netz.
3. SYNC-Link: Dedizierte Direktverbindung für den Datenabgleich.

# Die Architektur-Komponenten

• CARP: Teilt die VIP (Virtual IP) zwischen den Knoten.
• configd (XMLRPC): Spiegelt Firewall-Regeln, Aliase und Einstellungen vom Master auf den Backup.
• pfsync: Spiegelt die State-Tabelle (aktive Verbindungen).

# 2. Einrichtung in der Praxis

Der Weg zum stabilen Paar.

# Schritt 1: Das Sync-Interface (Der wichtigste Schritt)

Weisen Sie ein physisches Interface (z.B. igb2 / vtnet2) als Sync-Port zu. Geben Sie ihm eine IP aus einem kleinen Netz (z.B. 172.16.1.1/30 und 172.16.1.2/30).

# Schritt 2: CARP VIPs anlegen

Interfaces -> Virtual IPs -> Settings. Erstellen Sie für jedes Netz (WAN, LAN, VLANs) eine CARP-IP.

• VHID: Muss pro IP-Paar eindeutig sein.
• Password: Muss auf beiden Knoten identisch sein.

# Schritt 3: Synchronisation aktivieren

System -> High Availability -> Settings.

1. Synchronize Config to IP: Die Sync-IP des Backups eingeben.
2. Remote System Username: root.
3. Checkboxen: Wählen Sie alle Bereiche aus, die gespiegelt werden sollen (Regeln, DHCP, VPN, etc.).

# 3. Deep Dive: State-Synchronisation (pfsync)

Nahtlose Übergabe.

Ohne pfsync würden beim Failover alle Verbindungen (Downloads, VPN, SSH) abbrechen.

• Setup: Aktivieren Sie pfsync unter System -> High Availability -> Settings.
• Sicherheit: Da pfsync-Daten unverschlüsselt fließen, muss der Sync-Link physisch isoliert oder via IPsec/VLAN geschützt sein.

# 4. Day-2 Operations: Update-Strategie

Wartung ohne Schmerz.

1. Schalten Sie den Master in den Maintenance Mode (Interfaces -> Diagnostics -> CARP Status).
2. Prüfen Sie, ob der Traffic nun über den Backup fließt.
3. Updaten Sie den Master. Nach dem Reboot und erfolgreichem Test schalten Sie den Maintenance Mode am Master wieder aus.
4. Wiederholen Sie den Vorgang für den Backup-Knoten.

# 5. Troubleshooting & “War Stories”

Wenn der Cluster flappt.

# Top 3 Fehlerbilder

1. Symptom: “Master-Master” Zustand (beide Knoten denken, sie seien aktiv).

   • Ursache: Das Sync-Kabel ist defekt oder ein Switch blockiert die Multicast-Pakete (CARP Port 112).
   • Lösung: tcpdump -i [sync_interface] vrrp prüfen.

2. Symptom: Sync-Fehler im Log.

   • Ursache: SSH-Key Mismatch oder Plugin-Versionsunterschiede.
   • Lösung: Passwort-Login für root via Sync-IP temporär erlauben oder Keys neu verteilen.

3. Symptom: Hohe CPU Last auf dem Backup-Knoten.

   • Ursache: pfsync überträgt zu viele State-Änderungen (z.B. durch DNS-Traffic).
   • Fix: DNS-Traffic vom State-Logging ausnehmen oder Sync-Bandbreite erhöhen.

# “War Story”: Der “Auto-Update” Albtraum

Ein Admin aktivierte automatische Updates auf beiden Cluster-Knoten gleichzeitig. Das Ergebnis: Beide Knoten rebooteten zur gleichen Zeit um 3 Uhr morgens. Da kein Gerät mehr aktiv war, um die VIP zu halten, war das gesamte Netzwerk für 5 Minuten tot – inklusive der Verbindung zum Update-Server. Ein Knoten hing sich beim Booten auf, und das Netzwerk blieb bis zum Morgen offline. Lehre: Automatisieren Sie Cluster-Updates niemals gleichzeitig. Nutzen Sie die serielle Logik des CARP-Maintenance-Modes.

# 6. Monitoring & Reporting

Cluster-Health im Blick.

# Dashboard Widgets

Platzieren Sie das Widget “CARP Status” und “High Availability Sync” auf beiden Knoten.

• KPI: Master auf Node 1, Backup auf Node 2. OK beim XMLRPC Sync.

# 7. Fazit & Empfehlung

Ein OPNsense HA-Cluster ist das Fundament für Enterprise-Infrastrukturen.

• Empfehlung: Betreiben Sie HA-Cluster immer auf identischer Hardware.
• Hardware: Nutzen Sie für den Sync-Link 10G Interfaces, wenn Sie hohe State-Churn-Raten (viele kleine Verbindungen) haben.

# Anhang: Cheatsheet

# Referenzen

• OPNsense Docs: High Availability Documentation
• PfSense/OPNsense: Common CARP Problems
• RFC 3768: Virtual Router Redundancy Protocol (VRRP) (Basis für CARP)