Hallo an alle,
habe ein spezielles Problem:
Es geht um ein HA-Setup mit 2 OPNSenses, aufgebaut aus "dem Lehrbuch".
WAN hat eine virtuelle öffentliche CARP IP (und 2 normale)
LAN hat mehrere virtuelle CARP IPs (und 2 normale)
Soweit alles gut, nur wenn ein Rechner, der an einer virtuellen IP (LAN) angebunden ist, ein Traceroute macht, bekommt er immer die "physische" IP der ersten OPNSense angezeigt anstatt die der virtuellen. Gibt es da eine Möglichkeit, dies zu ändern?
Outbound NAT ist eingerichtet, ebenso die dazugehörigen floating rules.
Quote from: guenti_r on April 15, 2025, 09:39:02 AMLAN hat mehrere virtuelle CARP IPs (und 2 normale)
Wofür?
1 sollte reichen. Mehrere CARP VIPs produzieren nur unnötigen Traffic im Netzwerk.
Quote from: guenti_r on April 15, 2025, 09:39:02 AMnur wenn ein Rechner, der an einer virtuellen IP (LAN) angebunden ist, ein Traceroute macht, bekommt er immer die "physische" IP der ersten OPNSense angezeigt anstatt die der virtuellen. Gibt es da eine Möglichkeit, dies zu ändern?
Das Interface antwortet immer mit seiner statischen Hardwareadresse. Das ist CARP Standard und lässt sich nicht ändern.
Mit Outbound NAT kannst du nur Verbindungen, die zum Interface raus gehen, beeinflussen, nicht aber die IP, die OPNsense für eigene Antworten nutzt.
Erstmal danke für die Antwort.
Carp-VIPs im Lan, weil Aliases nicht funktionieren und ich hier separieren muss.
Dachte es mir schon, dass dieses Verhalten nicht änderbar ist.
Ist nur unangenehm, wenn ein Kunde die originale Struktur über simples Traceroute herausfinden kann (Sicherheitsthema).
Hier das Ursprungsthema:
https://forum.opnsense.org/index.php?topic=30985.0 (https://forum.opnsense.org/index.php?topic=30985.0)
Quote from: guenti_r on April 15, 2025, 02:01:28 PMCarp-VIPs im Lan, weil Aliases nicht funktionieren und ich hier separieren muss.
Verstehe. Da hab ich was gelernt.
Wieder mal eine ziemliche, unlogische Eigenwilligkeit von OPNsense. Auf anderen Systemen funktionieren Aliase, die auf der CARP VIP aufsitzen, wunderbar und erleichtern das Setup und belasten nicht unnötig das Netzwerk. Beim Failover wandern sämtliche Aliase mit der CARP auf die andere Instanz.
Das es mit Aliasen gar nicht funktioniert ist aber schräg. Ich habe hier Dutzende von Aliasen auf derselben VHID - aber alle nur auf WAN. Ich sehe aber nicht, was da unterschiedlich sein sollte. Die Interface-Namen sind nur Namen.
Kann ich jetzt sofort aber nicht nachbauen. In dem anderen Thread war meine Äußerung eher ein "wenn du eine neue CARP-Adresse willst, brauchst du auch eine neue VHID". Nicht unbedingt "das funktioniert nur so, weil isso". :-)
Gruß
Patrick
Quote from: viragomann on April 15, 2025, 02:42:38 PMVerstehe. Da hab ich was gelernt.
Wieder mal eine ziemliche, unlogische Eigenwilligkeit von OPNsense. Auf anderen Systemen funktionieren Aliase, die auf der CARP VIP aufsitzen, wunderbar und erleichtern das Setup und belasten nicht unnötig das Netzwerk. Beim Failover wandern sämtliche Aliase mit der CARP auf die andere Instanz.
Nur zur Info, die Erkenntnis war im Jahre 2022, eventuell hat sich in der Zwischenheit ja was getan.
@Patrick,
kann das hier jetzt auch grad nicht nachstellen. Damals gings am WAN einwandfrei mit den Aliases (inkl. HA/Failover), am LAN war sofort die Verbindung weg.
Daher DAMALS der Weg über die Carp-Vips.
Nur zur Ergänzung:
Mir geht es eigentlich ja nur darum, einen externen "Störenfried", der permanent mit Traceroute/Tracert mir intern mein Netzwerk scannt und dann blöde Fragen stellt. Per ICMP UDP wird eh nichts angezeigt, per ICMP TCP aber schon.
Was sollte man da von außen herausfinden können?
Wir die CARP VIP angesprochen, antwortet OPNsense mit der Interface-Hardwareadresse (= MAC). Aber wer sieht die schon? Doch nur das nächste Gateway, vermutlich beim ISP.
Die Antwort-IP wäre dennoch die CARP VIP.
Das einzige, für was normalerweise die Interface-IP verwendet wird, sind ausgehende Verbindungen der OPNsense selbst. Das muss aber so sein, jedenfalls im Backup-Modus, ansonsten würden die Antworten auf der falschen Box landen.
Oder habe ich den Problem nicht verstanden?
Nein, von innen.
Es wurde eine öffentliche IP (zB. 92.123.123.123) bereitgestellt (via IP-Alias an der einzigen WAN-CARP-VIP).
Dann gibt es für zB. ein LAN-Netzwerk (zB. 172.16.10.0/24), die LAN-CARP-VIP wär dann 172.16.10.1/24.
Eingehendes & ausgehendes NAT ist so angelegt, dass NUR dieser Adressraum verwendet/erreicht werden kann (auch mit floating rules).
Natürlich haben die "echten" LAN-IPs der OPNSenses einen anderen Adressbereich, zB. 192.168.20.1 & 192.168.20.2.
Wenn ich zB. einen PC an der LAN-CARP-VIP anschliesse mit 172.16.10.100/24 mit Gateway 172.16.10.1, funktioniert alles wunderbar.
Traffic wird einwandfrei rausgenatet und rein.
Wenn man dann aber von diesem PC ein TCP-Traceroute nach 8.8.8.8 absetzt, sieht man leider die 192.168.20.1 anstatt 172.16.10.1 !
Und genau das ist das Problem.
Ich könnte als hauruck-Lösung ICMP deaktivieren oder umleiten, aber dann verliere ich die PMTU-Geschichte.
Quote from: guenti_r on April 15, 2025, 04:26:11 PMNatürlich haben die "echten" LAN-IPs der OPNSenses einen anderen Adressbereich, zB. 192.168.20.1 & 192.168.20.2.
Wieso denn "natürlich"? Im Normalfall sind die beiden fixen Adressen und die CARP-VIP alle aus demselben Netz.
Firewall 1: 192.168.1.2/24
Firewall 2: 192.168.1.3/24
CARP VIP: 192.168.1.1/24
Hab ich auf OPNsense, Cisco, whatever ... überall so. Wie kommt man auf die Idee, das anders zu machen? ;-) Also was soll das bringen?
Quote from: guenti_r on April 15, 2025, 04:26:11 PMWenn man dann aber von diesem PC ein TCP-Traceroute nach 8.8.8.8 absetzt, sieht man leider die 192.168.20.1 anstatt 172.16.10.1 !
Verstehe.
Das Traceroute ist keine durchgehende Verbindung zum Zielserver, sondern die Antwort kommt eben vom nächsten Hop, OPNsense in dem Fall. Da wurde ja gar keine OPNsense IP direkt angesprochen. Sie antwortet nur als Gateway.
Das heißt aber auch, dass es möglich sein müsste, solche Pakete zu natten. Bspw. ein Regel am LAN:
Protocol: ICMP
Source: 127.0.0.1 (od. 127.0.0.0/8)
Destination: 172.16.10.0/24
Translation / target: 172.16.10.1
Jedoch kann damit die Firewall aber keine ICMP Kommunikation ins Zielnetz führen, wenn sie nicht Master ist.
Quote from: Patrick M. Hausen on April 15, 2025, 04:44:31 PMWie kommt man auf die Idee, das anders zu machen? ;-) Also was soll das bringen?
@Patrick,
die beiden fixen IPs und die "Haupt-CARP-VIP" sind natürlich im selben Netz.
Habe aber zusätzliche CARP-VIPs anlegen müssen (mit anderen Netzen), da ja IP-Aliase nicht funktionierten.
Quote from: guenti_r on April 16, 2025, 11:25:09 AMHabe aber zusätzliche CARP-VIPs anlegen müssen (mit anderen Netzen), da ja IP-Aliase nicht funktionierten.
IP-Alias
im selben Netz funktionieren. Das war ja mein Punkt. Wozu Aliase in einem anderen Netz in derselben Broadcast-Domain? Normalerweise hat man eine 1:1 Abbildung von Layer 2 Broadcast Domains und Layer 3 Netzen/Prefixen.
Aliases in einem anderen Subnetz sollten doch ebenfalls möglich sein. Ich würde aber unabhängig von CARP den Sinn hinterfragen.
Quote from: viragomann on April 16, 2025, 12:46:34 PMAliases in einem anderen Subnetz sollten doch ebenfalls möglich sein. Ich würde aber unabhängig von CARP den Sinn hinterfragen.
"Sollte" ist gut. Damals hat das eben nicht funktioniert. Der Sinn war eine seamless Migration bestehender Strukturen.
Hätte ich die Möglichkeit, diese Geschichte komplett neu zu machen, hätte ich diese Probleme nicht.
Werde mir mal eine Teststellung virtualisieren und das Szenario nachspielen, vielleicht funktioniert ja inzwischen das mit den IP-Aliasen auf dem LAN mit CARP.
Quote from: guenti_r on April 15, 2025, 04:26:11 PMNein, von innen.
Es wurde eine öffentliche IP (zB. 92.123.123.123) bereitgestellt (via IP-Alias an der einzigen WAN-CARP-VIP).
Dann gibt es für zB. ein LAN-Netzwerk (zB. 172.16.10.0/24), die LAN-CARP-VIP wär dann 172.16.10.1/24.
Eingehendes & ausgehendes NAT ist so angelegt, dass NUR dieser Adressraum verwendet/erreicht werden kann (auch mit floating rules).
Natürlich haben die "echten" LAN-IPs der OPNSenses einen anderen Adressbereich, zB. 192.168.20.1 & 192.168.20.2.
Wenn ich zB. einen PC an der LAN-CARP-VIP anschliesse mit 172.16.10.100/24 mit Gateway 172.16.10.1, funktioniert alles wunderbar.
Traffic wird einwandfrei rausgenatet und rein.
Wenn man dann aber von diesem PC ein TCP-Traceroute nach 8.8.8.8 absetzt, sieht man leider die 192.168.20.1 anstatt 172.16.10.1 !
Und genau das ist das Problem.
Ich könnte als hauruck-Lösung ICMP deaktivieren oder umleiten, aber dann verliere ich die PMTU-Geschichte.
Also das klingt bei mir nicht nach "aus dem Lehrbuch" gebaut, sondern nach einer ziemlichen Bastellösung. Bin da bei Patricks letztem Post, das sieht für mich eher falsch aus.
Cheers
Quote from: JeGr on April 23, 2025, 03:05:35 PMAlso das klingt bei mir nicht nach "aus dem Lehrbuch" gebaut, sondern nach einer ziemlichen Bastellösung. Bin da bei Patricks letztem Post, das sieht für mich eher falsch aus.
Cheers
Danke für dein Feedback.
Wie würde eine eine "richtigere" Lösung aussehen?
Dedizierte IP-Adressen und CARP-Adressen und Aliase alle aus demselben Netz.
Quote from: Patrick M. Hausen on April 24, 2025, 09:03:05 AMDedizierte IP-Adressen und CARP-Adressen und Aliase alle aus demselben Netz.
Naja, es kann gute Gründe geben, einem Interface Adressen aus unterschiedlichen Subnetzen zuzuweisen. Aber zugegeben, das sollte nur in seltenen Fällen nötig sein und wenn man es macht, sollte man sich der Auswirkungen bewusst sein.
Dann würde ich aber je eine feste Adresse aus jedem der Subnetze zuweisen und dann CARP und Aliase zusätzlich.
Nicht fest aus Subnetz 1 und CARP aus Subnetz 2 ...
Quote from: Patrick M. Hausen on April 24, 2025, 01:30:50 PMDann würde ich aber je eine feste Adresse aus jedem der Subnetze zuweisen
Ja, das ist obligatorisch.
Ich hatte das mal, weil ich vom ISP mehrere kleine WAN Subnetze bekommen hatte und dieser nicht fähig war, die weiteren zu routen...
Quote from: viragomann on April 24, 2025, 02:25:35 PMJa, das ist obligatorisch.
Hast du dafür eine Referenz? Ich mein, kein Widerspruch, aber eher weil "fühlt sich richtig an". Doku wäre toll :-)
Referenz kann ich nicht nennen.
Das besagte System hatte ich vor 12 Jahren mit pfSense eingerichtet und bis vor 5 Jahren betrieben. Die Infos stammen also von pfSense und aus früherer Zeit.
Ja, demnach musste in jedem Subnetz eine Interface-IP zugewiesen werden (IP Alias) und dann konnte eine CARP VIP zugewiesen werden.
Aber wenn ich so nachdenke, das dürfte heute gar nicht mehr gelten. Seit Jahren ist es ja legitim, eine CARP VIP in einem anderen Subnetz zu verwenden. Bspw. wenn nur 1 WAN IP zur Verfügung steht, so kann das Interface auch in einem privaten Subnetz sein. Dabei gibt es nur Einschränkungen bezüglich Verbindungen der Backup-FW.
Wichtig scheint also nur zu sein, dass die zusammengehörigen Interfaces IPs im selben Subnetz haben.