Upgrade HA Nodes - kurze Downtime & low Risk?

[JeGr]

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.

Dann habt ihr die Doku wahrscheinlich nicht vollständig gelesen. Die Firewall selbst - also der 1. oder 2. Node - braucht Regeln, dass er von lokal via SEINER IP raus NATtet aber das Netz HINTER der Firewall - also das LAN net bspw. - muss als NAT Adresse die VIP haben, damit bei einem Failover das LAN eben keinen Ausfall bemerkt weil das NATting nahtlos die andere Firewall übernimmt.

M.E. kommt das von dem ganzen Automatisch/Hybrid Outbound NAT "Quark" ;) Nicht böse gemeint und ich weiß dass man Defaults braucht, aber wenn der Default wäre die Regeln so zu erzeugen, wie es passiert, wenn man das erste Mal von auto auf manual NAT umstellt, dann wäre damit vielen besser geholfen (und gelernt) als bei der Automatik. Aber das ist nur mein persönlicher Take davon weil ich das immer wieder bei Kunden "reparieren" darf :)

Anyway wie es @mimugmail auch schon sagt (bei CARP ist IMHO manual outbound NAT zu setzen) lässt man die 127.0.0.1 und ::1 Adressen in Ruhe und ändert nur die LANnet outbound NAT rule von WAN address auf die WAN VIP und alles fluppt wie es soll.

Cheers

[liceo]

also der 1. oder 2. Node - braucht Regeln, dass er von lokal via SEINER IP raus NATtet aber das Netz HINTER der Firewall

Ja, das ist klar.

M.E. kommt das von dem ganzen Automatisch/Hybrid Outbound NAT "Quark"

Die NAT Rules sind bei mir manuell gesetzt, und das war auch nicht meine Frage.

Bei mir funktioniert der Failover ohne merklichen Paketverlust, auch wenn ich NICHT die WAN CARP VIP bei "Translation Target" eingetragen habe sondern einfach die "real IP" das WAN Interfaces nutze.

Wenn ich die VIP verwende, funktioniert der Failover auch, aber der Slave node hat keine outbound Connectivity Richtung Internet.

Also meine Frage(n) nochmal:
1. Was ist der Vorteil, wenn ich (wie in der Doku beschrieben) die CARP VIP für das Translation Target in der NAT Rule verwende?

2. Wie genau muss die NAT Rule aussehen, damit auch der Slave Node Internet Connectivity hat (zum updaten).

[JeGr]

> Bei mir funktioniert der Failover ohne merklichen Paketverlust, auch wenn ich NICHT die WAN CARP VIP bei "Translation Target" eingetragen habe sondern einfach die "real IP" das WAN Interfaces nutze.

"ohne merklich" ist "relativ". Faktisch ist es so, dass es immer einen Bruch gibt, wenn ein Failover in eine Kommunikation eingreift und sich die externe IP ändert. Vielleicht hast du in deinem Fall keine Realtime Anwendungen oder Sachen die ähnlich Streaming Traffic haben, aber ohne die Kommunikation über die VIP zu machen - auch extern - gibt es da _immer_ einen Bruch in der Verbindung. Vielleicht liegt es auch mit an deiner Konstellation, dass du hinter dem Router nochmal ein privates Transfernetz hast und deshalb sich direkt die externe IP nicht ändert, sondern nur der direkte Empfänger. Man kann Glück haben, dass man hauptsächlich sowas unkritisches hat wie HTTP/S Verbindungen denen das nach Refresh recht egal war, aber für alles was dauerhafte Verbindungen hält wäre ein Failover sonst ein harter Break. Und nicht jede Anwendung/Service ist intelligent genug da schnell einen reconnect zu machen. Aber selbst wenn es ohne WAN auf VIP zu setzen bei dir läuft, hast du mind. asymmetrisches Routing im Upstream Segment und das kann seine eigenen Bugs mitbringen (da du abgehend von deiner IF Adresse rausgehst, reinkommend der Traffic aber auf der VIP wieder ankommt).

1) es ist kein "Vorteil", es muss so gebaut wegen aus genau obigen Grund damit alles sauber Failovern kann ohne Abbrüche zu haben. Alles andere ist schlicht "make or break" und kann gut gehen oder nicht, ist aber sehr sehr abhängig von der tatsächlichen Situation. Abbrüche gibt es aber dann sicherlich auch wenn es vielleicht kurze sind. Bei korrektem Setup merkt man nichts davon im Netz hinter der Firewall. Wir hatte da zu Demozwecken schon Videos laufen lassen oder aktive RDP Sessions drüber. Da gibts vllt. nen minimalkurzen Ruckler, das wars dann aber. Wechselt aber die externe Adresse bricht ggf. die gesamte Verbindung ab oder muss reconnecten.

2) Genauso wie wir es jetzt schon mehrfach diskutiert haben. Lokales System / Localhosts über lokale IP, Netze dahinter via VIP. Wenn ansonsten dein Secondary kein Internet hat, dann ist  am Primary/Secondary Setup vielleicht noch zusätzlich was anderes nicht korrekt konfiguriert oder dein Router davor (Upstream) macht merkwürdige Mucken. Das kann dann ggf. eher DNS Problem als tatsächliches IP sein, da brauchen wir aber mehr Input was nicht geht und welche Config.

Also sind das im Normalfall (mit WAN/LAN) 3 Regeln:

127.0.0.0/8 Port any nach any Port 500 via WANaddress static-port
127.0.0.0/8 Port any nach any Port any via WANaddress (ohne static port)
<LANnet> Port any nach any Port any via VIPaddress

Damit kann localhost/vom lokalen System alles über die eigene IP raus, alles vom LAN wird brav über die VIP geschickt.

Cheers

[Domi741]

Wofür die NAT Regeln sind, auch mit der VIP ist mir bewusst und es funktioniert ja auch. Mir ist ja auch bewusst dass die VIP solange sie vom Master "geblockt" wird für den slave nicht greift, etc.

In der Online Hilfe steht halt explizit

Go to Firewall ‣ NAT ‣ Outbound. Choose manual outbound nat rule generation. On this page create the a rule originating from the 192.168.1.0/24 network to use the CARP virtual interface (172.18.0.100). The rule should contain the following:

Das habe ich auch äquivalent zu meinem Netzwerk gemacht.
Vielleicht sollte die Anleitung noch entsprechend um die Regeln

127.0.0.0/8 Port any nach any Port 500 via WANaddress static-port
127.0.0.0/8 Port any nach any Port any via WANaddress (ohne static port)

ergänzt werden.

[JeGr]

Ich vermute das Problem an der Online Hilfe ist, dass es noch auf dem alten Verhalten aufsetzt, dass bei Umschalten auf "Manuell" die aktuellen Regeln "rausgeschrieben" wurden und man dann einfach die Regeln editieren/ersetzen/ausmisten konnte. Das ist aktuell nicht (mehr) der Fall. Finde ich auch schade, dass es so ist (oder es ist verbuggt).

[liceo]

Ich referenziere mich auf diese Doku: https://docs.opnsense.org/manual/how-tos/carp.html

Vielleicht habe ich das auch falsch verstanden. Ich habe das eben nochmals getestet: Wenn ich die CARP VIP verwende, dann kann der secondary Node nicht mehr ins Internet, wenn er Status Backup hat (nein es ist kein DNS Problem).
Sobald ich bei der Outbound NAT Rule die "WAN Address" verwende, funktioniert auch der Backup Node und ich kann diesen updaten solange er "Backup" ist (und umgekehrt).

Im Anhang nochmals die Rule, welche funktioniert und einmal die Rule mit den CARP VIPs als target, welche das beschriebene Problem verursacht.

[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

...

[JeGr]

@mimugmail Danke dass dus nochmal schreibst!

Also sind das im Normalfall (mit WAN/LAN) 3 Regeln:

127.0.0.0/8 Port any nach any Port 500 via WANaddress static-port
127.0.0.0/8 Port any nach any Port any via WANaddress (ohne static port)
<LANnet> Port any nach any Port any via VIPaddress

Damit kann localhost/vom lokalen System alles über die eigene IP raus, alles vom LAN wird brav über die VIP geschickt.

Cheers

Ich frage mich manchmal, warum ich mir die Mühe mache und das möglichst klar beschreibe, wenn dann als Antwort kommt "Nein! Das geht so bei mir nicht!" - und im Screenshot ist dann lediglich EINE(!) NAT Regel mit * drin - und nicht die 3 wie von mir beschrieben... (und die 3. nur fürs interne Netz...) :(

NEIN mit * geht das auch nicht und man soll auch nicht ausgehend einfach alles NATten. Das ist doch irgendwo auch logisch!

[Domi741]

Ich vermute das Problem an der Online Hilfe ist, dass es noch auf dem alten Verhalten aufsetzt, dass bei Umschalten auf "Manuell" die aktuellen Regeln "rausgeschrieben" wurden und man dann einfach die Regeln editieren/ersetzen/ausmisten konnte. Das ist aktuell nicht (mehr) der Fall. Finde ich auch schade, dass es so ist (oder es ist verbuggt).

Ich habe das HA damals mit 19.7 in Betrieb genommen und die Probleme traten erst nach dem Update auf 21.1 auf. Was auch deine beschriebene Änderung im Verhalten erklären würde.

Aber bei mir funktioniert es nun und es ist auch logisch. :)

[Patrick M. Hausen]

@JeGr ich baue gerade etwas ähnliches. Was ist der Sinn dieser Regel?

127.0.0.0/8 Port any nach any Port 500 via WANaddress static-port

Werden denn die IKE-Pakete tatsächlich von 127.0.0.1 aus ausgehend verschickt und nicht von WANaddress?
Ich versuche bei mir gerade:

WANaddress/32 Port any nach any Port 500&4500 via VIP static-port

Denn ich will ja, dass meine IPsec-Peers die VIP benutzen und nicht die WANaddress.

Der Rest ist klar. Outbound NAT nur für die tatsächlich auf LAN (und evtl. OPT1, OPT2, ...) liegenden Netze.

Oder funktioniert 127.0.0.0/8 als "magischer Alias" für allen lokal erzeugten Traffic?


Gruß & danke
Patrick

[liceo]

Sorry, tut mir leid @JeGr, ich sehe: wer lesen kann ist klar im Vorteil (shame on me...). Wenn du noch Nerven hast, kannst du mir schnell noch sagen, wie die Rules aussehen müssen bei zwei WAN uplinks und mehreren lokalen Netzen? So wie ich das verstanden habe würde das wie folgt aussehen, ist das korrekt?:

Interface    Source          SourcePort    Destination    Destination Port    NAT Address    NAT Port    Static Port
--------------------------------------------------------------------------------------------------------------------------
WAN1        127.0.0.0/8   *                  *                  *                         WAN1 Address   *               500
WAN1        127.0.0.0/8   *                  *                  *                         WAN1 Address   *               NO
WAN1        LAN              *                  *                  *                         WAN1 VIP          *               NO
WAN2        127.0.0.0/8   *                  *                  *                         WAN2 Address   *               500
WAN2        127.0.0.0/8   *                  *                  *                         WAN2 Address   *               NO
WAN2        LAN              *                  *                  *                         WAN2 VIP          *               NO

[JeGr]

@JeGr ich baue gerade etwas ähnliches. Was ist der Sinn dieser Regel?

127.0.0.0/8 Port any nach any Port 500 via WANaddress static-port

Werden denn die IKE-Pakete tatsächlich von 127.0.0.1 aus ausgehend verschickt und nicht von WANaddress?
Ich versuche bei mir gerade:

WANaddress/32 Port any nach any Port 500&4500 via VIP static-port

Denn ich will ja, dass meine IPsec-Peers die VIP benutzen und nicht die WANaddress.

Der Rest ist klar. Outbound NAT nur für die tatsächlich auf LAN (und evtl. OPT1, OPT2, ...) liegenden Netze.

Oder funktioniert 127.0.0.0/8 als "magischer Alias" für allen lokal erzeugten Traffic?


Gruß & danke
Patrick

Moin Patrick,

tatsächlich ist das ein Punkt, den ich mich auch schon gefragt aber noch nie die Zeit hatte zu messen oder durchzutesten ;) Ältere OPNsense Installationen sowie pfSense erstellt die Localhost Regeln grundsätzlich mit. OB die tatsächlich für IPsec so überhaupt genutzt werden ist tatsächlich fraglich, es könnte auch aus der Tatsache stammen, dass im Auto-Mode grundsätzlich für alle angelegten Netze udp/500 static Outbound Rules erzeugt werden und es daher auch welche für Localhost gibt. Ich habe diese tatsächlich meist einfach unangetastet übernommen (auch weil man damit eine Vorlage hat für static port Regeln).

Ich würde mutmaßen, dass die tatsächlich für den "normalen" IPsec Betrieb nie zum Einsatz kommt, weil hier das Interface mitkonfiguriert wird und dann die ausgewählte IP/VIP von dem Interface genutzt wird. Da diese in den allermeisten Fällen überhaupt nicht geNATtet wird (warum auch, kann ja direkt kommunizieren) braucht es hier keine NAT Regel und kein static Port (da kein NAT stattfindet). Es könnte aber auch durchaus sein, dass es historisch irgendwann mal vorkam/ging, dass man IPsec an Localhost gebunden hat und darüber kommuniziert wurde. Da muss ich aber passen, das wüsste ich jetzt auch nicht.

> Denn ich will ja, dass meine IPsec-Peers die VIP benutzen und nicht die WANaddress.

Genau, aber das übernimmt Strongswan ja selbst durch die IPsec Konfiguration, welches Interface und welche IP (die VIP) ausgewählt ist. Andernfalls würde auch das Failover nicht klappen weil ständig beiden versuchen den Tunnel aufzubauen, wenn sie nicht die VIP nutzen und den CARP Status abfragen.

> Oder funktioniert 127.0.0.0/8 als "magischer Alias" für allen lokal erzeugten Traffic?

Wie gesagt noch nie wirklich so tief getestet, würde aber mal platt sagen "nö" :D
Grüße in die Stadt (oder ins Homeoffice ;) )!

Cheers
\jens

[JeGr]

Sorry, tut mir leid @JeGr, ich sehe: wer lesen kann ist klar im Vorteil (shame on me...).

So lange es am Ende denn jetzt funktioniert haben wir alle was davon :)

Interface    Source          SourcePort    Destination    Destination Port    NAT Address    NAT Port    Static Port
--------------------------------------------------------------------------------------------------------------------------
WAN1        127.0.0.0/8   *                  *                  *                         WAN1 Address   *               500
WAN1        127.0.0.0/8   *                  *                  *                         WAN1 Address   *               NO
WAN1        LAN              *                  *                  *                         WAN1 VIP          *               NO
WAN2        127.0.0.0/8   *                  *                  *                         WAN2 Address   *               500
WAN2        127.0.0.0/8   *                  *                  *                         WAN2 Address   *               NO
WAN2        LAN              *                  *                  *                         WAN2 VIP          *               NO

OK für Dual WAN würde es nach "alter Methode" bei Umwandlung auf "manuell" je 2 Regeln für Localhost pro Interface geben - wie du sie auflistest. Normalerweise waren da noch zusätzliche Regeln für Localhost v6 drin - also ::1/128 aber das müsste sich auch durch das Loopback net zusammenfassen lassen. Ansonsten braucht es pro Netz/Alias und WAN dann eine Regel. Also für ein LAN 2 Regeln für WAN1 und WAN2 wie du es korrekt auflistest.

Wenn mehr interne Netze dazukommen, kannst du auch statt LAN direkt ein Netz Alias reinpacken mit allen internen Netzen um dann Regeln zu minimieren, dann kommt man mit einer pro Interface - also zwei - problemlos hin. Wichtig ist eben NIE einfach "*" oder "any" zu nutzen, weil man sonst auch jeglichen anderen Traffic den man gar nicht NATten möchte auf die angegebene Adresse umschreibt, weswegen dein Standby Node dann nicht ins Netz rauskam. Auch bei Public-IP DMZ Netzen bspw. ist das tödlich, da man dort ja extra öffentliche IPs vergibt und dann mit einer ungeschickten Regel plötzlich alle Server die eine eigene IP hätten doch wieder auf die Firewall Adresse umschreibt.

Cheers
\jens

Edit: gerade mal kurz durchgetippt. Habe auf der Testinstanz zwar leider keinen Cluster bei dem ichs testen könnte, ändert sich aber hoffentlich bald. Aber in "Internal_net" sind quasi alle LAN Netze enthalten (praktisch wenns anfängt mehr zu werden, oder mal ggf. noch VPN Einwahlbereiche mit dazunehmen will damit diese auch über die Firewall ins Internet kommen) und in den entsprechenden VIPs natürlich die VIP auf den entsprechenden Interface - in meinem Fall je einmal Versatel und Vodafone.

[liceo]

Wenn mehr interne Netze dazukommen, kannst du auch statt LAN direkt ein Netz Alias reinpacken

Gute Idee, ich habe mehrere lokale Netze welche ich so gruppiert habe. Vermutlich vergesse ich dann ein zukünftiges Netz in die Gruppe zu schmeissen ;.)

Scheint alles soweit zu funktionieren, ich werde noch ein paar Failover Tests machen. Vielen Dank nochmals!

Anbei mein Ruleset ("Swisscom" ist der zweite WAN Uplink)

[atom]

@JeGr ich baue gerade etwas ähnliches. Was ist der Sinn dieser Regel?

127.0.0.0/8 Port any nach any Port 500 via WANaddress static-port

Werden denn die IKE-Pakete tatsächlich von 127.0.0.1 aus ausgehend verschickt und nicht von WANaddress?
Ich versuche bei mir gerade:

WANaddress/32 Port any nach any Port 500&4500 via VIP static-port

Denn ich will ja, dass meine IPsec-Peers die VIP benutzen und nicht die WANaddress.

Der Rest ist klar. Outbound NAT nur für die tatsächlich auf LAN (und evtl. OPT1, OPT2, ...) liegenden Netze.

Oder funktioniert 127.0.0.0/8 als "magischer Alias" für allen lokal erzeugten Traffic?


Gruß & danke
Patrick

Moin Patrick,

tatsächlich ist das ein Punkt, den ich mich auch schon gefragt aber noch nie die Zeit hatte zu messen oder durchzutesten ;) Ältere OPNsense Installationen sowie pfSense erstellt die Localhost Regeln grundsätzlich mit. OB die tatsächlich für IPsec so überhaupt genutzt werden ist tatsächlich fraglich, es könnte auch aus der Tatsache stammen, dass im Auto-Mode grundsätzlich für alle angelegten Netze udp/500 static Outbound Rules erzeugt werden und es daher auch welche für Localhost gibt. Ich habe diese tatsächlich meist einfach unangetastet übernommen (auch weil man damit eine Vorlage hat für static port Regeln).

Ich würde mutmaßen, dass die tatsächlich für den "normalen" IPsec Betrieb nie zum Einsatz kommt, weil hier das Interface mitkonfiguriert wird und dann die ausgewählte IP/VIP von dem Interface genutzt wird. Da diese in den allermeisten Fällen überhaupt nicht geNATtet wird (warum auch, kann ja direkt kommunizieren) braucht es hier keine NAT Regel und kein static Port (da kein NAT stattfindet). Es könnte aber auch durchaus sein, dass es historisch irgendwann mal vorkam/ging, dass man IPsec an Localhost gebunden hat und darüber kommuniziert wurde. Da muss ich aber passen, das wüsste ich jetzt auch nicht.

> Denn ich will ja, dass meine IPsec-Peers die VIP benutzen und nicht die WANaddress.

Genau, aber das übernimmt Strongswan ja selbst durch die IPsec Konfiguration, welches Interface und welche IP (die VIP) ausgewählt ist. Andernfalls würde auch das Failover nicht klappen weil ständig beiden versuchen den Tunnel aufzubauen, wenn sie nicht die VIP nutzen und den CARP Status abfragen.

> Oder funktioniert 127.0.0.0/8 als "magischer Alias" für allen lokal erzeugten Traffic?

Wie gesagt noch nie wirklich so tief getestet, würde aber mal platt sagen "nö" :D
Grüße in die Stadt (oder ins Homeoffice ;) )!

Cheers
\jens

Ich habe den Post zum Anlass genommen, mal einfach die NAT-Regeln für IPsec zu löschen.
Die IPsec-Tunnel funktionieren auch ohne einwandfrei und die Pakete gehen über die VIP IP raus.