Upgrade HA Nodes - kurze Downtime & low Risk?

[liceo]

Sorry, da habe ich mich falsch ausgedrückt (man sollte halt nicht mehrere Dinge gleichzeitig machen  ). Bei den Gateways ist natürlich die IP des "Next Hop" (Internet Router) definiert. Die Config der Gateways ist auf beiden Nodes identisch. Das opnsense Interface in den Gateway-Subnetzen haben uniqe IPs (so wie im Beispiel von atom).

Trotzdem gehen die Gateways auf dem BACKUP Node nicht online. Vielleicht ein Problem, mit dem outbound NAT?

Übrigens: Das ganze dual-WAN Setup mit CARP HA funktioniert ansonsten einwandfrei. Ist auch so bei Kunden im Einsatz.

[liceo]

Ah, ich hab's grad herausgefunden, wieso der Backup Node nicht ins Internet connecten konnte:

Irgend in einer Doku habe ich mal gelesen, man soll in einem HA Setup die Outbound NAT Rules das Translation-target auf die CARP VIP legen. Das geht natürlich nicht, wenn der Backup Node nicht owner von dieser VIP ist.

Versuche mal die Interface IP zu setzen und teste ob das Failover noch sauber funktioniert (sollte eigentlich).

[mimugmail]

Ah, ich hab's grad herausgefunden, wieso der Backup Node nicht ins Internet connecten konnte:

Irgend in einer Doku habe ich mal gelesen, man soll in einem HA Setup die Outbound NAT Rules das Translation-target auf die CARP VIP legen. Das geht natürlich nicht, wenn der Backup Node nicht owner von dieser VIP ist.

Versuche mal die Interface IP zu setzen und teste ob das Failover noch sauber funktioniert (sollte eigentlich).

Wenn du dieses Problem hast dann ist in der outbound nat rule die Quelladresse zu breit gesetzt und beinhaltet dein WAN (also *?), da solltest du eher deine LANs reinsetzen und dann passiert sowas auch nicht.

P.S.: Ich hab NUR deinen letzten Beitrag gelsene, nicht den Thread

[lfirewall1243]

Glaube auch dein Problem liegt am falschen Outbound NAT.
Habe soeben noch Updates über CARP durchgeführt und es lief sauber

https://docs.opnsense.org/manual/how-tos/carp.html#setup-outbound-nat

[RalfG]

Aber NAT hat doch damit gar nichts zu tun.

Wenn die Backup-OPNSense sich die Updates holen soll, dann tut sie dies ohne NAT über deren offizielle IP und das entsprechende Gateway. Ich würde hier eher mal die Rules ansehen.

Außer man nattet auch die Pakete der Firewall selbst, was imho aber keinen Sinn ergibt.

LG, Ralf.

[lfirewall1243]

Aber NAT hat doch damit gar nichts zu tun.

Wenn die Backup-OPNSense sich die Updates holen soll, dann tut sie dies ohne NAT über deren offizielle IP und das entsprechende Gateway. Ich würde hier eher mal die Rules ansehen.

Außer man nattet auch die Pakete der Firewall selbst, was imho aber keinen Sinn ergibt.

LG, Ralf.

Doch wenn als Source IP die VIP hinterlegt ist kommen die Antworten bei der falschen OPNsense an.

An sich richtig. Nur das NAT darf eben nur für die lokalen Netze durchgeführt werden

[RalfG]

An sich richtig. Nur das NAT darf eben nur für die lokalen Netze durchgeführt werden

Eben, die VIP steht nur als NAT Address drin, nicht als source.

LG, Ralf.

[mimugmail]

Any matched auch

[Domi741]

Moin zusammen,


ich muss den Thread noch mal aus der Versenkung holen.


Ich habe ein funktionierendes HA Setup, jedoch genau wie der Threadopener, das Problem, dass mein Slave keine Verbindung zum Internet kriegt, solange der Master die VIP owned.

Eingerichtet ist es meiner Meinung nach, wie nach der Anleitung vorgegeben.


Im Anhang ein Netzwerkdiagramm und die Outbound NAT Regeln.


Ich meine auch, dass das Ganze mal funktioniert hat und erst nach dem Update auf 21.1 nicht mehr funktionierte.


Liebe Grüße
Dominic

[mimugmail]

ping heise.de kann aufgelöst werden?

[Domi741]

Auf dem Master ja, auf dem Slave nein.Wenn ich jedoch Master und Slave einzeln via NSLookup anspreche von einem PC aus dem LAN und eine interne Adresse abfrage klappt es. Es scheitert also wirklich an jeglicher Kommunikation nach Extern.
In Beiden Firewalls ist als DNS jeweils 127.0.0.1 hinterlegt, da auf beiden der Unbound läuft.


Mir ist aber aufgefallen, wenn ich eine Outbound NAT einrichte mit:

• Interface: WAN
• Source: "This Firewall"
• Target IP: "WAN Address"

alles funktioniert.

Also für mich sieht es so aus, dass auch der Slave sich als VIP dem Gateway zeigt und dadurch die Rückpakete nicht kommen. Kann das auch gerne via Wireshark mal verifzieren.

[mimugmail]

Dann ist dein NAT Screenshot nicht vollständig

[Domi741]

Das habe ich in der Zwischenzeit nur mal zum testen eingefügt. Eigentlich ist die Regel nicht drin. und muss ja anscheinend auch nicht?!

Hatte auch testweise mal „any“ als Source eingetragen, das hat nicht funktioniert. Also bei den Regeln vom screenshot.

Was verbirgt sich denn hinter dem "this Firewall" alias?

[liceo]

Meiner Meinung nach hast du diese Probleme (kein Internet Access auf dem Slave Node) wenn du in der Outbound NAT Rule in "Translation Target" eine VIP nutzt. Ich habe deshalb die "WAN Address" genommen, dann funktioniert das.
Bislang habe  ich keine Probleme mit diesem Setup, ich weiss nicht weshalb in der Doku steht, mal solle die VIP des WAN interfaces als Translation Target nehmen.

[mimugmail]

Das habe ich in der Zwischenzeit nur mal zum testen eingefügt. Eigentlich ist die Regel nicht drin. und muss ja anscheinend auch nicht?!

Hatte auch testweise mal „any“ als Source eingetragen, das hat nicht funktioniert. Also bei den Regeln vom screenshot.

Was verbirgt sich denn hinter dem "this Firewall" alias?

Deiner Fehlerbeschreibung nach hast du ein Outbound NAT für source any auf destination any natten auf die VIP. Wenn die 2te FW jetzt raus will nattet sie die Quelle auf die IP die auf der anderen Firewall liegt.