New in Hyper-V Windows Server 2008 R2 Part 2 – MAC Spoofing

Our Virtual Switch got smarter in Windows Server 2008 R2. In Windows Server 2008, VMs are susceptible to MAC spoofing. MAC spoofing is where a (generally) malicious machine pretends to be another machine on a network (there are legitimate applications which do spoof MAC addresses though – Network Load Balancing being one such example).

A MAC (Media Access Control) address in physical NICs is burnt in, although it can usually be over-ridden. In a virtual machine environment, there’s no physical counterpart, so we have to “make up” our own addresses. In fact, that can sometimes cause other networking issues which I talked about last year.

The virtual switch in Hyper-V is a learning layer 2 switch – in other words, it routes packets based on MAC addresses. Therefore, if a malicious VM starts sending out packets with a MAC address owned by another machine, it causes the switch to re-learn. This in turn can cause DoS (Denial of Service) attacks, and the potential for the malicious virtual machine to see packets which weren’t destined for it. Hence, in our security recommendations, we state that as a security best practice, you should consider (in Hyper-V v1 at least) placing virtual machines of a similar security integrity level on the same virtual switch and not share the switch with virtual machines of a different security integrity level.

In Windows Server 2008 R2, we introduced several changes in the switch to make it smarter. Each virtual switch port has a new property (exposed in our WMI model as AllowMacSpoofing) which is off by default. We also expose this property in the settings page for a virtual machine. Note that to see this setting, you must be using the UI from Windows Server 2008 R2 or RSAT in Windows 7 Client.


When the checkbox is not checked (i.e. the port is in “secure” mode):

  1. The MAC address set in the Virtual NIC settings page (either static or the dynamically assigned on) is the only MAC address a virtual machine can specify for the source MAC address in any packets it sends.

  2. The virtual machine will only receive unicast packets with a destination MAC address matching the address in the virtual NIC settings page, and packets destined for its MAC won’t be flooded to other ports.

  3. As our virtual switch is a learning switch, we maintain various internal structures including a routing table. When the virtual machine starts and we power-on the virtual NIC, we pin the MAC address in the virtual NIC settings page into the routing table to ensure it cannot move to another port. We stop any more learning on that port.

  4. When traffic needs to be flooded by the switch to switch ports, we do not flood traffic to ports running in “secure” mode.

  5. Attempts to override the MAC address inside the virtual machine are ignored.

When the checkbox is not checked (i.e. the port is in “less secure” mode):
(6/15/2009 - fixed typo, removed word "not" above)

  1. The virtual machine can send and receive traffic using any MAC address

  2. The virtual machine receives flooded unicast packets

  3. Learning is enabled on the switch port so that multiple MAC addresses can be learnt on that port. No pre-population of the routing table is performed and MAC addresses for a port are learnt as traffic passes through the switch.

  4. Virtual machines can override their MAC address.

The above applies to virtual NICs used by virtual machines. We treat virtual NICs in the parent partition slightly differently and there is no setting to put that NIC into “secure” or “less secure” mode. The virtual NIC in the parent partition is always pinned in the routing table, but they receive flooded unicast traffic, learning is enabled on the switch port and can send using any MAC address.


And thanks again for Keith Mange for pulling the above information together 🙂

Comments (11)
  1. Anonymous says:

    Our Virtual Switch got smarter in Windows Server 2008 R2. In Windows Server 2008, VMs are susceptible

  2. Ultima Hosts – are you saying the *physical* switch port will only accept the physical MAC address? The virtual switch doesn’t have a MAC address itself – VMNics (or the VNic in the parent partition if configured) have MAC addresses. If the physical switch port is ACL’d to only allow the MAC address of the physical NIC, you need to relax security on that switch port to allow all traffic for the VMNics (and optionally the parent vNIC) for traffic to be able to flow.



  3. Joay – for example if the application running in a VM needs to send packets out with a source MAC other than the configured MAC address for the VM – Network Load Balancing (NLB) does this.



  4. Good spot – thanks Jason (and to others who mailed me direct). I’ve corrected the post.



  5. Madshark – the Hyper-V virtual switch is a layer 2 switch in both 2008 and 2008 R2. As such, to enforce seperation at layer 3, there are a few options. One is to use seperate physical NICs (obviously somewhat limiting in terms of scalability). VLANs will also provide full separation. There are some software solutions out there from vendors such as fivenines too.



  6. Joay says:

    Under what scenario would you choose "Less secure’?

  7. Jason says:

    I think you have a typo above…

    "When the checkbox is not checked (i.e. the port is in “secure” mode):


    "When the checkbox is not checked (i.e. the port is in “less secure” mode):


  8. Ultima Hosts says:

    Any pointers on how to setup the virtual network when the switch will only accept the physical MAC address?

  9. madshark says:

    Hi, what about spoofing IP addresses? It seems the virtual switch is not yet ‘smart’ enough for ACL’s to be configured. In a hosted environment any customer’s VM can steal the IP of another VM in the same subnet or even worse the gateway …

    … I would really like to here your comments on this issue. Yes I am talking about selling VM’s as opposed to an internal environment so layer 2 security is essential.

  10. wbplomp says:

    Normally when you enable NLB in unicast mode your will encounter switch flooding because the traffic is send to all switch ports. You can solve this by enabling NLB in multicast with IGMP mode.

    But what happens when you enable NLB in unicast mode on Virtual Machines (hosted on Hyper-V)? Technically, does switch flooding occur as well? Another question is, does it actually support NLB in multicast (with IGMP) mode?

Comments are closed.

Skip to main content