OpnSense 25.10_2 HA Cluster Probleme

[Alexander.P]

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

   

[JeGr]

Moin,

auch wenns schon etwas her ist:

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.

Ich würde bei CARP versuchen alle Netze gleich aufzusetzen. Also vllt. .1 als GW, .2/.3 als Nodes. Dann entfällt die Sucherei, welche IP in welchem Netz das jetzt ist und die Größe ist egal. Weniger fehleranfällig. Vor allem wäre das Arbeiten auf dem primary fix immer auf bspw. der .2.

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.

Das ist aber korrekt. Vielleicht nicht ganz User-friendly aber Faustregel: alles was "Hardware" ist (also Interfaces, IF Gruppen, IP Konfiguration etc.) ist pro Node zu konfigurieren. Alles was Regelwerk, PF und Co. sowie diverse Services betrifft ist sync-bar. Aber besser nachschauen, ob der Service XY da nicht spezifische Einstellungen für hat oder eben nicht gesynct wird. Bei Zusatzpaketen ist das zB nicht immer der Fall.

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.

Sync nicht korrekt konfiguriert? Auf dem Backup Node nicht den "General Settings" part ausgefüllt? Ohne wird kein State Sync zurück gemacht.

IPSec Tunnels die eingerichtet sind, werden sowohl auf der Master Node als auch auf der Backup Node aktiviert.

Wenn IPsec tatsächlich auf der VIP konfiguriert ist, wäre das ein Fehlverhalten. Wie ist IPsec eingerichtet? Mit der neuen Connections Methode oder eine alte Service-Konfiguration? Eventuell könnte das beim neuen Connections-Setup dann ein Fehler sein, müsste man einmal nachstellen.

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

Das wäre tatsächlich bei einem Cluster praktischer. Nicht nur wegen der NAT Thematik, sondern auch wegen der Regelerstellung. Bei zwei Nodes auf Firewalls die aktiv sind, wäre es sonst fürs Routing sehr verwirrend, über welchen Node die IPs gehen und von der aktiven FW und Routing Node dann auf die passive kommen - ohne die Tailscale eigene IP zu nutzen - wäre dann ähnlich wie bei OpenVPN/WG Einwahl problematisch und bräuchte wieder einen NAT Workaround.
Darum wäre es vermutlich die geschickteste Idee die zusätzlich noch den Nutzen hätte, dass die Regeln einfacher und geschickter definiert werden können wenn man ein extra VLAN mit ein/zwei Tailscale Nodes dahinter macht (betrifft 1:1 auch das Netbird Setup BTW, funktioniert dort ja sehr ähnlich).

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

Frage vorab: Hast du denn den Config Sync aktiv bzw. als Cronjob eingerichtet? Ansonsten WICHTIG: OPNsense macht KEINEN aktiven sofortigen Sync mehr. Seit längerem. Ich fände es zwar nach wie vor schön, wenn sie das als Option wieder einbauen würden, aber der Config Sync findet IMHO aktuell NICHT automatisch statt. Du brauchst also entweder nen zyklischen Cronjob der das übernimmt oder du musst manuell nach Änderungen wieder syncen, sonst passiert da nichts.

Dass dann im Betrieb die Firewalls auseinander driften in der Config und dann bei einem Failover sich vllt. sehr schräg verhalten ist leider dann kein Wunder. Das hat auch schon viele Kunden von uns getroffen, die von der Beschreibung "Sync" her einfach nicht erwarten, dass das was "Manuelles" ist oder man das nochmal extra als Cron einrichten muss, sondern dass Änderungen eben sofort gesynct und übertragen werden.

Ansonsten ist CARP/HA immer ein wenig komplex und durch die Beschreibung weiß ich jetzt spontan auch noch nicht alles, was schief gehen könnte, daher waren das nur die Punkte, die ich denke man recht schnell sehen kann. Ansonsten bräuchte man da mehr Details oder - wenn du eh schon drüber nachdenkst was anderes einzusetzen - wäre es vielleicht sinnvoll, das im Sinne von Support-Einkauf sich komplett anzusehen.

Cheers
\jegr

[Patrick M. Hausen]

IPSec Tunnels die eingerichtet sind, werden sowohl auf der Master Node als auch auf der Backup Node aktiviert.

Wenn IPsec tatsächlich auf der VIP konfiguriert ist, wäre das ein Fehlverhalten. Wie ist IPsec eingerichtet? Mit der neuen Connections Methode oder eine alte Service-Konfiguration? Eventuell könnte das beim neuen Connections-Setup dann ein Fehler sein, müsste man einmal nachstellen.

Mit der neuen Connections Methode startet er die Tunnel auf beiden Nodes, wenn die Start Action auf "Start" steht. Das hatte ich in diesem Ticket bereits reklamiert:

https://github.com/opnsense/core/issues/9082

Der Workaround ist, ausschließlich "Trap" zu verwenden, also auch in den DPD und weiteren Actions.

Gruß
Patrick