ICMP Redirect for host

[Orca]

Hallo,

ich habe folgende Konfiguration:

• FRITZ!Box 7360 mit FRITZ!OS: 06.80
• realer Windows 10 Computer mit Hyper-V
• in Hyper-V eine VM mit ESXi 6.0 am externen Switch

nach zwei Abenden probieren und Suchen im Internet ist es mir endlich gelungen, den ESXi 6.0 unter Hyper-V zu virtualisieren. (Die Installation von ESXi 6.5 habe ich nicht gestartet bekommen, deshalb 6.0.)

Nun zu meinem Problem:

Windows 10 und ESXi haben beide eine statische IPv4-Konfiguration. IPv6 wird stateless konfiguriert (default) und erhält die IPv6-Adressen von der FRITZ!Box. Das Problem besteht aber auch wenn der ESXi-Host dynamisch konfiguriert wird. Er erhält ordnungsgemäß eine IPv4-Adresse von der FRITZ!Box.

Wenn ich mich auf der Benutzerschnittstelle der direkten Konsole (Direct Console User Interface, DCUI) anmelde und Test Management Network auswähle, werden alle Test erfolgreich bestanden. Dabei werden sowohl IPv4- als auch IPv6-Adressen getestet. Ich kann sogar über beide IP-Protokolle Hosts im Internet erreichen. Aber ich kann keine anderen IPv4-Adressen im LAN erreichen außer die der FRITZ!Box.

Edit: Habe einen zweiten virtuellen ESXi-Server aufgesetzt. Beide können sich gegenseitig über ihre IPv4-Adresse anpingen.

Wenn ich aber den ESXi-Server anpingen oder anderweitig erreichen will (VMware Host-Client, vSphere Web Client) ist nur eine Kommunikation unter Verwendung von IPv6-Adressen möglich. Der DNS-Server (oder besser DNS-Proxy) der Fritzbox liefert auf Namensanfragen nur die IPv4-Adresse zurück. Folglich bin ich gezwungen, überall mit IPv6-Adressen zu arbeiten.

Eine Diagnose mit Wireshark hat ergeben, dass jegliche Kommunikation mit dem ESXi-Host über IPv4 von der FRITZ!Box mit einem ICMP-Paket Typ 5 Code 1 (Redirect for host) beantwortet wird. Das TCP wiederholt die SYN-Pakete bis ein Timout eintritt. Die FRITZ!Box wiederholt ihre ICMP-Redirects.

Das Problem tritt nur mit dem ESXi-Host auf. Alle anderen realen und virtuellen Maschinen verhalten sich normal.

Hat jemand eine Idee, woran das liegt oder sogar eine Lösung?

Was kann ich noch diagnostizieren, um dem Problem auf die Spur zu kommen?

[~thc]

Zum Fehler: Wenn eine Maschine versucht, den virtuellen ESXi zu erreichen und ein "ICMP Redirect for Host" bekommt, bedeutet es, dass die Maschine glaubt, dass der ESXi sich außerhalb seiner Erreichbarkeit (Subnetz) befindet und das Paket an das Gateway (FritzBox) schickt. Da eigentlich alle modernen OS das ICMP Redirect for Host ignorieren, hilft es nichts.

- Kannst du ausschließen, dass auf dem Windows 10 irgendeine "Sicherheits"-Software läuft, die dem Bridging dazwischenfunkt?
- Wenn ja, kannst du mal die ARP-Caches der Maschinen überprüfen? Da IPv6 ohne ARP läuft, kann es damit zu tun haben.

[Orca]

Danke für deinen Denkanstoß.

Die ARP-Tabelle enthält gar keinen Eintrag für den ESXi-Host. Eine Untersuchung mit Wireshark ergab, dass der Quellrechner zwar ARP-Requests versendet, er aber keine Antwort darauf erhält.

Aus mir noch unbekannten Gründen richtet er dann den Echo-Request zwar an die richtige IP-Adresse, aber an die falsche MAC-Adresse, nämlich die der FRITZ!Box. Proxy-ARP ist es nicht, denn dann müsste die IP-Adresse des ESXi-Hosts mit der MAC-Adresse der FRITZ!Box in der ARP-Tabelle stehen.

Damit ist klar, warum die FRITZ!Box mit dem Redirect reagiert.

Ich habe einen neuen Thread aufgemachen, da das eigentliche Problem die fehlende IPv4-Kommunikation des ESXi-Hosts ist.