imported>TechCorner-Redaktion: Neuer Artikel: HA-Cluster mit CARP, pfsync und Konfigurationssynchronisation, Stand OPNsense 26.7

2026-10-08T00:00:00Z

Neuer Artikel: HA-Cluster mit CARP, pfsync und Konfigurationssynchronisation, Stand OPNsense 26.7

Neue Seite

{{Steckbrief
| gilt_fuer = OPNsense 26.1 und 26.7 (Interfaces → Virtual IPs, System → High Availability)
| bereich = IT-Security
| dauer = ca. 60–90 Minuten (Cluster aus zwei Firewalls mit WAN und LAN)
| rechte = Administrator (OPNsense-WebUI) auf beiden Firewalls, Zugriff auf die Switch-Konfiguration
| stand = Oktober 2026 (OPNsense 26.7.5)
}}
'''Hochverfügbarkeit mit CARP in OPNsense''' macht aus zwei Firewalls einen ausfallsicheren [[Cluster]]: Fällt die aktive Firewall (Master) aus oder verliert sie eine Schnittstelle, übernimmt die zweite (Backup) automatisch die gemeinsamen virtuellen IP-Adressen – bestehende Verbindungen laufen dank '''pfsync''' weiter. Drei Bausteine greifen dabei ineinander: '''CARP''' für die virtuellen Adressen, '''pfsync''' für die Zustandstabelle der Firewall und die '''Konfigurationssynchronisation''' (XMLRPC) vom Master zum Backup.

Dieser Artikel zeigt Aufbau und Einrichtung eines Active/Passive-Clusters mit OPNsense 26.7, die Anforderungen an das Netzwerk, die Integration weiterer Dienste (DHCP, VPN, Routing), Wartung und Updates ohne Ausfall sowie die Fehlersuche bei Split-Brain und Co.

== Bausteine der OPNsense-Hochverfügbarkeit ==
{| class="wikitable"
! Baustein !! Aufgabe !! Konfiguration
|-
| '''CARP''' (Common Address Redundancy Protocol) || Virtuelle IP-Adressen, die immer auf der aktiven Firewall liegen. Der Master sendet Ankündigungen (IP-Protokoll 112, standardmäßig Multicast); bleiben sie aus, übernimmt der Backup. Vergleichbar mit [[VRRP]]. || ''Interfaces → Virtual IPs''
|-
| '''pfsync''' || Repliziert die Zustandstabelle (States) der Firewall, damit bestehende Verbindungen den Wechsel überstehen || ''System → High Availability → Settings''
|-
| '''Konfigurationssynchronisation''' (XMLRPC) || Überträgt ausgewählte Konfigurationsbereiche (Regeln, NAT, Aliase, VIPs, Dienste) vom Master zum Backup – nur auf Befehl || ''System → High Availability → Settings'' und ''Status''
|}
Wichtige Begriffe:
* '''VHID''' – Kennung einer CARP-Gruppe; pro Netz eine eigene, auf beiden Firewalls identisch.
* '''Advbase / Advskew''' – Ankündigungsintervall (Standard 1 Sekunde) und Verzögerung; die Firewall mit dem '''niedrigeren Skew''' wird Master (Master 0, der Backup erhält nach der Synchronisation automatisch einen höheren Wert).
* '''Preempt''' – sorgt dafür, dass alle CARP-Adressen einer Firewall gemeinsam Master bzw. Backup sind.
* '''Demotion''' – Zähler, der eine Firewall für CARP unattraktiver macht (z. B. bei Dienstausfällen oder im Wartungsmodus).

[[Datei:OPNsense-HA-CARP.png|thumb|center|750px|OPNsense-Cluster mit CARP: Master und Backup teilen sich je Netz eine virtuelle CARP-Adresse (VHID); über eine direkte Sync-Schnittstelle laufen pfsync (Zustandstabelle) und die Konfigurationssynchronisation. Clients nutzen ausschließlich die CARP-Adressen als Gateway und DNS.]]

== Voraussetzungen und Planung ==
* '''Identische Schnittstellen-Zuordnung''' auf beiden Firewalls (LAN = gleicher Port und gleicher interner Name wie ''opt1'' usw. – prüfen unter ''Interfaces → Overview''), idealerweise identische Hardware bzw. Netzwerktreiber. Bei unterschiedlichen Treibern (z. B. physischer Master, virtueller Backup) funktioniert pfsync nicht, da sich die Schnittstellennamen unterscheiden.
* '''Drei Adressen pro Netz''': eine je Firewall plus die gemeinsame CARP-Adresse – auch auf dem WAN. Vom Provider werden daher mindestens drei feste Adressen bzw. ein kleines Netz benötigt.
* '''Eigene Sync-Schnittstelle''' (direktes Kabel zwischen beiden Firewalls) für pfsync und Konfigurationssynchronisation – aus Sicherheitsgründen (Manipulation von States) und für die Leistung.
* '''Switch-Infrastruktur''': beide Firewalls in derselben Layer-2-Domäne, möglichst an einem Switch, einem Stack oder einem [[MLAG]]-Verbund (siehe unten).

=== Beispiel-Szenario ===
{| class="wikitable"
! Netz !! Master (fw1) !! Backup (fw2) !! CARP-Adresse !! VHID
|-
| WAN <code>172.18.0.0/24</code> || <code>172.18.0.101</code> || <code>172.18.0.102</code> || <code>172.18.0.100</code> || 1
|-
| LAN <code>192.168.1.0/24</code> || <code>192.168.1.10</code> || <code>192.168.1.20</code> || <code>192.168.1.1</code> || 3
|-
| PFSYNC <code>10.0.0.0/30</code> || <code>10.0.0.1</code> || <code>10.0.0.2</code> || – || –
|}

== Einrichtung Schritt für Schritt ==
=== Schritt 1: Schnittstellen und Grundregeln (beide Firewalls) ===
* Physische Adressen wie in der Tabelle vergeben.
* '''Firewall → Rules''': Auf allen Schnittstellen mit CARP-Adressen Pakete des Protokolls '''CARP''' erlauben (auf LAN deckt die Standardregel das meist ab, auf WAN ist eine Regel nötig).
* Auf der PFSYNC-Schnittstelle eine Regel, die den Verkehr vom Partner erlaubt (mindestens pfsync und den Zugriff auf die Weboberfläche für die Synchronisation).

=== Schritt 2: CARP-Adressen (nur auf dem Master) ===
'''Interfaces → Virtual IPs → Settings''' → '''+''':
{| class="wikitable"
! Feld !! WAN !! LAN
|-
| Mode || CARP || CARP
|-
| Interface || WAN || LAN
|-
| Network / Address || <code>172.18.0.100/24</code> || <code>192.168.1.1/24</code>
|-
| Password || langes, zufälliges Kennwort || eigenes Kennwort
|-
| VHID Group || 1 || 3
|-
| Advbase / Advskew || 1 / 0 || 1 / 0
|-
| Description || VIP WAN || VIP LAN
|}
CARP-Adressen immer mit '''derselben Netzmaske wie die Schnittstelle''' anlegen (bei <code>/24</code> also <code>/24</code>, nicht <code>/32</code>). Für weitere Adressen im selben Netz (z. B. zusätzliche öffentliche IPs) statt neuer VHIDs '''IP-Aliase''' mit der VHID der vorhandenen CARP-Adresse verwenden – das reduziert den CARP-Verkehr. IP-Aliase werden nicht synchronisiert und müssen auf beiden Firewalls angelegt werden.

=== Schritt 3: Source NAT auf die CARP-Adresse ===
Ausgehender Verkehr muss die '''CARP-Adresse''' des WAN als Absender verwenden, sonst brechen Verbindungen beim Wechsel ab. '''Firewall → NAT → Source NAT''': Modus ''Manual'' oder ''Hybrid'' und eine Regel ''Interface WAN, Quelle LAN-Netz (bzw. die internen RFC-1918-Netze), Übersetzung 172.18.0.100''. Als Quelle '''nicht''' ''any'' wählen – sonst würde auch Verkehr der Firewall selbst übersetzt, und der Backup erreicht das Internet nicht mehr (z. B. für Updates).

=== Schritt 4: pfsync und Konfigurationssynchronisation ===
'''System → High Availability → Settings''' auf dem '''Master''':
{| class="wikitable"
! Einstellung !! Wert
|-
| Synchronize all states via || PFSYNC-Schnittstelle
|-
| Synchronize Peer IP || <code>10.0.0.2</code>
|-
| Sync compatibility || auf beiden Firewalls gleich (Standard)
|-
| Synchronize Config || <code>10.0.0.2</code> (Sync-Adresse des Backups)
|-
| Remote System Username / Password || Benutzer mit Administratorrechten auf dem Backup (am besten ein eigener Sync-Benutzer)
|-
| Services || zu übertragende Bereiche, z. B. Firewall-Regeln, NAT, Aliase, Virtual IPs, Zertifikate, Dienste wie Kea DHCP, Unbound, IPsec, WireGuard, FRR
|-
| Disable preempt || aus (Standard) – Preempt aktiv lassen
|}
Auf dem '''Backup''' nur pfsync einrichten (Schnittstelle PFSYNC, Peer IP <code>10.0.0.1</code>). Die Felder für die Konfigurationssynchronisation bleiben auf dem Backup '''leer''' – sonst könnte versehentlich der Backup den Master überschreiben. Tipp aus der OPNsense-Dokumentation: Master und Backup mit unterschiedlichen Themes versehen, um sie in der Oberfläche sicher zu unterscheiden.

=== Schritt 5: Synchronisieren und testen ===
# '''System → High Availability → Status''' auf dem Master: Verbindung zum Backup prüfen und '''Synchronize and reconfigure all''' ausführen. Die CARP-Adressen erscheinen auf dem Backup mit höherem Skew.
# '''Interfaces → Virtual IPs → Status''': Master zeigt ''MASTER'', Backup ''BACKUP'' für alle VHIDs.
# Beide Firewalls einmal neu starten.
# '''Test:''' Von einem Client eine SSH-Verbindung nach außen aufbauen, unter ''Firewall → Diagnostics → States'' auf beiden Firewalls denselben State sehen und dann beim Master das Kabel ziehen bzw. den Wartungsmodus aktivieren – die SSH-Verbindung muss bestehen bleiben.

{{Hinweis|Die Konfigurationssynchronisation erfolgt bewusst '''nur auf Befehl''': Änderungen werden zuerst auf dem Master getestet, der Backup bleibt bis zur Synchronisation in einem bekannt guten Zustand. Wer automatisch synchronisieren möchte, legt auf dem Master unter ''System → Settings → Cron'' einen Job mit dem Befehl '''HA update and reconfigure backup''' an (z. B. täglich nachts); er läuft nur, wenn alle CARP-Adressen des Masters im Zustand ''MASTER'' sind.}}

== Wie schnell schaltet CARP um? ==
Der Backup übernimmt, wenn er etwa drei Ankündigungsintervalle lang nichts vom Master hört – bei ''Advbase 1'' also nach rund '''drei Sekunden'''. Dank pfsync laufen bestehende TCP-Verbindungen weiter; kurze Unterbrechungen im Sekundenbereich sind normal. Mit ''Preempt'' (Standard) wechseln alle CARP-Adressen gemeinsam, damit nicht eine Firewall für WAN und die andere für LAN zuständig ist.

Neben einem Totalausfall führt auch der '''Ausfall einer einzelnen Schnittstelle''' (Link down) zum Wechsel. Zusätzlich können Dienste per '''Demotion''' einen Wechsel auslösen – etwa OSPF über ''CARP demote'' im Plugin [[OPNsense - OSPF und OSPFv3 mit FRR|os-frr]].

== Weitere Dienste im Cluster ==
{| class="wikitable"
! Dienst !! Hinweis !! Artikel
|-
| DHCP || Gateway und DNS als Option auf die '''CARP-Adresse'''; Kea mit Lease-Synchronisation (hot-standby) oder Dnsmasq mit getrennten Pools || [[OPNsense - Kea DHCP mit Hochverfügbarkeit]], [[OPNsense - Dnsmasq DHCP-Server]]
|-
| DNS (Unbound) || Clients nutzen die CARP-Adresse; Konfiguration per Synchronisation übertragen || [[OPNsense - Unbound DNS Resolver]]
|-
| WireGuard || in jeder Instanz '''Depend on (CARP)''' setzen; Gegenstellen verwenden die CARP-Adresse als Endpoint || [[OPNsense - WireGuard Site-to-Site und Road Warrior]]
|-
| IPsec || Local Address = CARP-Adresse des WAN || [[OPNsense - IPsec Site-to-Site route-based]]
|-
| Dynamisches Routing (FRR) || CARP Failover, CARP demote oder CARP-abhängige OSPF-Kosten || [[OPNsense - FRR Dynamisches Routing]]
|-
| PPPoE/Einwahl || Option ''Disconnect dialup interfaces'': der Backup trennt PPP-Verbindungen und baut sie als Master neu auf || –
|}
Einträge, die auf einer Firewall bewusst anders bleiben sollen, lassen sich mit '''No XMLRPC Sync''' bzw. ''Disable HA sync'' (bei einzelnen Diensten) von der Synchronisation ausnehmen.

== Netzwerk und Switches ==
Laut OPNsense-Dokumentation ist die Switch-Infrastruktur entscheidend für einen zuverlässigen Failover:
* Beide Firewalls '''im selben VLAN und an derselben Switching-Fabric''' – ein Switch, ein Stack oder ein MLAG-Verbund. Hängen die Firewalls an getrennten, nicht gekoppelten Switches, drohen Split-Brain, MAC-Flapping-Warnungen und langsame Umschaltungen.
* '''IGMP Snooping''' ohne IGMP-Querier kann die CARP-Multicasts (Protokoll 112) blockieren.
* '''Port Security / Sticky MAC''' können die virtuellen CARP-MAC-Adressen (<code>00:00:5e:00:01:xx</code>) sperren.
* '''MAC-Flapping-Erkennung''' und '''Storm Control''' können CARP-Wechsel als Angriff werten bzw. Ankündigungen verwerfen.
* Wo Multicast nicht möglich ist (z. B. in manchen Cloud- und Virtualisierungsumgebungen), kann pro CARP-Adresse ein '''Peer''' für '''Unicast CARP''' eingetragen werden. Viele Cloud-Plattformen unterstützen die Übernahme virtueller MAC-Adressen jedoch grundsätzlich nicht – CARP ist dort oft keine verlässliche Lösung.

== Wartung und Updates ohne Ausfall ==
Vorgehen laut OPNsense-Dokumentation:
# '''Backup aktualisieren''' und warten, bis er wieder online ist.
# Auf dem Master unter '''Interfaces → Virtual IPs → Status''' '''Enter Persistent CARP Maintenance Mode''' wählen – der Backup wird Master (der Wartungsmodus übersteht auch einen Neustart).
# Prüfen, ob DHCP, VPN, NAT und alle anderen Dienste auf dem Backup korrekt laufen.
# Den Master aktualisieren und anschließend '''Leave Persistent CARP Maintenance Mode''' wählen.
'''Neue Adresse in eine laufende VHID aufnehmen:''' Auf einer Firewall unter ''Virtual IPs → Status'' '''Disable CARP''' (nicht den Wartungsmodus) wählen, den IP-Alias auf beiden Firewalls identisch anlegen und CARP wieder aktivieren. Wird der Alias nur auf einer Seite ergänzt, passt die Prüfsumme der VHID nicht mehr, und beide Firewalls werden Master (Split-Brain).

== Typische Probleme und Lösungen ==
{| class="wikitable"
! Symptom !! Ursache und Lösung
|-
| '''Split-Brain''': beide Firewalls zeigen MASTER || CARP-Pakete erreichen den Partner nicht (Firewall-Regel für Protokoll CARP fehlt, IGMP Snooping, getrennte Switches) oder die VIP-Konfiguration einer VHID weicht ab (Kennwort, Adressen, IP-Aliase). Mit ''tcpdump'' auf dem Backup prüfen, ob die Ankündigungen mit der Adresse des Masters ankommen; testweise Unicast CARP nutzen.
|-
| Gemischte Rollen: WAN auf fw1, LAN auf fw2 || ''Disable preempt'' aktiv oder Schnittstellenproblem auf einer Seite – Preempt aktivieren, Links prüfen.
|-
| Backup erreicht das Internet nicht (z. B. für Updates) || Source-NAT-Regel mit Quelle ''any'' übersetzt auch den Verkehr der Firewall selbst – Quelle auf die internen Netze beschränken.
|-
| Verbindungen brechen beim Failover ab || pfsync nicht aktiv, unterschiedliche ''Sync compatibility'', unterschiedliche Netzwerktreiber/Schnittstellennamen oder Source NAT nicht auf der CARP-Adresse.
|-
| Firewall bleibt dauerhaft Backup („CARP has detected a problem“) || Demotion-Wert erhöht (z. B. durch Schnittstellenfehler oder einen ausgefallenen Dienst). Ursache im Systemlog prüfen; der Wert lässt sich durch zweimaliges Betätigen von ''Enter Persistent CARP Maintenance Mode'' auf 0 zurücksetzen.
|-
| Backup wird nach Synchronisation falsch konfiguriert || Konfigurationssynchronisation auch auf dem Backup eingetragen oder Schnittstellenzuordnung unterschiedlich.
|}
CARP-Ereignisse stehen im allgemeinen Systemlog (''System → Log Files → General'').

== Sicherheitsempfehlungen ==
* pfsync und Konfigurationssynchronisation nur über eine '''dedizierte Schnittstelle''' bzw. ein direktes Kabel.
* Für die Synchronisation einen '''eigenen Benutzer''' mit starkem Kennwort anlegen; ''Verify peer'' aktivieren, wenn der Backup ein vertrauenswürdiges Zertifikat besitzt.
* Lange, zufällige '''VHID-Kennwörter''' verwenden.
* Den Backup regelmäßig synchronisieren und Failover-Tests einplanen (z. B. vor Updates).
* CARP-Zustand und Demotion überwachen, z. B. mit dem [[OPNsense - Zabbix-Agent|Zabbix-Agent]] oder per Log-Auswertung mit dem [[OPNsense - Wazuh-Agent|Wazuh-Agent]].

== Fazit ==
Mit CARP, pfsync und Konfigurationssynchronisation baut OPNsense einen Active/Passive-Cluster, der bei Hardware-, Link- oder Dienstausfällen in wenigen Sekunden umschaltet, ohne dass bestehende Verbindungen abbrechen. Entscheidend für den Erfolg sind identische Schnittstellen auf beiden Firewalls, Source NAT auf die CARP-Adresse, eine dedizierte Sync-Verbindung, eine geeignete Switch-Infrastruktur und Dienste, die konsequent auf die CARP-Adressen ausgerichtet sind.

== Unterstützung von m.a.x. it ==
Sie planen einen hochverfügbaren OPNsense-Cluster oder möchten bestehende Firewalls redundant ausbauen? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit [https://www.max-it.de/it-services/opnsense/ OPNsense-Firewall-Services von m.a.x. it] und einer [https://www.max-it.de/it-services/managed-firewall/ Managed Firewall von m.a.x. it] inklusive Betrieb und Updates des Clusters.

== Siehe auch ==
* [[Hochverfügbarkeit]]
* [[Failover]]
* [[Redundanz]]
* [[VRRP]]
* [[MLAG]]
* [[OPNsense - Kea DHCP mit Hochverfügbarkeit]]
* [[OPNsense - FRR Dynamisches Routing]]
* [[OPNsense - WireGuard Site-to-Site und Road Warrior]]
* [[OPNsense - Eine kurze Einführung]]

== Links und Quellen ==
* [https://docs.opnsense.org/manual/hacarp.html OPNsense-Doku – High Availability]
* [https://docs.opnsense.org/manual/how-tos/carp.html OPNsense-Doku – Configure CARP]
* [https://docs.opnsense.org/manual/firewall_vip.html OPNsense-Doku – Virtual IPs]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]

OPNsense - Hochverfügbarkeit mit CARP und pfsync - Versionsgeschichte

imported>TechCorner-Redaktion: Neuer Artikel: HA-Cluster mit CARP, pfsync und Konfigurationssynchronisation, Stand OPNsense 26.7