Hi zusammen
Ich überlege mir, wie ich den Upgrade-Prozess von einem HA-Pair verbessern könnte. Um die Updates herunterzuladen und zu installieren, benötigt der Node ja Internet Access: Das heisst ich kann den Upgrade nur auf dem aktiven Node durchführen (CARP Master). Gibt es eine Möglichkeit die Upgrade Sequenz wie folgt durchzuführen:
- Patching des sekundären Node (CARP Backup) und reboot
- Temporäres Deaktivieren von CARP auf dem primären Node > Failover auf den sekundären node (auf neue Version)
- Testing...
- Patching des primären Node (ist jetzt CARP Backup) und reboot
- Nach dem Reboot wird der primäre Node wieder CARP Master
So könnten die opnsense HA-Pairs mit einer minimalen downtime gepatched werden.
Ich schließe mich liceo "Fragestellung" an.
Zumal in der Dokumentation da Szenario genau so beschrieben ist, es aber praktisch nicht funktioniert.
https://wiki.opnsense.org/manual/how-tos/carp.html#example-updating-a-carp-ha-cluster
...genau! Es würde schon helfen, einfach die Updates herunterladen zu können und eine "offline" installation/reboot zu machen.
Ich mache es genauso. Warum sollte das nicht funktionieren ?
QuoteIch mache es genauso. Warum sollte das nicht funktionieren ?
OK, aber wie gehst du genau vor? Gemäss Manual müsste das ja der erste Schritt sein:
QuoteUpdate your secondary unit and wait until it is online again
Um den BACKP Node (secondary) patchen zu können, muss ich ihn ja erst zum Master machen. Ansonsten hat der Node ja kein Internet-Zugriff (weil das WAN VIP auch auf dem MASTER aktiv ist)
Ich kann mich direkt am Backup-Node anmelden. Dafür habe ich mir Wireguard auf dem backup-Node konfiguriert.
versteh ich nicht oder hast du nur eine externe IP?
Wenn du die Config wie folgt hast:
fw1 (WAN -IP1)
fw2 (WAN-IP2)
fwcluster (WAN-IP3)
dann haben alle Nodes Internet Access.
Ralf.
Das logische Netz sieht so aus... (siehe Anhang)
Wenn Du aus Sicherheitsgründen den WAN-Zugang des Backupservers nicht für die Anmeldung öffnen willst, musst Du Dir eine Möglichkeit schaffen per ipsec, wireguard o.a. Remote auf den Backup-Server zu kommen.
Natürlich kann ich auf den Backup-Node connecten, der hat ja seine eigene phyische IP im LAN. Das Problem ist: Der Backup Node kann nicht ins internet connecten während er im CARP Status Backup ist.
Versteh ich trotzdem nicht,
wenn der Backup eine eigene IP im WAN hat und das gw richtig gesetzt ist, kann ich auf den von außen connecten und er auch ins Web für Updates etc. auch im Status Backup.
Ralf.
Hi Ralf
Hast du denn auf den Gateways > Single die IPs der Physischen WAN Interfaces genommen? Ich habe die CARP VIP eingetragen, dann ist klar, wieso der BACKUP Node keinen Internet Uplink hat..
Auf dem Gateways->Single
Interface: WAN
IP-Adress: das des Upstream Routers (Provider)
(x) bei Upstream Gateway
Bei "Gateway" kommt keine Adresse aus Deinen CARP-IPs hin, sondern das nächste Gateway.
Beispiel:
WAN-FW1: 10.10.10.1
WAN-FW2. 10.10.10.2
WAN-CARP: 10.10.10.3
WAN-GW: 10.10.10.254
Soll das Swisscom DSL ein Fallback Zugang sein?
Wenn ja, solltest du noch eine Gateway Group (nebst Regeln) einrichten.
Sorry, da habe ich mich falsch ausgedrückt (man sollte halt nicht mehrere Dinge gleichzeitig machen ;D). 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.
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).
Quote from: liceo on March 25, 2021, 05:09:48 PM
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
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
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.
Quote from: RalfG on March 26, 2021, 01:28:08 PM
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
Quote from: lfirewall1243 on March 26, 2021, 01:29:25 PM
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.
Any matched auch
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
ping heise.de kann aufgelöst werden?
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.
Dann ist dein NAT Screenshot nicht vollständig ;)
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?
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.
Quote from: Domi741 on September 26, 2021, 10:04:09 PM
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.
Quote from: liceo on September 26, 2021, 10:34:45 PM
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
Quote
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.
Quote
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).
> 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
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
QuoteGo 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
Quote
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.
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 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.
Quote from: mimugmail on March 26, 2021, 06:35:20 AM
Quote from: liceo on March 25, 2021, 05:09:48 PM
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
...
@mimugmail Danke dass dus nochmal schreibst!
Quote from: JeGr on September 27, 2021, 11:27:56 AM
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!
Quote from: JeGr on September 28, 2021, 06:34:18 PM
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. :)
@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
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
Quote from: pmhausen on September 30, 2021, 01:08:02 PM
@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
Quote from: liceo on September 30, 2021, 07:06:57 PM
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 :)
Quote from: liceo on September 30, 2021, 07:06:57 PM
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.
QuoteWenn 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)
Quote from: JeGr on October 01, 2021, 09:12:04 AM
Quote from: pmhausen on September 30, 2021, 01:08:02 PM
@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.
Da bin ich jetzt auch angekommen. VIP für IPsec verwenden und alles funktioniert wie gewünscht.
Nu hab ich noch einen Punkt für @JeGR - wie ist denn die Idee bei Services wie z.B. BIND?
Der hat ja die unangenehme Eingenschaft, dass er an alle Interface-Adressen mit /32 bindet. Wenn also beim Start von BIND die CARP-Adresse nicht da ist, dann lauscht der auf der auch nicht.
Ich bin hier darauf angewiesen, BIND zu verwenden, kann den auch nicht auf 127.0.0.1 binden und Unbound vorschalten - Stichwort Zonetransfers, must have.
Soll ich den vielleicht trotzdem auf 127.0.0.1 nageln und für alle HA-Interfaces ein NAT-Portforwarding für Port 53 einrichten?
Liebe Grüße
Patrick
Quote from: pmhausen on October 03, 2021, 06:19:31 PM
Soll ich den vielleicht trotzdem auf 127.0.0.1 nageln und für alle HA-Interfaces ein NAT-Portforwarding für Port 53 einrichten?
So habe ich es nun gemacht und es funktioniert.
Ah jetzt erst gesehen - sorry. Aber ja, wäre auch exakt meine Idee gewesen :D