Da einige der Systeme sich im Netzwerk von manchen Quellen anpingen ließen, von anderen nicht, hatte ich einen Blick auf die ARP-Tabelle eines der Hosts, von wo aus ein Ping nicht möglich war, geworfen:

Dort war mir dann etwas aufgefallen – nämlich dass eine konkrete MAC-Adresse mehreren IP-Adressen zugeordnet war – mit anderen Worten: Mehrere Hosts im Netzwerk hatten scheinbar die selbe MAC-Adresse!

Um dies zu verifizieren, habe ich mir dann die MACs aller VMs auf den betroffenen Hosts anzeigen lassen:

Get-VMNetworkAdapter -VMName * -ComputerName "HOST01","HOST02","HOST03" | Select-Object VMName,MacAddress | Sort-Object MacAddress

Hier bestätigt sich die vorherige Erkenntnis: 4 der verwendeten MACs werden durch mehr als eine VM genutzt! Aber woher kommt das?

Alle Hyper-V-Hosts wurden im selben Netzwerk und nacheinander aufgesetzt. Dennoch zeigt sich, dass zwei der Hosts den selben MAC Address Pool verwenden:

Die Lösung besteht also aus 2 Teilen:

• MAC Address Pool auf mindestens einem der beiden Hosts ändern
• Betroffenen VMs eine neue MAC-Adresse (oder einfach eine neue NIC) verpassen

Ich habe keine Ahnung, wie dieser Fehler zustande gekommen ist, denn eigentlich prüfen Hyper-V Hosts beim Setup, ob der MAC-Address-Bereich von anderen Hosts verwendet wird, aber diese Prüfung war hier wohl irgendwie wenig erfolgreich… Naja, egal. Fehler gefunden, behoben, alles gut

Ich habe auf einer Azure Firewall einige DNAT Rules, um auf Jump-Hosts zu kommen, die in unterschiedlichen Netzwerken stehen:

Hier ist also für zwei VMs aus dem freien Internet über die Public IP der Azure Firewall und zwei höhere Ports der Durchgriff auf RDP TCP/3389 konfiguriert.

Zwischen den beiden Netzwerken, in denen sich die VMs befinden, soll der Traffic aber stark reglementiert sein. Daher sind dort nur einige Ports explizit erlaubt, für den Rest sollte die Azure Firewall „per default“ blockieren:

Jedoch ist es dennoch so, dass zwischen den beiden VMs, die ja in getrennten Netzen stehen, weiterhin Kommunikation möglich ist, auch jenseits von ICMP und HTTP(S). Getestet hatte ich es mit RDP – das geht noch, obwohl das nach meiner Meinung nicht so sein sollte.

Und das hatte mich sehr verwundert. Zunächst hatte ich das als Fehlverhalten interpretiert. Ein kurzer Call mit dem Support hat aber geklärt, dass dieses Verhalten so ganz normal ist. Das wiederum war für mich unerwartet.

Die Lösung hier ist, dass eine DNAT Rule eine implizite Network Rule nach sich zieht. Dabei werden allerdings nicht Port und Destination IP sondern Translated Adress und Translated Port für die Destination verwendet. So steht es auch in der Doku:

(Quelle: https://docs.microsoft.com/en-us/azure/firewall/rule-processing)

Es gibt hier also zwei Lösungen, um das Ziel, keine Kommunikation zwischen den Netzen zu haben, zu erreichen:

• In den DNAT Rules konkrete Source-IPs / Netze eintragen
• Explizite Network Rules mit einem Deny zwischen den Netzen