One virtual switch security policy that tends to trip folks up is the idea of rejecting or accepting MAC address Forged Transmits. To simplify the idea behind the policy, a Forged Transmit occurs when a network adapter starts sending out traffic that identifies itself as someone else. This security policy compares the Effective Address of the virtual network adapter and the source address inside of an 802.3 Ethernet frame generated by the virtual machine to make sure they match. If they don’t match, a Forged Transmit has occurred – sometimes this is known as MAC impersonation. If the security policy for Forged Transmits is set to Reject, the frame will be dropped.

The key thing to note about Forged Transmits is that the security policy is only policing the Effective Address of the network adapter, which is the address set by the guest OS. The policy does not compare the virtual machine’s configured MAC address, also called the Initial Address, as that duty is handled by the MAC Address Changes policy.

When Does A Forged Transmit Make Sense?

A common poster child for Forged Transmits is the use of Microsoft’s Network Load Balancing (NLB) unicast mode configuration.

In this scenario, multiple virtual machines are participating in the NLB cluster and all have the same MAC address. Other cases revolve around the concept of utilizing a common MAC address to own a cluster resource when one or more nodes fail. Realistically, you won’t encounter all that many use cases that require Forged Transmits, and the default distributed switch security setting is to Reject any MAC impersonations (the standard switch still Accepts them by default).

Prime Example: Nested Virtualization

A much more common scenario today is the situation where a virtual machine is hosting traffic for a variety of other workloads, such as with a virtual ESXi server running nested virtual guests. In this case, multiple MAC addresses will appear in the Source Address 802.3 field, as each virtual workload hosted by the VM would need to communicate using the virtual ESXi network adapter. You would need to Accept Forged Transmits in order for a nested virtual guest to communicate outside of the virtual ESXi host.

Take this example scenario below. A virtual ESXi VM has been created with a MAC address of “D” (not valid, but pretend it is). The virtual ESXi server is running three nested VMs with a MAC address of A, B, and C. When any of the VMs attempt to talk to the outside network via the virtual ESXi network adapter, the virtual switch will check the source address of the 802.3 Ethernet frame. Because the source address does not match the Effective Address of the virtual ESXi server, the frames will treated like a Forged Transmit and subsequently dropped.

Thoughts

If you’re still stuck on Forged Transmits vs MAC Address Changes, I invite you to read my post on rejecting MAC Address Changes. The two security policies are complimentary and can lend a hand to one another. When used together, MAC Address Changes ensure that the guest OS is unable to modify its Effective Address, and Forged Transmits prohibits the actual 802.3 Ethernet frames from containing any source MAC address other than the Effective Address.