OpnSense 25.10_2 HA Cluster Probleme

Started by Alexander.P, November 07, 2025, 11:04:28 AM

Previous topic - Next topic
Hallo zusammen,

ich betreibe schon sein Jahren einige OpnSense und PFsense in der Community Edition als Single Node.
Dort läuft bis auf ein paar kleinere Probleme alles bestens.

Die Probleme fingen bei der OpnSense erst an, als ich für einen neuen Standort die Firewall im HA Betrieb aufbaute.
Und vor Kurzen auf die letzte Version 25.10 aktualisierte. Business Version.


Damals zwei Nodes vorbereitet Version weis ich nicht mehr könnte irgendeine 24er gewesen sein.
Sync Interface Definiert (Cross Connect)
Pro Node Zwei Interface in ein LAGG gesteckt (Failover) Terminieren auf zwei Core Switchen mit 10 vLANs
10 vLANs auf dem LAGG erstellt.
2x WAN Pro Node (beide WANs sind hinter einem NAT Router wegen CARP)


Jedes vLAN Interface hat auf beiden Nodes eine Separate IP
Node1 10.x.x.251
Node2 10.x.x.252
CARP IP 10.x.x.1

Ist bei jedem Netz etwas anders da die Netze mal kleiner mal größer als /24 sind.

Also 24 Interfaces Konfiguriert und 12 Mal CARP eingerichtet.
Hier wurde mir schon klar das Firewalls von Cisco, Forti, Sophos da Benutzerfreundlicher sind.


CARP Umschalt-Szenarios getestet.
Ein Core Switch Ausfall -> kein HA Umschalten. LAGG Schaltet um
WAN1 NAT Router Ausfall -> kein HA Umschalten. Aber GW Switch funktionierte
Bei Master Node WAN1 gezogen -> HA Umschaltung
Bei Master Node WAN2 gezogen -> HA Umschaltung
Bei Master Node beide LAGG Interfaces gezogen -> HA Umschaltung
Bei Backup Node WAN1 gezogen -> nix = OK
Bei Backup Node WAN2 gezogen -> nix = OK
Bei Backup Node beide LAGG Interfaces gezogen -> nix = OK
Bei Backup Node beide LAGG Interfaces gezogen -> nix = OK

So soweit so gut. Scheint alles zu funktionieren.

Config sync getestet, und festgestellt das nicht alles übertragen wird. Einige Setting´s müssen manuell auf der Backup Node gemacht werden.
Ok nicht schön aber ist halt so.


Jetzt ist mir beim weiteren einrichten und nach 3 Monaten betrieb aufgefallen.
Wenn die Backup Node übernimmt, wird die Session Tabelle nicht mehr auf die Master Node übertragen.
Sie schaltet einfach zurück.
Und die Master Node blockt dann erst mal jeglichen Taffic da sie keine Sitzung dazu kennt.

IPSec Tunnels die eingerichtet sind, werden sowohl auf der Master Node als auch auf der Backup Node aktiviert.
Sorgt natürlich auf der Gegenstelle das der Tunnel andauernd neu aufgebaut wird.
IPSec auf der Backup Node ausgeschaltet. Config Sync. IPSec auf Backup Node wieder an. Manuelles Ausschalten. -> Ziemlicher Mist

IPSec ist auf die CARP IPs eingerichtet, die ja nur auf der "Aktiven Node" ist.
Trotzen wird die Interface IP einfach genommen um den Tunnel aufzubauen.
In einigen Beiträgen hab ich dann gesehen, das dort ein Outgoing NAT eingerichtet wurde. Funktioniert aber nicht (mehr).
Da die IPSec Charon an die Routing Tabelle hält.
Und wenn die WAN Interface
Node1 WAN1 192.x.x.251
Node2 WAN1 192.x.x.252
CARP WAN1 192.x.x.250
Einen GW haben 192.x.x.1 dann geht der Traffic von Charon IPsec einfach darüber raus.

IPsec ist mit VTI eingerichtet und funktioniert einwandfrei. Sobald nur die Aktive Node "Aktive" ist.
Oder halt auf allen anderen Singel Node Instanzen.


Für die Fernwartung läuft auf beiden Nodes noch Tailscale.
Das funktioniert so einigermaßen im HA Betrieb.
Mit einigen Einschränkungen wenn Advertised Routing aktiviert ist. (Auf den Single Instanzen ohne Probleme)
Tailscale hat hier das Problem das die letzte Node die die Routen bekannt gibt, die Routen erhält.
Ergo Backup Node darf die Routen bekannt geben, aber wird bei Tailscale nur Manuell freigegeben.

Wenn jetzt Tailscale Traffic über die Firewall ins Netz geht kommt.
Wird dieser automatisch ein Source Nat gemacht, dieser Traffic kommt dann nicht mit der GW IP 10.x.x.1 sondern mit der jeweiligen Node IP 10.x.x.251/252
Was natürlich bei einem umschalten wieder zum Sesson Drop führt.
Das ist aber ein Tailscale Problem, und weniger ein Problem der OpnSense

Eventuell Verbanne ich die Subnet Routing Funktion ganz von der Firewall auf eine VM irgendwo




Als ich jetzt die Obigen HA Tests wieder gemacht hatte. War das verhalten extrem anders

Ein Core Switch Ausfall -> HA Umschaltung. LAGG schaltet auch um -> Fallback auf Master
WAN1 NAT Router Ausfall -> HA Umschaltung. GW Switch -> kein Fallback auf Master
Bei Master Node WAN1 gezogen -> HA Umschaltung
Bei Master Node WAN2 gezogen -> HA Umschaltung
Bei Master Node beide LAGG Interfaces gezogen -> HA Umschaltung
Bei Backup Node WAN1 gezogen -> nix = OK
Bei Backup Node WAN2 gezogen -> nix = OK
Bei Backup Node beide LAGG Interfaces gezogen -> nix = OK
Bei Backup Node beide LAGG Interfaces gezogen -> nix = OK

Eines nachts hat unser WAN1 NAT Router neugestartet.
Opnsense Schaltet um.
Auf den Core Switches sehe ich Log Port Flapping.
Port 25 auf beiden Switchen Master Node
Port 26 auf beiden Switchen Backup Node

Auf beiden Switches Port 25 down . up . down . up ....

Erst als ich die Master Node neugestartet hatte ist das verschwunden.
Und sie hat dann auch wieder die Master Rolle übernommen. Nachdem ca 3 Stunden alles über die Backup Node lief.
Und der WAN1 Router Neustart dauerte 10 Minuten.


Also irgendwie läuft da einiges Falsch. Wie gesagt im Single betrieb haben wir diese Extremen Probleme nicht. 


Was ich jetzt noch nicht nochmal getestet habe, ist das Backup einspielen.
Beide Nodes schreiben ihre Config ins Git.
Am Anfang haben wir das mal getestet.
Master Node aus -> Neu Installation -> Backup eingespielt -> Neustart -> alle Interfaces angeschlossen -> CARP Aktiviert -> Fallback von Aktiver Backup Node funktionierte
Ob das jetzt nach Mehrmonatigen betrieb noch funktioniert. Weis ich nicht.


Wenn jemand schon ähnliche Probleme hatte, und dafür auch Lösungen wäre ich dankbar.

Da ich den Stabilen HA betrieb gewährleisten muss, und an dem Standort bald kein Personal mehr ist, sonder nur noch Rechner.
Bind ich schon am überlegen auf eine Kommerzielle Lösung zurückzugreifen, die diesen Konfiguration irrsinnig (CARP) und HA Probleme nicht hat.
Auch im Bezug auf die WAN NAT Router, die nur deswegen da sind da ich nur eine Externe IP habe ...


Grüße
Alex