Die Firewall ist das zentrale Nadelöhr jeder Unternehmens-IT. Fällt sie aus, steht das gesamte Netzwerk still — kein Internet, keine VPN-Verbindungen, keine Kommunikation zwischen Standorten. Für KMU, die auf permanente Erreichbarkeit angewiesen sind, ist eine einzelne OPNsense-Firewall deshalb ein inakzeptables Risiko. Die Lösung: ein High-Availability-Cluster mit CARP Failover, bei dem eine zweite Firewall im Standby bereitsteht und innerhalb von Sekunden übernimmt.

Warum High Availability für Firewalls unverzichtbar ist

Ein Firewall-Ausfall betrifft nicht nur den Internetzugang. VoIP-Telefonie bricht ab, Cloud-Dienste sind nicht erreichbar, Site-to-Site-VPNs fallen weg und interne Dienste zwischen VLANs werden unterbrochen. Je nach Branche drohen bei längeren Ausfällen SLA-Verletzungen, Umsatzeinbußen oder sogar Compliance-Verstöße.

Hardware-Defekte, fehlerhafte Firmware-Updates oder Stromausfälle können jede Firewall treffen — unabhängig von der Qualität der eingesetzten Komponenten. Ein HA-Cluster eliminiert diesen Single Point of Failure und sorgt dafür, dass ein Ausfall der primären Firewall für Benutzer nahezu unsichtbar bleibt.

CARP: Das Protokoll hinter dem Failover

CARP (Common Address Redundancy Protocol) stammt aus dem OpenBSD-Projekt und ist das Herzstück der OPNsense-HA-Lösung. Das Prinzip ist einfach: Zwei oder mehr Firewalls teilen sich eine gemeinsame virtuelle IP-Adresse (VIP). Die primäre Firewall sendet regelmäßig CARP-Advertisements ins Netzwerk. Bleiben diese aus, übernimmt die sekundäre Firewall die VIP und damit den gesamten Netzwerkverkehr.

Ergänzt wird CARP durch zwei weitere Komponenten:

pfSync — synchronisiert die State Table (aktive Verbindungen) zwischen beiden Firewalls, sodass bestehende TCP-Sessions beim Failover nicht abbrechen.
XMLRPC Sync — repliziert die Konfiguration (Firewall-Regeln, NAT, VPN, Aliases) automatisch vom Primary auf den Secondary.

Voraussetzungen und Netzwerkarchitektur

Für einen OPNsense-HA-Cluster benötigen Sie:

Komponente	Beschreibung
2x OPNsense-Firewalls	Identische oder vergleichbare Hardware
WAN-Interface	Beide Firewalls am selben Uplink-Switch
LAN-Interface	Beide Firewalls am selben LAN-Switch
Sync-Interface	Dediziertes Interface für pfSync und XMLRPC
3 IP-Adressen pro Subnetz	Je eine pro Firewall + eine CARP VIP

Die Netzwerktopologie sieht schematisch so aus:

Internet
    |
[ Uplink-Switch ]
    |           |
[ FW1-WAN ]  [ FW2-WAN ]     CARP VIP: 203.0.113.1
    |           |
[ FW1-SYNC ]--[ FW2-SYNC ]   Sync: 10.0.0.1 <-> 10.0.0.2
    |           |
[ FW1-LAN ]  [ FW2-LAN ]     CARP VIP: 192.168.1.1
    |           |
[ LAN-Switch ]

Das dedizierte Sync-Interface ist entscheidend: Es isoliert den Synchronisationsverkehr vom Produktivnetz und verhindert, dass pfSync-Daten über unsichere Netze laufen. Ein direktes Crossover-Kabel oder ein separates VLAN eignet sich dafür ideal.

Konfiguration Schritt für Schritt

1. Sync-Interface einrichten

Auf beiden Firewalls das Sync-Interface konfigurieren — zum Beispiel 10.0.0.1/30 auf FW1 und 10.0.0.2/30 auf FW2. Dieses Netz wird ausschließlich für pfSync und XMLRPC verwendet.

2. CARP Virtual IPs anlegen

Unter Interfaces > Virtual IPs > Settings erstellen Sie die CARP VIPs. Für jedes Subnetz (WAN und LAN) wird eine virtuelle IP definiert:

Typ:        CARP
Interface:  WAN
Adresse:    203.0.113.1/24
VHID Group: 1
Passwort:   <sicheres-shared-secret>
Adv. Skew:  0   (Primary)

Auf der sekundären Firewall wird dieselbe VIP mit einem höheren Adv. Skew (z. B. 100) konfiguriert. Der niedrigere Skew-Wert bestimmt den Primary.

3. pfSync aktivieren

Unter System > High Availability > Settings aktivieren Sie pfSync und wählen das Sync-Interface aus. Als Sync Peer tragen Sie die IP der jeweils anderen Firewall ein. Damit werden aktive Connection States in Echtzeit repliziert.

4. XMLRPC Configuration Sync

Im selben Menü konfigurieren Sie die XMLRPC-Synchronisation auf dem Primary. Tragen Sie die IP des Secondary sowie Benutzername und Passwort ein. Wählen Sie aus, welche Konfigurationsbereiche synchronisiert werden sollen — in der Regel alle:

Firewall-Regeln und NAT
Aliases und Schedules
VPN-Konfigurationen (IPsec, OpenVPN, WireGuard)
DHCP-Server und DNS
Intrusion Detection (Suricata)

Ab sofort wird jede Änderung auf dem Primary automatisch auf den Secondary übertragen.

5. Gateway und NAT anpassen

Stellen Sie sicher, dass alle Clients die CARP VIP als Default Gateway verwenden — nicht die physische IP einer einzelnen Firewall. Outbound-NAT-Regeln sollten ebenfalls die CARP VIP als Quell-IP nutzen, damit der Return-Traffic immer zur aktiven Firewall gelangt.

Failover testen

Ein HA-Setup, das nicht getestet wurde, ist keines. Folgende Tests sollten Sie durchführen:

Kabel ziehen — Trennen Sie das WAN-Kabel der primären Firewall. Innerhalb von 2-3 Sekunden sollte der Secondary die VIP übernehmen.
Primary herunterfahren — Simuliert einen vollständigen Hardware-Ausfall. Bestehende Verbindungen sollten dank pfSync bestehen bleiben.
Failback prüfen — Nach Wiederherstellung des Primary übernimmt dieser automatisch wieder die Master-Rolle (niedrigerer Skew).
Langzeittest — Lassen Sie den Secondary über mehrere Stunden als Master laufen und prüfen Sie VPN-Tunnel, NAT und IDS-Funktionalität.

HA-Status mit DATAZONE Control überwachen

Ein Failover nützt wenig, wenn niemand bemerkt, dass er stattgefunden hat. Mit DATAZONE Control lässt sich der CARP-Status beider Firewalls kontinuierlich überwachen. Typische Checks umfassen:

CARP-Status — Ist der erwartete Primary tatsächlich Master? Ist der Secondary im Backup-Modus?
pfSync-Status — Werden States synchronisiert? Wie groß ist die State Table?
Interface-Health — Sind alle relevanten Interfaces (WAN, LAN, Sync) aktiv?
Config-Drift — Stimmt die Konfiguration auf beiden Nodes überein?

Bei einem unerwarteten Failover wird sofort ein Alert ausgelöst, sodass das IT-Team die Ursache untersuchen kann, bevor auch der Secondary ausfällt. In Kombination mit Netzwerk-Monitoring entsteht so ein lückenloses Bild der gesamten Infrastruktur.

Häufige Stolpersteine

Asymmetrisches Routing: Wenn eingehender Traffic über FW1 läuft, die Antwort aber über FW2 geht, werden Pakete verworfen. Lösung: Alle Gateways und NAT-Regeln konsequent auf die CARP VIPs umstellen.

State-Synchronisation bei hoher Last: Bei sehr großen State Tables (>500.000 Einträge) kann pfSync zur Engstelle werden. Ein dediziertes Gigabit-Sync-Interface und ausreichend RAM auf beiden Nodes schaffen Abhilfe.

XMLRPC-Fehler nach Updates: Nach einem OPNsense-Update können XMLRPC-Sync-Fehler auftreten, wenn die Versionen nicht identisch sind. Daher immer zuerst den Secondary updaten, dann den Primary — so bleibt der Cluster während des Updates funktionsfähig.

VHID-Konflikte: Jede CARP VIP benötigt eine eindeutige VHID-Gruppe pro Broadcast-Domain. Bei mehreren HA-Clustern im selben Netz auf unterschiedliche VHIDs achten.

Fazit

OPNsense High Availability mit CARP ist eine bewährte, kosteneffiziente Methode, um den Single Point of Failure Firewall zu eliminieren. Mit zwei Firewalls, einem dedizierten Sync-Interface und sauberer Konfiguration erreichen KMU eine Verfügbarkeit, die sonst nur Enterprise-Lösungen bieten. Der Schlüssel liegt in der korrekten Einrichtung, gründlichem Testing und kontinuierlichem Monitoring — damit der Failover im Ernstfall tatsächlich reibungslos funktioniert.

Sie möchten Ihre OPNsense-Firewalls hochverfügbar betreiben? Wir planen und implementieren HA-Cluster inklusive Monitoring — sprechen Sie uns an.

OPNsense High Availability: CARP Failover für ausfallsichere Firewalls