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
Moin,
auch wenns schon etwas her ist:
Quote from: Alexander.P on November 07, 2025, 11:04:28 AMJedes 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.
Quote from: Alexander.P on November 07, 2025, 11:04:28 AMConfig 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.
Quote from: Alexander.P on November 07, 2025, 11:04:28 AMJetzt 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.
Quote from: Alexander.P on November 07, 2025, 11:04:28 AMIPSec 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.
Quote from: Alexander.P on November 07, 2025, 11:04:28 AMEventuell 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).
Quote from: Alexander.P on November 07, 2025, 11:04:28 AMAls 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
Quote from: JeGr on December 05, 2025, 09:59:05 AMQuoteIPSec 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
Quote from: Patrick M. Hausen on December 05, 2025, 10:22:10 AMDer Workaround ist, ausschließlich "Trap" zu verwenden, also auch in den DPD und weiteren Actions.
Workaround, OK. Aber das ist ja ne zentrale Komponente und das ist seit August offen und Ad hat trotz @ im Ticket nicht drauf reagiert. Tut sich da noch was, oder muss man das wieder als "Workaround vorhanden, muss man wissen" sich irgendwo ablegen, damit man bei Kunden das korrekt einrichtet? Das kann ja als Bugfix nicht so schwer sein zu checken, dass man auf dem Standby ist und dann "start" zu ignorieren weil "habe die VIP nicht". War vorher möglich, sollte jetzt auch so sein, oder? :)
Cheers
Frag das doch nicht mich :-)
@franco?
Sollte der IKE daemon der IPsec Gegenstelle nicht Payloads unbekannter IP addressen verwerfen? Wenn dort 0.0.0.0 eingestellt ist kann jede IP mit valider PSK dort die verbindung aufbauen. Wenn beide gegenstellen nur eine IP addresse zulassen gibt es kein Problem, weil nur die OPNsense mit der CARP IP Addresse akzeptiert werden kann.
Also ist das eher ein Operations-defizit der durch korrekte Konfiguration der beiden Peers behoben werden kann.
Hallo zusammen, erst mal danke für antworten.
QuoteQuote 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
QuoteFrage 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.
QuoteQuote 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,
noch ein etwas eher unfachmännischer Kommentar, der aus Sicht einer Person kommt, die mit IT eher auf der Prozess- und Organisationsebene zu tun hat....
Bin gestolpert über den Hinweis, sinngemäß... Standort, an dem bald keine Leute mehr sind....
Passt den die Organisation / Aufbau noch im Sinne, benötigt man das ,,komplexe" Konstrukt denn zukünftig noch, in dieser Art? Würde sich mit einer gewissen Reorganisation vielleicht auf die kommerziellen Produkte verzichten lassen?
Nur so ein Gedanke...
Beste Grüße