Hyper-V virtual switch: Does it do NAT for virtual machines?

Question

The configuration:

• Hyper-V host (Windows Server 2025)
• Virtual switch (VMSwitch) of type "external", connected to a physical NIC
• Physical NIC connected to a physical switch in the "outside world"
• Host OS shares the VMSwitch
• Virtual machine (VM; Windows Server 2025)

The creation of the VMSwitch results in the creation of a virtual vEthernet device (that's normal); the physical NIC and the vEthernet have the same MAC address (that's normal, too; check with Get-NetAdapter/Get-VMNetworkAdapter -ManagementOS).

The VM is connected to the VMSwitch which results a virtual NIC to be exposed in the guest OS. On the Hyper-V host, the default of "dynamic MAC" is set, so the VM's virtual NIC has its own MAC address that's different from the vEthernet adapter of the host.

That's all pretty normal and works perfectly.

I often do nested virtualization, so when I want to make the VM a Hyper-V host, on the host, I need to enable MAC spoofing for the VM's virtual adapter that's connected to the VMSwitch. I do this by routine, and because without it, VMs on the nested Hyper-V host couldn't speak to the external network.

Recently, I started to wonder why MAC spoofing is required in such situations. What led me to the problem that I don't really undestand how traffic flow from a VM via the VMSwitch to the outside world and vice versa really works.

My understanding is that the entire nested-or-not Hyper-V amalgam has exactly one physical NIC showing the physical NIC's MAC address to the "outside world". So, the physical switch sees this NIC and thus its MAC address on one of its switch ports.

When the VM now sends a network packet, and it leaves the NIC and arrives the physical switch, doesn't the switch see the physical NIC's MAC address? Or does it really see the MAC address of the VM? I can imagine that the VMSwitch does something with either MAC addresses or packet routing... leaves the question why I need to activage MAC address spoofing for nested virtualization at all...

Answer 1

Hello,

In order to fully understand nested virtualization we need to take two steps back and start from the beginning of Networking. Real world physical networks use Network switches . A switch operates by learning the MAC address of the devices it is connected to creating a table mapping between MAC address and physical port. This way, when it is time to forward a packet to a specific destination address, the switch will only forward it to the relevant port.

If the switch doesn't know where to forward a specific packet (because, for example, it contains a new destination address) it will "flood" all ports - except the source port.

This behavior applies when forwarding traffic within the same IP subnet. Devices leverage the ARP protocol in order to resolve IP addresses to MAC addresses. So a device will populate the destination MAC address with the one he learnt from the destination, and the switch will do the rest. Instead when a packet is destined to a IP address that does NOT belong to the same subnet, it will be forwarded to a router (either a specific one if a route is defined, or to the default gateway). When the router forwards a packet to a different network, it changes the source MAC address to its own, and the destination MAC address to the next hop. MAC addresses are not preserved in IP datagrams when they travel accross different networks. (this property will play a role in Nested Virtualizaton later)

When you use virtual machines with Hyper-V, the virtualization software (Hypervisor) needs to find a way to map the physical MAC address of the hyper-V host to the virtual MAC addresses of the virtual machines it manages. This translation is done by Hyper-V's virtual switch. The virtual switch then becomes the software representation of the physical networking switches, but behaves in a slightly different way. By default:

• The virtual network adapter MAC address cannot be moved or associated with another virtual switch port.
• The virtual switch port does not forward unicast flooded packets (packets that are forwarded to all switch ports if the destination MAC address is not found in the switch forwarding table) to the virtual network adapter. This is done in order to prevent unwanted traffic to leak to a certain virtual machine. This configuration has an important consequence for the nested virtualization.

When it comes to Nested Virtualization, you will build a virtual machine inside another one. In order to do so, you need to install Hyper-V on a Virtual Machine (called the Virtual Host) as well as having Hyper-V running on the physical host. This implies the presence of two Virtual switches in a row on the path from the external network to the nested virtual machine.

Now imagine that a device on the external network needs to send traffic to the Nested VM 1 in the picture. But Nested VM 1 has MAC address of :1A and this MAC address is not present in the forwarding table of the physical hosts' Virtual switch, which only knows about MAC addresses :1B :2B and :3A
Since by default such Virtual Switch can not find information about :1A it is supposed to flood unicast packets searching for :1A but this is blocked by design as we discussed above. So natively, this configuration won't work.

The way to make Nested Virtualization work using Hyper-V on premises is enabling MAC spoofing on the physical hosts' Virtual switch. By enabling MAC spoofing:

• The virtual switch port that connects the virtual network adapter can send and receive packets that contain any MAC address.
• The virtual switch port dynamically learns of new MAC addresses and the virtual switch can add them in its forwarding table.
• The virtual switch port will receive and forward unicast flooded packets to the virtual network adapter.

Best Regards

Zunhui

Answer 2

Thank you Zunhui. The one document that I found on the web tells a similar story.

If I understand right, that means more or less that VMSwitches don't learn more than a single MAC address on each port, and they don't forward unicast flooded packets as long as MAC address spoofing isn't enabled.

The term "MAC address spoofing" IMHO has nothing to do with the functionality of this parameter in regards to VMSwitches if you ask me. Very confusing to use such wording. What adds to this that I have the impression that Microsoft doesn't really publish important technical details...