Hyper-V: How do VMs communicate with external?

When you create an External virtual switch in Hyper-V, the physical NIC is turned into a transparent Layer 2 bridge.
The Hyper-V Extensible Switch becomes the actual switching fabric, and the physical NIC simply transmits whatever Ethernet frames the switch sends — without rewriting the MAC address.

So when your VM’s vNIC (with MAC aa:aa:aa:aa:aa:aa) sends a packet, Hyper-V encapsulates it directly on the physical NIC’s hardware queue. The physical NIC driver sends it “as is” — the frame’s source MAC remains the VM’s MAC.
That’s why the external physical switch (physSwitch) learns the VM’s MAC address on that physical port.

 The mechanism in detail

Virtual switch binding

When you create an External vSwitch, Hyper-V removes the host OS’s direct binding to the physical NIC and attaches the NIC to the Extensible Switch layer.

A new virtual NIC is created for the host (the “vEthernet (External Switch)” adapter), which connects internally to that switch — just like any VM vNIC.

Layer-2 switching

The Hyper-V virtual switch is a full software bridge operating at Layer 2.

Each VM’s vNIC, and the host vNIC, are switch ports on that bridge.

The physical NIC (uplink) is another switch port.

MAC learning

The virtual switch maintains a MAC address table mapping each MAC to a port (vNIC, host, or uplink).

When a VM transmits a frame, the switch tags it with that port’s MAC as the source address and sends it out the uplink.

The physical NIC driver transmits that frame unmodified.

Physical switch perception

The external physical switch sees frames with source aa:aa:aa:aa:aa:aa arriving on the NIC’s port and therefore associates that MAC with the Hyper-V host’s switch port.

It doesn’t see bb:bb:bb:bb:bb:bb (the hardware MAC) unless the host OS itself is sending traffic.

Receive direction

For inbound traffic, the physical switch sends Ethernet frames destined for aa:aa:aa:aa:aa:aa.

The physical NIC delivers them up into the virtual switch, which forwards them to the VM that owns that MAC.

 Why the physical NIC’s MAC isn’t used

Because the Hyper-V switch operates below the host’s network stack.
The NIC is in “promiscuous” or “switch-embedded” mode, letting the virtual switch driver inject arbitrary Ethernet frames. The NIC hardware doesn’t rewrite or filter the source MAC; it just transmits what the vSwitch hands to it.

In essence:

VM → vSwitch → Physical NIC (as raw frame passthrough)

No NAT, no MAC translation, no encapsulation — unless you configure features like SR-IOV or NVGRE/VXLAN overlays.

 Special cases

SR-IOV enabled NICs: The VM’s vNIC maps to a Virtual Function (VF) on the NIC. The VF owns its own MAC and DMA queue, so frames are still transmitted with the VM’s MAC at hardware level.

Internal/Private switches: No external NIC is involved; traffic never leaves the host.

MAC spoofing: Disabled by default; if you enable it, a VM can send frames with arbitrary source MACs.

 Summary

In an External Hyper-V vSwitch, the virtual switch bridges the VM’s MAC addresses directly onto the physical network.
The physical NIC acts as a transparent port under vSwitch control, transmitting frames with the VM’s MAC untouched.
The external switch therefore learns each VM’s MAC as if the VM were physically connected to it.