Both the standard and distributed VMware switches offer the ability to enforce a number of security policies to help prevent spoofing attacks, guard against traffic sniffing, and close other fun loopholes that can exist when people do silly things. One of the policies is called “MAC Address Changes” and is often met with confusion around what it does and when it goes into effect. In a nutshell, this policy determines if the guest OS within the virtual machine (VM) is allowed to define a new MAC address for the network adapter.

Typically, a VM’s MAC initial address is defined in the configuration file (.vmx) and can be viewed and altered by editing the virtual network adapter within the VM settings or by directly editing the vmx itself. Think of the intial address as the “burned in address” (BIA) used by physical cards. By default, the MAC is auto generated by vSphere using an Organizationally Unique Identifier (OUI) which starts with these three bytes: 00:50:56 – you can read all about that process here. If you look at your virtual machines, they should pretty much all start with those same three bytes.

When a VM is powered on, the initial address is assigned to the virtual network adapter and the guest OS will usually set the effective address to the same value. This is much like having a physical network card in your server and letting the guest OS simply use that burned in address without altering it. The end result is a runtime address applied to the virtual port based on the effective address.

To reiterate:

• Initial Address = Similar to a burned in address, this MAC is set by the configuration file (vmx) for the virtual network adapter. Cannot be changed by the guest OS, but can be changed by a vSphere Admin via the GUI or editing the vmx file.
• Effective Address = The address assigned by the guest OS to the network adapter. In most situations, the guest OS will simply copy the initial address.
• Runtime  Address = The effective address as viewed by a port on the virtual switch.

Modifying The Initial MAC Address

Regardless of the security policy set on the switch, you can change the Initial Address to whatever you want. You would do this by editing the virtual machine while it is powered off and modifying the MAC address of the network adapter.

Once changed, you’d want to make sure that the guest OS agrees with this new MAC address and sets the effective MAC address to match. In most cases, this will happen by default.

Modifying The Effective MAC Address

This is where the security policy “MAC Address Changes” comes into play. If you have flagged this policy to Reject then the Initial Address and Effective Address must agree with each other. If the guest OS changes the Effective Address, the Runtime Address on the port will also change. The port will compare the Effective Address to the Initial Address, detect that they do not much, and administratively down the port.

Here’s an example. In the screenshot above, you can see that the GNS3 VM has an Initial Address of 00:50:56:AF:2C:EE. I’ve set the “MAC Address Changes” policy to Reject. I then went into the guest OS, Windows 7, and manually edited the network adapter’s Effective MAC Address. I changed the last letter from E to D, making it 00:50:56:AF:2C:ED. The Effective Address no longer matches the Initial Address, and so the port has been blocked.

For another example, I’ve set the “MAC Address Changes” policy to Accept. I then changed the last letter in the Effective Address from E to C (00:50:56:AF:2C:EC). Because I’m using DHCP on the GNS3 VM, I also had to renew my IP lease for this new MAC. Below you can see that the new MAC address is in the ARP cache on my host and can be pinged successfully.

The Point of This Security Policy

If a VM can change its MAC to whatever it wishes, it can potentially spoof a known good MAC address and steal frames meant for another VM. Having this security policy in place prevents a VM from doing this, either maliciously or unintentionally, by blocking the port. There are certain use cases where you do want two VMs to have the same MAC address, an example being Network Load Balancing (NLB) in unicast mode. You can also read the VMware details on their view of MAC Address Changes.

Thoughts

Questions about MAC Address Changes have been frequent lately. I wonder if that is due to it being set to Reject by default with a distributed switch, but set to Accept by default with a standard switch. Perhaps those switching from standard to distributed switches are encountering the security policy for the first time?

Additionally, there seems to be confusion between MAC Address Changes and Forged Transmissions: you can read about those here!