HA Setup mit Virtual-IP Traceroute generelle Frage

[guenti_r]

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.

[viragomann]

LAN hat mehrere virtuelle CARP IPs (und 2 normale)

Wofür?
1 sollte reichen. Mehrere CARP VIPs produzieren nur unnötigen Traffic im Netzwerk.

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?

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.

[guenti_r]

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

[viragomann]

Carp-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.

[Patrick M. Hausen]

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

[guenti_r]

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.

Nur zur Info, die Erkenntnis war im Jahre 2022, eventuell hat sich in der Zwischenheit ja was getan.

[guenti_r]

@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.

[guenti_r]

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.

[viragomann]

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?

[guenti_r]

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.

[Patrick M. Hausen]

Natü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?

[viragomann]

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 !

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.

[guenti_r]

Wie 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.

[Patrick M. Hausen]

Habe 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.

[viragomann]

Aliases in einem anderen Subnetz sollten doch ebenfalls möglich sein. Ich würde aber unabhängig von CARP den Sinn hinterfragen.