Messages

Hallo zusammen, erst mal danke für antworten.

Quote from: Alexander.P on November 07, 2025, 11:04:28 AM
    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.

Auf beiden Nodes ist jeweils die andere Seite über das SYNC Interface eingerichtet.

Node 1
Synchronize all states via ->  SYNC
Sync compatibility. -> OPNsense 24.7 or above
Synchronize Peer IP -> 172.16.0.2

Node 2
Synchronize all states via ->  SYNC
Sync compatibility. -> OPNsense 24.7 or above
Synchronize Peer IP -> 172.16.0.1

Frage vorab: Hast du denn den Config Sync aktiv bzw. als Cronjob eingerichtet?

Ja. Der sync der Config ist per Cron hinterlegt, und wird auch bei Änderungen dann Manuell gemacht.

Es ist aber nur bei der Node 1 eingerichtet das er einen Sync Partner hat.
Mir wurde bei einem Call gesagt das die zweite Node diese Einstellungen nicht haben soll.

Quote from: Alexander.P on November 07, 2025, 11:04:28 AM
    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.

in der IPSec Config sind die CARP VIPs hinterlegt, trotzdem startet das IPsec auch auf der Node 2

Die unschöne Lösung ist jetzt beim Config Sync den Server auf der Node2 nicht starten zu lassen.


Bei dem Setup was ich hier habe hängen beide Nodes hinter einem StarLink Router und als weites WAN einen LTE/5G Router.
Also ich habe nur Private IPs in auf meinen WAN interfaces (NAT + CNAT)
Wir könnten zwar den StarLink router umstellen das er die Offentliche IP durchgibt. Aber dann kann nur eine Node diese haben. CARP fällt dann wieder raus.

IPsec hab ich jetzt doppelt eingerichtet damit über beide WAN´s einen Tunnel aufgebaut wird.
Dazu ist aber einen Statische Route einzutragen, Die gegenstelle hat zwei öffentliche IPs. Eine wird über die Statische route über Starlink geroutet die andere über den LTE Router.

Auch hier war es so, das IPSec sich nicht an die hinterlegte CARP vIP hält. sondern einfach den Tunnel aufbaut auf dem Interface was per Routing tabelle für die Destination zuständig ist.
Und solange die Node2 eine IP auf WAN1 oder WAN2 hat und über den GW raus kann, wird der Tunnel aufgebaut. Was dann natürlich den Tunnel der Node1 brechen lässt.

Auf der Gegenseite muss ich bei Remote IP %any eintragen da ich keine Feste öffentliche IP habe.


Aber das IPsec ist auch nicht gerade Stabil, manchmal ist die Tunnel Laufzeit mehrere Stunden oder Tage, manchmal auch nur ein paar Minuten.
Denke aber das liegt an der Funk Technik. Das da halt immer mal was wegbricht.

Über die beiden VTI IPsec Tunnels ist dann BGP gelegt was sehr schnell den Traffic zwischen den beiden Tunnels umschaltet. Das funktioniert jedenfalls.

Manchmal wird einer der IPsecs auch garnicht aufgebaut. warum keine ahnung.
erst nach einem Neustart von IPsec gehts dann wieder.
Daher hab ich hier Monit eingerichtet was die beiden Tunnels prüft, ob die Gegenstelle erreichbar ist. Und nach X Fehlversuchen wird IPsec neugestartet.

Auf einer TEST OPNsense ist während den Feiertagen / Neujar der IPSec dienst durch Monit so oft neugestartet worden das IPsec garnicht mehr starten wollte.
Auch in der Console konnte ich charon und Strongswan nicht startet. Erst ein Reboot der Test FW hat wieder für Funktion gesorgt.
Und das war nicht mal ein HA System sondern einfach eine einzelne Instanz.

Mein Cheff will eine Stabile Firewall Lösung, daher werden wir das System mit Fortinet nochmal aufbauen und schauen wie es sich dann verhält.
 

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