OPNsense - Hochverfügbarkeit mit CARP und pfsync
Auf einen Blick
| Gilt für | 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
| 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).
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
| Netz | Master (fw1) | Backup (fw2) | CARP-Adresse | VHID |
|---|---|---|---|---|
WAN 172.18.0.0/24 |
172.18.0.101 |
172.18.0.102 |
172.18.0.100 |
1 |
LAN 192.168.1.0/24 |
192.168.1.10 |
192.168.1.20 |
192.168.1.1 |
3 |
PFSYNC 10.0.0.0/30 |
10.0.0.1 |
10.0.0.2 |
– | – |
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 → +:
| Feld | WAN | LAN |
|---|---|---|
| Mode | CARP | CARP |
| Interface | WAN | LAN |
| Network / Address | 172.18.0.100/24 |
192.168.1.1/24
|
| 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 /24 also /24, nicht /32). 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:
| Einstellung | Wert |
|---|---|
| Synchronize all states via | PFSYNC-Schnittstelle |
| Synchronize Peer IP | 10.0.0.2
|
| Sync compatibility | auf beiden Firewalls gleich (Standard) |
| Synchronize Config | 10.0.0.2 (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 10.0.0.1). 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.
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 os-frr.
Weitere Dienste im Cluster
| 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 (
00:00:5e:00:01:xx) 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
| 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 Zabbix-Agent oder per Log-Auswertung mit dem 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 OPNsense-Firewall-Services von m.a.x. it und einer 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
- OPNsense-Doku – High Availability
- OPNsense-Doku – Configure CARP
- OPNsense-Doku – Virtual IPs
- m.a.x. it – OPNsense-Firewall-Services
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
