18
IP außerhalb des Subnetzes wird nicht auf Default Gateway geroutet
Hallo,
ja, es ist Freitag und ich habe ein seltsames Problem. An dem war ich aber schon gestern dran. Weil ich es nicht selbst ergründen kann, möchte ich mal die Community damit belasten:
Ich kann eine IP (10.20.71.36), die in einem über IPSec angebundenen Netzwerk liegt, nicht erreichen. Die Pakete werden nicht auf das Default Gateway geroutet.
Ich kann mir das Problem nicht erklären.
Es sind zwei Netzwerke DC1, DC2 über eine IPSec, die jeweils am Standardgateway (pfSense, OPNsense) eingerichtet ist, verbunden.
DC1 läuft auf VMware ESXi, 7.0.3, DC2 in der EXOSCALE Cloud.
In DC1 sollte das Netz 10.10.0.0/16 eingerichtet sein. ESXi ist aber nicht unter meiner Kontrolle. In DC2 sind alle VMs innerhalb 10.20.0.0/16.
Ein Traceroute von einer Windows VM in DC1 auf die Ziel IP in DC2 geht nicht auf die Firewall:
Woher die Antworten kommen, ist mir schleierhaft.
Die Netzwerkkonfig:
Und die Routentabelle::
Ganz simpel.
Ein Traceroute auf eine andere IP im selben Subnetz wird, wie erwartet geroutet:
Dasselbe Ergebnis erhalte ich auch auf 10.20.71.37, die gar nicht existiert.
Falls die Frage aufkommt, warum der erste Hop nicht dem Default Gateway entspricht, das ist ein CARP HA Setup. Die Firewalls antworten immer mit der Interface IP, während als Gateway die virtuelle IP gesetzt ist.
Auf einer anderen VM in einem anderen Subnetz verhält es sich ebenso, auch auf Linux VMs.
Ich vermute, dass es was mit dem ESXi zu tun hat. Aber das dürfte doch nicht sein.
Hat jemand eine verständliche Erklärung für das Phänomen?
Grüße
ja, es ist Freitag und ich habe ein seltsames Problem. An dem war ich aber schon gestern dran. Weil ich es nicht selbst ergründen kann, möchte ich mal die Community damit belasten:
Ich kann eine IP (10.20.71.36), die in einem über IPSec angebundenen Netzwerk liegt, nicht erreichen. Die Pakete werden nicht auf das Default Gateway geroutet.
Ich kann mir das Problem nicht erklären.
Es sind zwei Netzwerke DC1, DC2 über eine IPSec, die jeweils am Standardgateway (pfSense, OPNsense) eingerichtet ist, verbunden.
DC1 läuft auf VMware ESXi, 7.0.3, DC2 in der EXOSCALE Cloud.
In DC1 sollte das Netz 10.10.0.0/16 eingerichtet sein. ESXi ist aber nicht unter meiner Kontrolle. In DC2 sind alle VMs innerhalb 10.20.0.0/16.
Ein Traceroute von einer Windows VM in DC1 auf die Ziel IP in DC2 geht nicht auf die Firewall:
C:\>tracert 10.20.71.36
Tracing route to 10.20.71.36 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.20.71.36
2 3 ms 1 ms 1 ms 10.20.71.36
3 1 ms 1 ms 1 ms 10.20.71.36
4 1 ms 1 ms 1 ms 10.20.71.36
5 1 ms 1 ms 1 ms 10.20.71.36
6 1 ms 1 ms 1 ms 10.20.71.36
7 1 ms 1 ms 1 ms 10.20.71.36
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
30 * * * Request timed out.
Trace complete.Die Netzwerkkonfig:
C:\>ipconfig /all
Ethernet adapter Ethernet0 2:
Connection-specific DNS Suffix . : xxx.xy
Description . . . . . . . . . . . : vmxnet3 Ethernet Adapter
Physical Address. . . . . . . . . : 00-50-56-A3-01-13
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 10.10.81.11(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.10.81.252
DNS Servers . . . . . . . . . . . : 10.10.81.252
NetBIOS over Tcpip. . . . . . . . : EnabledUnd die Routentabelle::
C:\>route print
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.10.81.252 10.10.81.11 271
10.10.81.0 255.255.255.0 On-link 10.10.81.11 271
10.10.81.11 255.255.255.255 On-link 10.10.81.11 271
10.10.81.255 255.255.255.255 On-link 10.10.81.11 271
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 10.10.81.11 271
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 10.10.81.11 271
===========================================================================
Persistent Routes:
Network Address Netmask Gateway Address Metric
0.0.0.0 0.0.0.0 10.10.81.252 Default
===========================================================================Ein Traceroute auf eine andere IP im selben Subnetz wird, wie erwartet geroutet:
C:\>tracert 10.20.71.35
Tracing route to 10.20.71.35 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms FW1.xxxx.xy [10.10.81.250]
2 * * * Request timed out.
3 1 ms 1 ms 1 ms 10.20.71.35
Trace complete.Dasselbe Ergebnis erhalte ich auch auf 10.20.71.37, die gar nicht existiert.
Falls die Frage aufkommt, warum der erste Hop nicht dem Default Gateway entspricht, das ist ein CARP HA Setup. Die Firewalls antworten immer mit der Interface IP, während als Gateway die virtuelle IP gesetzt ist.
Auf einer anderen VM in einem anderen Subnetz verhält es sich ebenso, auch auf Linux VMs.
Ich vermute, dass es was mit dem ESXi zu tun hat. Aber das dürfte doch nicht sein.
Hat jemand eine verständliche Erklärung für das Phänomen?
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670032
Url: https://administrator.de/forum/ip-ausserhalb-des-subnetzes-wird-nicht-auf-default-gateway-geroutet-670032.html
Ausgedruckt am: 19.01.2025 um 12:01 Uhr
18 Kommentare
Neuester Kommentar
Top Titel 🤣
Hi,
blockt DC2 ICMP?
Welches Netz hat DC2? Welche Netze werden über den IPSec getunnelt?
VG
blockt DC2 ICMP?
Welches Netz hat DC2? Welche Netze werden über den IPSec getunnelt?
VG
DC2 habe ich oben angegeben, liegen alle Subnetze innerhalb 10.20.0.0/16.
Nein, es wird nicht geblockt. Von der Test-VM im Management Subnetz ist alles erlaubt.
Das Problem ist aber, dass die IP keine VM überhaupt auf das Gateway in DC1 routet, als wäre die IP lokal.
Wie oben ersichtlich, ist die VM, von der ich die Tests durchgeführt hatte, aber in 10.10.81.0/24.
Nein, es wird nicht geblockt. Von der Test-VM im Management Subnetz ist alles erlaubt.
Das Problem ist aber, dass die IP keine VM überhaupt auf das Gateway in DC1 routet, als wäre die IP lokal.
Wie oben ersichtlich, ist die VM, von der ich die Tests durchgeführt hatte, aber in 10.10.81.0/24.
Was mir als erstes auffällt: du schreibst /16, nutzt aber /24
OK, da du das nicht aktiv angibst bei den CLI-Befehlen, wäre das egal.
Aber: wenn dein Netz 10.10.81/24 ist ...
... und du 10.20.71.36 (/16?) ansprechen willst:
Sicher, das di dich mit den Netzen nicht etwas vertust?
10.10.81.0/16 als Quelle in der VPN-Konfig wäre zunächst mal falsch ...
... und erst Recht 10.20.71.0/16, wenn es tatsächlich 10.20.71.0/24 wäre ..
oder gar 10.10.71.0/24?
🤔
OK, da du das nicht aktiv angibst bei den CLI-Befehlen, wäre das egal.
Aber: wenn dein Netz 10.10.81/24 ist ...
... und du 10.20.71.36 (/16?) ansprechen willst:
Sicher, das di dich mit den Netzen nicht etwas vertust?
10.10.81.0/16 als Quelle in der VPN-Konfig wäre zunächst mal falsch ...
... und erst Recht 10.20.71.0/16, wenn es tatsächlich 10.20.71.0/24 wäre ..
oder gar 10.10.71.0/24?
🤔
Hallo,
wie soll denn die ein 24er Subnetz auf ein 16er Gateway kommen, wenn die nicht zufällig im gleichen 24er liegen?
cya
wie soll denn die ein 24er Subnetz auf ein 16er Gateway kommen, wenn die nicht zufällig im gleichen 24er liegen?
cya
1Zitat von @gammelobst:
Hallo,
wie soll denn die ein 24er Subnetz auf ein 16er Gateway kommen, wenn die nicht zufällig im gleichen 24er liegen?
cya
Hallo,
wie soll denn die ein 24er Subnetz auf ein 16er Gateway kommen, wenn die nicht zufällig im gleichen 24er liegen?
cya
Wir wissen ja bisher nichts über das Netz an sich - ein Diagramm vom TO wäre schön ...
schon möglich, das 10.10.0.0/16 < 10.20.0.0/16 irgendwie verbunden sind und zumindest beim TO in 24er unterteilt wird ...
Dann wäre aber die Frage des Routing ... 🤔
Supernetting funktioniert nur von oben.
Nicht aber aus einem kleineren Netz.
Nicht aber aus einem kleineren Netz.
Die beiden Subnetze habe ich angeben, um die beiden Seiten der VPN abzugrenzen.
DC1: 10.10.0.0/16
DC2: 10.20.0.0/16
Jeder dieser Bereiche ist noch weiter segmentiert. Die VM, von der ich die Tests gepostet habe, befindet sich in 10.10.81.0/24 (DC1). Sie ist, nebenbei bemerkt, die einzige in ihrem Subnetz.
Sie sollte die Pakete für 10.20.71.36 aber auf jeden Fall auf das Standardgateway routen, passiert aber offenbar nicht.
Selbes Verhalten auf anderen VMs im Subnetz 10.10.71.0/24 in DC1.
Und natürlich hat jedes der Subnetze ihr eigenen Gateway, jeweils .250.
Die IPSec umfasst aber nicht den gesamten Bereich, sondern nur Teilenetze. Hier die SPDs aus Sicht von DC1:
Das, was da außerhalb der genannten Netze liegt, sind externe, die über OpenVPN angebunden sind.
DC1: 10.10.0.0/16
DC2: 10.20.0.0/16
Jeder dieser Bereiche ist noch weiter segmentiert. Die VM, von der ich die Tests gepostet habe, befindet sich in 10.10.81.0/24 (DC1). Sie ist, nebenbei bemerkt, die einzige in ihrem Subnetz.
Sie sollte die Pakete für 10.20.71.36 aber auf jeden Fall auf das Standardgateway routen, passiert aber offenbar nicht.
Selbes Verhalten auf anderen VMs im Subnetz 10.10.71.0/24 in DC1.
Und natürlich hat jedes der Subnetze ihr eigenen Gateway, jeweils .250.
Die IPSec umfasst aber nicht den gesamten Bereich, sondern nur Teilenetze. Hier die SPDs aus Sicht von DC1:
SPDs
Tunnel 10.20.0.0/16 10.10.64.0/19 ◄ Inbound ESP <DC1> ◄ <DC2>
Tunnel 10.20.0.0/16 10.0.40.0/22 ◄ Inbound ESP <DC1> ◄ <DC2>
Tunnel 10.20.0.0/16 192.168.3.0/24 ◄ Inbound ESP <DC1> ◄ <DC2>
Tunnel 10.10.64.0/19 10.20.0.0/16 ► Outbound ESP <DC1> ► <DC2>
Tunnel 10.0.40.0/22 10.20.0.0/16 ► Outbound ESP <DC1> ► <DC2>
Tunnel 192.168.3.0/24 10.20.0.0/16 ► Outbound ESP <DC1> ► <DC2> 
Die Kardinalsfrage ist welche IP Netze in der Phase 2 des IPsec VPN Tunnels definiert sind, also in den Tunnel geroutet werden? Dazu macht der TO leider keinerlei Angaben und zwingt zum Raten. 
Nur die P2 Settings an der pfSense/OPNsense bestimmen was in den Tunnel auf die andere Seite geht und was nicht!! Routing ist da außen vor und hat nichts damit zu tun was die IPsec P2 forwardet.
Der gepostete, erfolgreiche Traceroute lässt aber vermuten das (geraten) die jeweiligen remoten /16er IP Netze in die P2 eingetragen sind und so auf die andere Seite gehen. Zielführender wäre allerdings ein Screenshot des P2 Settings der Firewalls um das sicher beurteilen zu können. (Siehe z.B. HIER). Hätte der TO auch vorab selber einmal checken können wie es bei einem strategischen Troubleshooting in der Regel ja üblich ist! 🧐
Zu mindestens ein Ping Check auf den Firewalls selber im "Diagnostic Menü" mit Setzen der entsprechenden LAN Interface IPs als Source/Absender IPs hätte das ebenso wasserdicht verifiziert das der Tunnel diese IP Netze sauber forwardet.
Desweiteren wäre wichtig zu wissen ob die angepingten Geräte ggf. Winblows Endgeräte sind. Bei denen ist bekanntlich das ICMP Protokoll (Ping: Typen 0 und 8) per Default in der Firewall deaktiviert.
Ohne das das im Firewall Setting aktiviert ist scheitert jeglicher Ping auf Windows Geräte.
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Mit dem ESXi hat es sicher nichts zu tun, denn wenn es klassisch mit einem vSwitch eingerichtet ist arbeitet dort alles im Layer 2 ohne Routing.
Nur die P2 Settings an der pfSense/OPNsense bestimmen was in den Tunnel auf die andere Seite geht und was nicht!! Routing ist da außen vor und hat nichts damit zu tun was die IPsec P2 forwardet.
Die IPSec umfasst aber nicht den gesamten Bereich
Genau deshalb ist es wichtig die exakten Phase 2 Settings im IPsec zu kennen! Nur Traffic der dort dediziert angegeben ist wird in den Tunnel geforwardet. Routing Einträge sind da wirkungslos.Der gepostete, erfolgreiche Traceroute lässt aber vermuten das (geraten) die jeweiligen remoten /16er IP Netze in die P2 eingetragen sind und so auf die andere Seite gehen. Zielführender wäre allerdings ein Screenshot des P2 Settings der Firewalls um das sicher beurteilen zu können. (Siehe z.B. HIER). Hätte der TO auch vorab selber einmal checken können wie es bei einem strategischen Troubleshooting in der Regel ja üblich ist! 🧐
Zu mindestens ein Ping Check auf den Firewalls selber im "Diagnostic Menü" mit Setzen der entsprechenden LAN Interface IPs als Source/Absender IPs hätte das ebenso wasserdicht verifiziert das der Tunnel diese IP Netze sauber forwardet.
Desweiteren wäre wichtig zu wissen ob die angepingten Geräte ggf. Winblows Endgeräte sind. Bei denen ist bekanntlich das ICMP Protokoll (Ping: Typen 0 und 8) per Default in der Firewall deaktiviert.
Ohne das das im Firewall Setting aktiviert ist scheitert jeglicher Ping auf Windows Geräte.
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Okay, die P2 habe ich vorhin schon nachgereicht. Alles andere ist eigentlich im ersten Post klar beschrieben.
Kurz:
VM 10.10.81.11/24
tracert auf 10.20.71.35 geht auf GW
tracert auf 10.20.71.36 wird sofort von 10.20.71.36 beantwortet (?), tracert scheint aber mit dieser Antwort nicht zufrieden zu sein und macht weiter.
Für mich wirkt sich da die VPN auf der Firewall / GW gar nicht aus. Das tracert kommt ja gar nicht da hin.
Kurz:
VM 10.10.81.11/24
tracert auf 10.20.71.35 geht auf GW
tracert auf 10.20.71.36 wird sofort von 10.20.71.36 beantwortet (?), tracert scheint aber mit dieser Antwort nicht zufrieden zu sein und macht weiter.
Für mich wirkt sich da die VPN auf der Firewall / GW gar nicht aus. Das tracert kommt ja gar nicht da hin.
Okay, die P2 habe ich vorhin schon nachgereicht.
Leider wenig zielführend, denn man weiss nicht auf welcher Seite diese gelten? Ist das die Seite mit dem lokalen 10.20er oder dem 10.10er?Und natürlich hat jedes der Subnetze ihr eigenen Gateway, jeweils .250.
Liegen die auch alle zentral auf den Firewalls oder bedienen die andere Router oder L3 Switches?Okay, die P2 habe ich vorhin schon nachgereicht.
Leider wenig zielführend, denn man weiss nicht auf welcher Seite diese gelten? Ist das die Seite mit dem lokalen 10.20er oder dem 10.10er?Aus der Sicht von DC1, habe ich doch geschrieben. Für mich ist da alles nötige angegeben.
Und natürlich hat jedes der Subnetze ihr eigenen Gateway, jeweils .250.
Liegen die auch alle zentral auf den Firewalls oder bedienen die andere Router oder L3 Switches?Die liegen alle auf der Firewall.
Allerdings ist das auf ESXi mit 2 Hosts und 2 Switchen redundant aufgebaut. Das steht aber alles nicht unter meiner Kontrolle. Die Switche solten L2 sein.
Ich habe nur auf den Hosts die virtuellen Subnetze definiert und kann VMs damit verbinden.
Von allen Subnetzen ist jeweils der erste Hop die Firewall, nur bei 10.20.71.36 verhält es sich anders.
Nut frag ich mich, was sehe ich im Traceroute. Kann das jemand beantworten?
Aus der Sicht von DC1, habe ich doch geschrieben.
Das ist korrekt, aber dann fragt sich immer noch welche dedizierte Absender IP bzw. Netzmaske der DC1 hat??In DC1 sollte das Netz 10.10.0.0/16
OK, ist der DC1 laut obigem Output 10.10.81.11 addressiert mit einem 24 Bit Präfix also 10.10.81.0er Netzsegment dann fällt er in die Phase 2 Definition: 10.10.64.0/19 -> 10.20.0.0/16 die alle IP Netze zw. 10.10.64.0 und 10.10.95.0 ins remote 10.20er Netz forwardet.VPN technisch ist das also OK was ja dann auch der Traceroute mehr oder minder zeigt.
Wenn alle diese Netzsegmente zentral auf der Firewall liegen kann man nur vermuten das es da bei der Interface Adressierung zu einem Tippfehler bei den Masken gekommen ist.
Die Switche solten L2 sein.
Das ist in der Regel auch üblich bei ESXi. Allerdings wäre es von Vorteil die L2 Infrastruktur genau zu kennen, denn darauf baut eine korrekte Layer 3 Routing Infrastruktur massgeblich auf. Gibt es in der L2 Infrastruktur grobe Fehler bei der VLAN Zuordnung dann scheitert natürlich auch die L3 Connectivity, das liegt auf der Hand.Von allen Subnetzen ist jeweils der erste Hop die Firewall
Hier hast du die entsprechenden Subnetzmasken und IP Connectivity auf das jeweils lokale Firewall Interface geprüft? (Ping)Wie ist die Ping Connectivity von VMs im 10.10.64.0 bis 10.10.95.0 Bereich auf das remote LAN Interface der dortigen Firewall im 10.20er Netz? Sofern es kein ICMP oder IP Blocking auf das Interface gibt sollte ein Ping und Traceroute immer positiv sein.
was sehe ich im Traceroute.
Das kannst du HIER und auch HIER genau nachlesen!Traceroute zeigt dir also immer alle einzelnen Routing Hops zum Ziel an. Voraussetzung dafür ist das an den Hops ICMP Zugang erlaubt ist.
Idealerweise schaltet man die DNS Auflösung beim Tracerouten ab da das zu Verzögerungen führt und nicht alle Infrastrukturgeräte im DNS konfiguriert ist. Bei Winblows also tracert -d <ziel_ip>
In den jeweiligen Hops zw. Absender und Ziel sollten also ausschliesslich Router oder Firewalls zu sehen sein!
Aus der Sicht von DC1, habe ich doch geschrieben.
Das ist korrekt, aber dann fragt sich immer noch welche dedizierte Absender IP bzw. Netzmaske der DC1 hat um den der P2 Definotion zuordnen zu können?In DC1 sollte das Netz 10.10.0.0/16
OK, ist der DC1 laut obigem Output mit 10.10.81.11 addressiert und einem 24 Bit Präfix also 10.10.81.0er Netzsegment dann fällt er in die Phase 2 Definition: 10.10.64.0/19 -> 10.20.0.0/16 die alle IP Netze zw. 10.10.64.0 und 10.10.95.0 ins remote 10.20er Netz forwardet.VPN technisch ist das damit also OK, was ja dann auch der o.a. Traceroute mehr oder minder zeigt.
Wenn alle diese Netzsegmente zentral auf der Firewall liegen kann man nur vermuten das es da bei der Interface Adressierung zu einem Tippfehler bei den Masken gekommen ist.
Die Switche solten L2 sein.
Das ist in der Regel auch üblich bei ESXi. Allerdings wäre es von Vorteil die L2 Infrastruktur genau zu kennen, denn darauf baut eine korrekte Layer 3 Routing Infrastruktur massgeblich auf wie du als gestandener Netzwerk Administrator ja auch selber weisst.Gibt es in der L2 Infrastruktur grobe Fehler bei der VLAN Zuordnung dann scheitert natürlich auch die L3 Connectivity, das liegt auf der Hand. Es ist also mehr oder minder essentiel für ein zielführendes Troubleshooting das L2 Setup genau zu kennen. Andernfalls stocherst du immer im Trüben und hast einen großen Bereich an möglichen Ursachen die du nicht kennst.
Von allen Subnetzen ist jeweils der erste Hop die Firewall
Hier hast du die entsprechenden Subnetzmasken und IP Connectivity auf das jeweils lokale Firewall Interface geprüft? (Ping) 🤔Wie ist die Ping Connectivity von VMs im 10.10.64.0 bis 10.10.95.0 Bereich auf das remote LAN Interface der dortigen Firewall im 10.20er Netz? Sofern es kein ICMP oder IP Blocking auf das Interface gibt sollte ein Ping und Traceroute immer positiv sein.
was sehe ich im Traceroute.
Das kannst du HIER und auch HIER genau nachlesen!Traceroute (oder auch Pathping bei Winblows) zeigt dir immer alle einzelnen Routing Hops zum Ziel an. Voraussetzung dafür ist das an den Hops ICMP Zugang erlaubt ist.
Idealerweise schaltet man immer die DNS Auflösung beim Tracerouten ab da das zu Verzögerungen führt und nicht alle Infrastrukturgeräte im DNS konfiguriert ist. Bei Winblows also tracert -d <ziel_ip> bzw. pathping /n bei Pathping.
In den jeweiligen Hops zw. Absender und Ziel sollten also ausschliesslich Router oder Firewalls zu sehen sein!
Ich habe nun nochmal die 3 IPs im Remote-Netz, jedoch bei deaktivierter VPN, getracet, um Spekulationen über Konfigurationsfehler der VPN auszuschließen. Das Ergebnis ist mir gleichfalls unverständlich.
Traceroute (oder auch Pathping bei Winblows) zeigt dir immer alle einzelnen Routing Hops zum Ziel an. Voraussetzung dafür ist das an den Hops ICMP Zugang erlaubt ist.
Diese Frage war genau auf das Ergebnis bezogen:
Ich sehe hier 7 mal die Ziel-IP als next Hop. Ich habe schon so manches getracet, aber das sagt mir nix.
Interessant vielleicht, "<1 ms" gibt es nur in der ersten Zeile.
Da hilft mir Wikipedia leider auch nicht weiter, deshalb habe ich auf die Experten hier gehofft.
Andere IPs, wie erwartet:
Letztere IP existiert nicht, aber das macht hier keinen Unterschied, wenn die VPN tot ist. Die Pakete gehen nach draußen.
Ich hatte eigentlich gedacht, ich hätte das unterbunden. War wohl nur eine Idee.
Das Interface des Rechners ist korrekt konfiguriert. Die Konfig ist ganz oben gezeigt.
ICMP ist überall erlaubt und die VMs, auf welcher ich die gezeigten Tests gemacht habe, hat keine Einschränkungen bis auf sehr allgemeine. Aber selbst Filterbeschränkungen außerhalb könnten mir nicht das Traceroute Ergenbnis erklären.
Wie auch immer, das Problem muss nicht gelöst werden. Ich wollte es nur verstehen.
Die Ziel-IP brauche ich vorläufig nicht, die VM bekommt ohnehin eine andere, weil sie in ein anderes Subnetz wandert. Und das DC2 soll in einem halben Jahr das DC1 ablösen. Spätestens dann wär ich das Problem los.
Danke jedenfalls mal fürs Gedanken machen.
was sehe ich im Traceroute.
Das kannst du HIER und auch HIER genau nachlesen!Traceroute (oder auch Pathping bei Winblows) zeigt dir immer alle einzelnen Routing Hops zum Ziel an. Voraussetzung dafür ist das an den Hops ICMP Zugang erlaubt ist.
Diese Frage war genau auf das Ergebnis bezogen:
C:\>tracert -d 10.20.71.36
Tracing route to 10.20.71.36 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.20.71.36
2 1 ms 1 ms 1 ms 10.20.71.36
3 1 ms 1 ms 1 ms 10.20.71.36
4 2 ms 1 ms 2 ms 10.20.71.36
5 1 ms 1 ms 1 ms 10.20.71.36
6 2 ms 1 ms 1 ms 10.20.71.36
7 1 ms 5 ms 1 ms 10.20.71.36
8 * * * Request timed out.
9 * ^CInteressant vielleicht, "<1 ms" gibt es nur in der ersten Zeile.
Da hilft mir Wikipedia leider auch nicht weiter, deshalb habe ich auf die Experten hier gehofft.
Andere IPs, wie erwartet:
C:\>tracert -d 10.20.71.35
Tracing route to 10.20.71.35 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.10.81.250
2 1 ms 1 ms 1 ms <Infr1>
3 <Infr2> reports: Destination net unreachable.
Trace complete.
C:\>tracert -d 10.20.71.37
Tracing route to 10.20.71.37 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 10.10.81.250
2 1 ms 1 ms 1 ms <Infr1>
3 * <Infr2> reports: Destination net unreachable.
Trace complete.Letztere IP existiert nicht, aber das macht hier keinen Unterschied, wenn die VPN tot ist. Die Pakete gehen nach draußen.
Ich hatte eigentlich gedacht, ich hätte das unterbunden. War wohl nur eine Idee.
Das Interface des Rechners ist korrekt konfiguriert. Die Konfig ist ganz oben gezeigt.
ICMP ist überall erlaubt und die VMs, auf welcher ich die gezeigten Tests gemacht habe, hat keine Einschränkungen bis auf sehr allgemeine. Aber selbst Filterbeschränkungen außerhalb könnten mir nicht das Traceroute Ergenbnis erklären.
Wie auch immer, das Problem muss nicht gelöst werden. Ich wollte es nur verstehen.
Die Ziel-IP brauche ich vorläufig nicht, die VM bekommt ohnehin eine andere, weil sie in ein anderes Subnetz wandert. Und das DC2 soll in einem halben Jahr das DC1 ablösen. Spätestens dann wär ich das Problem los.
Danke jedenfalls mal fürs Gedanken machen.
Das Ergebnis ist mir gleichfalls unverständlich.
Ist das Ergebnis das was im Screenshot zu sehen ist, sprich der sich im Kreise drehende Traceroute auf die 10.20.71.36 ???Wenn das VPN dort deaktiviert war zeigt es das da was ganz gehörig im Argen liegt mit dem IP Routing. Der Trace auf die 10.20.71.36 dürfte in dem Falle nie beantwortet werden bzw. rennt dann gleich beim ersten Hop an der Firewall in einen Timeout mit Sternchen...
Ich habe schon so manches getracet, aber das sagt mir nix.
Zeigt das es da einen Routing Loop gibt. Vermeintlich durch falsche IP Routen oder falsche IP Adressierung. (geraten)Ist die 10.20.71.36 der oder ein LAN Port der remoten Firewall oder was verbirgt sich dahinter??
aber das macht hier keinen Unterschied, wenn die VPN tot ist. Die Pakete gehen nach draußen.
Oha, dann wie oben schon gesagt: Falsche IP Routen oder falsche IP Adressierung! Besagt ja das diese IPs vermutlich auch lokal vorhanden sind. Doppelvergabe oder was auch immer.Hier solltest du also dringenst einmal in den hoffentlich vorhandenen IP Adressierungsplan bzw. Adresskonzept sehen!!
Das Interface des Rechners ist korrekt konfiguriert
Das hat mit dem ganzen Elend ja am allerwenigsten zu tun. Da liegt am IP Routing oder der Adressierung ziemlich was im Argen.Wie auch immer, das Problem muss nicht gelöst werden.
OK, dann kannst du das Chaos ja auch einfach belassen. Normal ist das Verhalten jedenfalls nicht und weist de facto auf gravierende Fehler im TCP/IP hin.Bleibt ja dann nur noch
Wie kann ich einen Beitrag als gelöst markieren?
Ist das Ergebnis das was im Screenshot zu sehen ist, sprich der sich im Kreise drehende Traceroute auf die 10.20.71.36 ???
Ja, und es betrifft nur diese IP von allen, die ich nutze.
Die IP ist eine VM hinter der Firewall auf der Remoteseite der IPSec. Diesseits wird die VPN auch durch die FW terminiert.
Das Problem tritt in allen von uns genutzten Subnetzen (ESXi) auf, nicht aber im Management Subnetz. Das einzige, was mir einfällt, was die einen vom anderen unterscheidet, ist dass auf den fehlerhaften der Promiscuous-Mode in ESXi aktiviert ist.
Die Interfacekonfiguration hatte ich angeführt, weil ich davon ausgehe, dass die Pakete zu eine Ziel-IP außerhalb des Subnetzes aufs Gateway geroutet werden. Ich würde mir also bei Traceroute keine direkte Antwort sondern das Standardgateway als ersten Hop erwarten.
Und falls irgendetwas im L2 direkt antwortet, würde ich mir erwarten, die IP in der ARP Tabelle zu finden, was nicht der Fall ist.
Und nun war meine Frage, wie das sein kann.
Das Problem tritt in allen von uns genutzten Subnetzen (ESXi) auf
Da ist irgendwas im Argen. Entweder stimmen dort Gateway IP Adressen nicht oder die VMs sind nicht korrekt im Layer 2 (vSwitch) den Firewall Segmenten richtig zugewiesen. Möglich auch das im Regelwerk irgendwo ICMP geblockt oder teilgeblockt wird.Das Verhalten ist so nicht normal. Liegt ja auch auf der Hand wenn man das Ergenis sieht.
Am Ziel ist ein Traceroute immer prinzipbedingt zuende und dreht sich dort nicht unendlich weiter bis der TTL Counter abgelaufen ist. Das sieht sehr verdächtig nach einem Routing Loop aus in diesen Netzen! Vermutlich gibt es dort fälschlicherweise mehrere Gateway o.ä.
Ohne aber die L2 und auch L3 Infrastruktur genau zu kennen ist das Raterei im freien Fall.
Ggf. solltest du einmal einen TCP basierten Traceroute verwenden um ICMP als Fehlerursache auszuschliessen.
