15
Routing-Problem bei Virtualisierungshost
Hallo zusammen,
ich habe da gerade ein kleines Problem und hoffe auf eure Hilfe.
Für diverse Test- und Bastelarbeiten habe ich mir einen Server angemietet. Dieser Server hat 2 IP-Adressen. Die erste(Haupt-IP) zeigt auf den Proxmox-Virtualisierungshost. Auf diesem ist eine Bridge auf den eth0 eingerichtet, der die erste IP zugewiesen ist. Das funktioniert soweit ohne Probleme.
Nun habe ich eine virtuelle pfSense aufgesetzt, mit 3 NICs, NIC1 stellt die Internetverbindung via NAT her, da die zusätzliche IP kein Gateway hat. NIC2 stellt die Internetverbindung auf eine Interne Bridge zur Verfügung und NIC3 hat die zweite öffentliche IP zugewiesen bekommen mit der 32er Netzmaske.
IPv4-Forwarding ist auf dem Virtualisierungshost aktiv.
Leider ist die pfSense nicht unter der zweiten öffentlichen IP zu erreichen (zumindest nicht von ausserhalb). Innerhalb des pfSense-Client-Netzes reagiert die pfSense auch auf die zweite öffentliche IP.
Hat jemand eine Idee, wo ich mit der Fehlersuche beginnen sollte, bzw, wo mein Fehler liegt?
Danke schonmal für die Hilfe!
Beste Grüße
Berthold
ich habe da gerade ein kleines Problem und hoffe auf eure Hilfe.
Für diverse Test- und Bastelarbeiten habe ich mir einen Server angemietet. Dieser Server hat 2 IP-Adressen. Die erste(Haupt-IP) zeigt auf den Proxmox-Virtualisierungshost. Auf diesem ist eine Bridge auf den eth0 eingerichtet, der die erste IP zugewiesen ist. Das funktioniert soweit ohne Probleme.
Nun habe ich eine virtuelle pfSense aufgesetzt, mit 3 NICs, NIC1 stellt die Internetverbindung via NAT her, da die zusätzliche IP kein Gateway hat. NIC2 stellt die Internetverbindung auf eine Interne Bridge zur Verfügung und NIC3 hat die zweite öffentliche IP zugewiesen bekommen mit der 32er Netzmaske.
IPv4-Forwarding ist auf dem Virtualisierungshost aktiv.
Leider ist die pfSense nicht unter der zweiten öffentlichen IP zu erreichen (zumindest nicht von ausserhalb). Innerhalb des pfSense-Client-Netzes reagiert die pfSense auch auf die zweite öffentliche IP.
Hat jemand eine Idee, wo ich mit der Fehlersuche beginnen sollte, bzw, wo mein Fehler liegt?
Danke schonmal für die Hilfe!
Beste Grüße
Berthold
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 237649
Url: https://administrator.de/forum/routing-problem-bei-virtualisierungshost-237649.html
Ausgedruckt am: 11.04.2025 um 14:04 Uhr
15 Kommentare
Neuester Kommentar
Hast du denn den virtuellen PFsense ins "Netz" gehängt?
Ja, habe ich, der ist auf der öffentlichen bridge eingebunden und aktiv...
Kleine Ergänzung: Ich habe testweise mal die zweite IP zusätzlich dem Virtualisierungshost zugewiesen und von der pfSense entfernt. Dann klappt der Zugriff(Auf den Virtualisierungshost) einwandfrei...
Kleine Ergänzung: Ich habe testweise mal die zweite IP zusätzlich dem Virtualisierungshost zugewiesen und von der pfSense entfernt. Dann klappt der Zugriff(Auf den Virtualisierungshost) einwandfrei...
Okay, ich habe noch einen Anhaltspunkt für den Fehler gefunden.
Laut Traceroute kommt die Anfrage über den Default-Gateway, geht zum Virtualisierungshost und der gibt den wieder an den Default-Gateway zurück, so dass hier eine Endlosschleife entsteht...
Müsste ich jetzt noch manuell eine Route für die zweite öffentliche IP setzen, so dass diese zur Bridge geht und nicht zum default-gateway?
Und wenn ja: wie konfiguriere ich das? Denn in der Bridge-Konfiguration ist ja das default-gateway festgelegt...
Laut Traceroute kommt die Anfrage über den Default-Gateway, geht zum Virtualisierungshost und der gibt den wieder an den Default-Gateway zurück, so dass hier eine Endlosschleife entsteht...
Müsste ich jetzt noch manuell eine Route für die zweite öffentliche IP setzen, so dass diese zur Bridge geht und nicht zum default-gateway?
Und wenn ja: wie konfiguriere ich das? Denn in der Bridge-Konfiguration ist ja das default-gateway festgelegt...
Leider ist die pfSense nicht unter der zweiten öffentlichen IP zu erreichen (zumindest nicht von ausserhalb)
Das ist auch normal, denn auf der pfSense ist wie bei einer Firewall üblich das ALLES verboten ist was nicht explizit erlaubt ist !Die grundlegende Frage die sich stellt was der tiefere Sinn der 2ten WAN IP sein soll ?? Oder wolltest du ein 1:1 NAT auf der FW nach innen machen damit ?
Ohne adäquate FW Regeln wirst du also nix.
Problam kann (muss aber nicht) an der Bridge Einrichtung liegen. Wie das richtig zu machen ist kannst du in diesem Tutorial nachlesen:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion) --> "LAN WLAN im gleichen Netz"
Gateway zurück, so dass hier eine Endlosschleife entsteht...
...zusätzlich hast du also auch noch ein Routing Problem !Routen musst du keine einzige setzen, denn die pfSense "kennt" ja alle IP Netze die direkt auf ihr definiert sind.
Die einzige Route die sie braucht ist die Default Route zum Provider Router ins Internet !
Hallo aqui,
Die pfSense hat allerdings selbst behauptet, dass das Konfigurationsinterface über diese NIC/Adresse erreichbar sei. Das Interface läuft als OPT1 und ist noch nicht weiter konfiguriert. Hab ich da jetzt was falsch verstanden?
Ich habe es jetzt mal auf dem Virtualisierungshost mit einem route add -host (2.öffentliche IP) dev vmbr0 probiert... Jetzt habe ich zwar keine Schleife mehr, aber ich erreiche immer noch nix
Der Sinn der zweiten IP ist folgender:
Die erste IP läuft zu auf dem Virtualisierungshost auf, diese wollte ich ausser zur Konfiguration desselbigen auch nicht weiter verwenden.
Für die Spielereien habe ich eine zweite IP, die direkt auf die pfSense laufen sollte, damit ich mit der pfSense die Ports so weiterleiten kann, wie ich es gern mag...
Die pfSense hat allerdings selbst behauptet, dass das Konfigurationsinterface über diese NIC/Adresse erreichbar sei. Das Interface läuft als OPT1 und ist noch nicht weiter konfiguriert. Hab ich da jetzt was falsch verstanden?
Ich habe es jetzt mal auf dem Virtualisierungshost mit einem route add -host (2.öffentliche IP) dev vmbr0 probiert... Jetzt habe ich zwar keine Schleife mehr, aber ich erreiche immer noch nix
Der Sinn der zweiten IP ist folgender:
Die erste IP läuft zu auf dem Virtualisierungshost auf, diese wollte ich ausser zur Konfiguration desselbigen auch nicht weiter verwenden.
Für die Spielereien habe ich eine zweite IP, die direkt auf die pfSense laufen sollte, damit ich mit der pfSense die Ports so weiterleiten kann, wie ich es gern mag...
OPT1 wäre ein eigenständiges IP Segment als Interface auf der FW. Wenn der Haken bei "enable" nicht gesetzt ist ist es eh inaktiv und nicht verwendbar.
Ein route add Kommando ist aus den obigen Gründen Unsinn. Deshalb löst es auch nicht dein Problem...kannst du deshalb gleich wieder löschen.
Hilfreich wäre hier eine kleine Topologie Zeichnung WAS WIE verschaltet ist und WAS du WIE erreichen willst an der FW... ?!
Generell ist die Einrichtung ja kein Problem.
An der NIC des vHosts ist deine öffentliche IP, die muss im Bridge Modus mit der vNIC der pfSense verbunden sein, da kommt dann die 2te öffentliche IP drauf.
WAN Default Gateway und DNS wird so eingestellt wie es auch auf der NIC des vHosts gemacht ist.
Generell ist der WAN Port der FW wie es auch sein soll komplett dicht...Management ist also nicht möglich.
Hier solltest du eine Regel erstellen die inbound Port 443 auf die WAN IP erlaubt, damit kannst du die FW dann über ihr GUI managen.
Wenn das klappt solltest du die Anti Lockout Rule deaktivieren zur Sicherheit.
Später wenn alles rennt ist es besser den Port von 443 auf 54443 umzubiegen um da nicht Spielkindern Angriffsfläche zu bieten aber das ist Finetuning später.
An der pfSense musst du dann mit 1:1 NAT und Port Forwarding die Ports weiterleiten an die internen IPs die du auf dessen internen LAN Interface haben willst. Auch hier musst du die entsprechenden FW Regeln erstellen damit das klappt.
Ein Blick in das Firewall Log ist hier immer hilfreich, denn da steht genau WAS WARUM geblockt wurde.
Ein route add Kommando ist aus den obigen Gründen Unsinn. Deshalb löst es auch nicht dein Problem...kannst du deshalb gleich wieder löschen.
Hilfreich wäre hier eine kleine Topologie Zeichnung WAS WIE verschaltet ist und WAS du WIE erreichen willst an der FW... ?!
Generell ist die Einrichtung ja kein Problem.
An der NIC des vHosts ist deine öffentliche IP, die muss im Bridge Modus mit der vNIC der pfSense verbunden sein, da kommt dann die 2te öffentliche IP drauf.
WAN Default Gateway und DNS wird so eingestellt wie es auch auf der NIC des vHosts gemacht ist.
Generell ist der WAN Port der FW wie es auch sein soll komplett dicht...Management ist also nicht möglich.
Hier solltest du eine Regel erstellen die inbound Port 443 auf die WAN IP erlaubt, damit kannst du die FW dann über ihr GUI managen.
Wenn das klappt solltest du die Anti Lockout Rule deaktivieren zur Sicherheit.
Später wenn alles rennt ist es besser den Port von 443 auf 54443 umzubiegen um da nicht Spielkindern Angriffsfläche zu bieten aber das ist Finetuning später.
An der pfSense musst du dann mit 1:1 NAT und Port Forwarding die Ports weiterleiten an die internen IPs die du auf dessen internen LAN Interface haben willst. Auch hier musst du die entsprechenden FW Regeln erstellen damit das klappt.
Ein Blick in das Firewall Log ist hier immer hilfreich, denn da steht genau WAS WARUM geblockt wurde.
Male ich gleich auf, einen Moment bitte...
Und bitte keine externen Bilderlinks !! Kannst du über den Original Thread Uploaden mit der Upload Funktion und den Bild URL in jeglichen Text posten.
1
So schaut es aus, ich hoffe es ist einigermaßen verständlich... (Ich habe leider nicht so viel Erfahrung mit Netzwerkskizzen...)
Ergänzend habe ich jetzt für das OPT1-Interface (Öffentliche IP2) eine generelle PASS-Regel angelegt.
Nur nochmal zur Klarstellung: Das Wort Bridge bezeichnet hier KEINE Bridgekonfiguration innerhalb der pfSense sondern einzig von der virtuellen Hypervisor NIC zu den pfSense Interfaces !!
Das sollte dir klar sein und du auch zwingend beachten ?!
Ansonsten ist das soweit OK.
Das WAN Interface der pfSense muss mit der physischen Hypervisor NIC wo die auch ihre öffentliche IP hat im Bridge Modus (Hypervisor Bridge !) verbunden sein.
Dem WAN Interface der pfSense vergibst du dann eine weitere öffentliche IP die du noch hast mit entsprechend Subnetzmaske und Gateway und DNS.
Über die Ping Funktion in den Diagnostics Menü der pfSense kannst du dann dort die saubere Internet Verbindung testen indem du z.B. mal die 8.8.8.8 anpingst oder www.heise.de um auch mal DNS zu testen.
Das LAN Interface der pfSense hängt dann an der internen virtuellen NIC mit einer privaten IP an der auch alle VM Clients hängen.
Hier kannst du die Connectivity auch testen indem du von den VMs andere VMs und das pfSense LAN Interface pingst.
Zur Sicherheit solltest du über die Mac Adressen der virtuellen NICs genau checken das die Zuordnung auch stimmt.
Du brauchst eigentlich gar keine weiteren Interfaces auf der pfSense. WAN und LAN Port reichen für dich ja hier vollkommen !
Wozu also sinnloserweise noch ein zusätzliches OPT Interface einrichten ?? Du hast ja keinerlei weitere IP Segmente mehr ?
Das wars....wenn du das eingerichtet hast klappt alles wunderbar !
Das sollte dir klar sein und du auch zwingend beachten ?!
Ansonsten ist das soweit OK.
Das WAN Interface der pfSense muss mit der physischen Hypervisor NIC wo die auch ihre öffentliche IP hat im Bridge Modus (Hypervisor Bridge !) verbunden sein.
Dem WAN Interface der pfSense vergibst du dann eine weitere öffentliche IP die du noch hast mit entsprechend Subnetzmaske und Gateway und DNS.
Über die Ping Funktion in den Diagnostics Menü der pfSense kannst du dann dort die saubere Internet Verbindung testen indem du z.B. mal die 8.8.8.8 anpingst oder www.heise.de um auch mal DNS zu testen.
Das LAN Interface der pfSense hängt dann an der internen virtuellen NIC mit einer privaten IP an der auch alle VM Clients hängen.
Hier kannst du die Connectivity auch testen indem du von den VMs andere VMs und das pfSense LAN Interface pingst.
Zur Sicherheit solltest du über die Mac Adressen der virtuellen NICs genau checken das die Zuordnung auch stimmt.
Du brauchst eigentlich gar keine weiteren Interfaces auf der pfSense. WAN und LAN Port reichen für dich ja hier vollkommen !
Wozu also sinnloserweise noch ein zusätzliches OPT Interface einrichten ?? Du hast ja keinerlei weitere IP Segmente mehr ?
Das wars....wenn du das eingerichtet hast klappt alles wunderbar !
Hallo aqui,
das Problem ist aber, dass die zweite öffentliche IP keine Gateway-Angabe und eine 32er Netzmaske hat, deshalb dachte ich, ich müsste ausgehend das NAT vom hypervisor nutzen, oder? Die beiden Adressen liegen leider auch in vollkommen verschiedenen Netzen...
Daher die Idee mit den 3 Interfaces... Oder wie soll ich da sonst vorgehen?
Gruß!
Berthold
das Problem ist aber, dass die zweite öffentliche IP keine Gateway-Angabe und eine 32er Netzmaske hat, deshalb dachte ich, ich müsste ausgehend das NAT vom hypervisor nutzen, oder? Die beiden Adressen liegen leider auch in vollkommen verschiedenen Netzen...
Daher die Idee mit den 3 Interfaces... Oder wie soll ich da sonst vorgehen?
Gruß!
Berthold
Das kann ja nicht sein. Dann machst du für eine öffentliche IP nochmal NAT mit einer öffentlichen IP. Das wäre ja totaler Blödsinn.
Hat der Provider dir wirklich eine /32 Hostmaske gegeben ? Das kann eigentlich nicht sein, es sei denn er geht davon aus das du die irgendwo routest.
Aber auch das wäre total unüblich, denn der geht ja vermutlich davon aus das du eine zusätzliche VM auf dem Host laufen lässt und die im Bridge Mode ist und so auch eine öffentliche IP hat.
Ist die 2te IP denn im gleichen IP Netz bzw. sieht sie gleich aus wie die primäre IP ?
Trag einfach mal sonst Gateway und DNS so ein wie es bei der Primären vorgegeben ist.
Ansonsten musst du mal den Provider kontaktieren, denn die Maske ist eigentlich falsch.
Hat der Provider dir wirklich eine /32 Hostmaske gegeben ? Das kann eigentlich nicht sein, es sei denn er geht davon aus das du die irgendwo routest.
Aber auch das wäre total unüblich, denn der geht ja vermutlich davon aus das du eine zusätzliche VM auf dem Host laufen lässt und die im Bridge Mode ist und so auch eine öffentliche IP hat.
Ist die 2te IP denn im gleichen IP Netz bzw. sieht sie gleich aus wie die primäre IP ?
Trag einfach mal sonst Gateway und DNS so ein wie es bei der Primären vorgegeben ist.
Ansonsten musst du mal den Provider kontaktieren, denn die Maske ist eigentlich falsch.
Hallo Aqui,
die zweite IP ist eine ganz andere als die erste. (89,163.XXX.XXX und 5.199.YYY.YYY)
Die Beschreibung des Providers zu den zusätzlichen IP-Adressen sagt folgendes:
(Das gilt natürlich nur, wenn ich die Adresse auf dem Hypervisor und nicht auf der VM einrichten will)
Ansonsten ist hier bei den VMs noch die Rede von Hostrouten
Ich habe nur keine Ahnung, wie ich das jetzt mit der pfSense umsetze.
Vielleicht hast du ja noch einen heißen Tip für mich, denn meine Kenntnisse sind hier wohl leider nicht ausreichend, gerade auch was die pfSense betrifft.
Vielen Dank für die Hilfe!
die zweite IP ist eine ganz andere als die erste. (89,163.XXX.XXX und 5.199.YYY.YYY)
Die Beschreibung des Providers zu den zusätzlichen IP-Adressen sagt folgendes:
Eine zusätzlich bestellte IP Adresse muss auf Ihrem Server eingerichtet werden, damit diese erreichbar ist. Hierzu gehen Sie wie folgt vor:
Debian Linux
In der Datei /etc/network/interfaces folgenden Eintrag hinzufügen:
auto eth0:1
iface eth0:1 inet static
address XXX.XXX.XXX.XXX
netmask 255.255.255.255Ansonsten ist hier bei den VMs noch die Rede von Hostrouten
Beispielhafte Annahmen
In den folgenden Konfigurations-Beispielen gehen wir von folgenden IP-Adressen aus:
IP Host: 10.0.1.100/24
IP Gateway: 10.0.1.1
IP VM: 10.0.2.100/32
Hostkonfiguration
In der Virtualisierungs-Software müssen Sie für das Netzwerk Ihrer virtuelle Maschine ein Bridged-Setup verwenden. Unter VMware-vSphere muss der erstellte vSwitch mit der Netzwerkkarte Ihres Server "verbunden" werden. Unter den gängisten Virtualisierungs-Produkten ist dies Standard, wenn Sie ein Bridged-Setup bei der Erstellung der VM wählen.
VM-Konfiguration
Die Basis-Installation Ihre virtuellen Servers muss offline von einem minimalen Installationsmedium erfolgen, da kein uns bekannter Installer ein solches Netzwerk-Setup direkt ermöglicht. Anschließend kann aber im fertig installierten System die Netzwerkkonfiguartion über Konfigurationsdateien problemlos gesetzt werden:
Debian/Ubuntu
Unter Debian bzw. Ubuntu kann das Setup über die für die Netzwerkkonfiguration vollständig in der Datei /etc/network/interfaces eingetragen werden.
/etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 10.0.2.100
netmask 255.255.255.255
post-up ip route add 10.0.1.1 dev eth0
post-up ip route add default via 10.0.1.1Ich habe nur keine Ahnung, wie ich das jetzt mit der pfSense umsetze.
Vielleicht hast du ja noch einen heißen Tip für mich, denn meine Kenntnisse sind hier wohl leider nicht ausreichend, gerade auch was die pfSense betrifft.
Vielen Dank für die Hilfe!
Hat nicht vielleicht doch noch jemand eine Idee zu diesem Setup? So langsam verzweifele ich daran...
OK, dann routen die über deine öffentliche NIC IP die die auch ein Dateway und DNS hat.
Der Provider wird also alles was die 89,163.XXX.XXX und 5.199.YYY.YYY hat also die Adressen mit einer 32 Bit Hostroute an diese IP senden.
Das ist quasi so als wenn deine öffentliche IP (die mit Gateway IP) deinen Router IP für die dir gehörenden Adressen 89,163.XXX.XXX und 5.199.YYY.YYY ist !!
Ganz simpel also....
Wenn diese öffentliche IP und die 89,163.XXX.XXX und 5.199.YYY.YYY alle auf einer Hardware bzw. einem gemeinsamen System (OS) sind dann ist es ja ganz einfach, denn dann "kennt" dieses System auch diese IP Adressen.
Kannst du ja oben genau sehen, denn diese sind als Sub Adressen zum primären Interface konfiguriert.
Wenn du sie jetzt allerdings auf unterschiedlichen Systemen hast oder VMs "kennen" diese unterschiedlichen Systeme diese IPs ja nicht, da lokal nicht direkt angeschlossen. Du musst hier also zwangsweise dann routen.
Sprich deine VM die ja die öffentliche IP mit Gateway hält muss dann also diese IPs mit einer Hostroute an die VM mit pfSense routen.
Generell ist dieses Konstrukt etwas ungünstig, denn es wäre allemal besser die VM mit der pfSense hält diese Provider IP mit Gateway, denn sie ist ein besserer Router mit entsprechenden Features.
Aber andersrum geht es auch wenn auch etwas umständlich.
Du must also dem VM Host eine statische Hostroute dieser beiden zusätzlichen IPs an das virtuelle NIC Interface senden an dem die pfSense mit ihrer WAN IP hängt.
Die 2te IP ist dann einfach eine zusätzliche Subadresse der pfSense am WAN Port die du dann entsprechend mit Port Forwarding auf eine interne private IP mappst.
Fertisch.
Der Provider wird also alles was die 89,163.XXX.XXX und 5.199.YYY.YYY hat also die Adressen mit einer 32 Bit Hostroute an diese IP senden.
Das ist quasi so als wenn deine öffentliche IP (die mit Gateway IP) deinen Router IP für die dir gehörenden Adressen 89,163.XXX.XXX und 5.199.YYY.YYY ist !!
Ganz simpel also....
Wenn diese öffentliche IP und die 89,163.XXX.XXX und 5.199.YYY.YYY alle auf einer Hardware bzw. einem gemeinsamen System (OS) sind dann ist es ja ganz einfach, denn dann "kennt" dieses System auch diese IP Adressen.
Kannst du ja oben genau sehen, denn diese sind als Sub Adressen zum primären Interface konfiguriert.
Wenn du sie jetzt allerdings auf unterschiedlichen Systemen hast oder VMs "kennen" diese unterschiedlichen Systeme diese IPs ja nicht, da lokal nicht direkt angeschlossen. Du musst hier also zwangsweise dann routen.
Sprich deine VM die ja die öffentliche IP mit Gateway hält muss dann also diese IPs mit einer Hostroute an die VM mit pfSense routen.
Generell ist dieses Konstrukt etwas ungünstig, denn es wäre allemal besser die VM mit der pfSense hält diese Provider IP mit Gateway, denn sie ist ein besserer Router mit entsprechenden Features.
Aber andersrum geht es auch wenn auch etwas umständlich.
Du must also dem VM Host eine statische Hostroute dieser beiden zusätzlichen IPs an das virtuelle NIC Interface senden an dem die pfSense mit ihrer WAN IP hängt.
Die 2te IP ist dann einfach eine zusätzliche Subadresse der pfSense am WAN Port die du dann entsprechend mit Port Forwarding auf eine interne private IP mappst.
Fertisch.
