VMware ESXi and vSphere Cluster Management
Configure VMware ESXi Virtual Switch Security Policies
Learn how Promiscuous Mode, MAC Address Changes, and Forged Transmits protect VMware ESXi virtual networks and how to configure them on standard switches and port groups.
VMware ESXi virtual switch security policies control how virtual machines handle Ethernet frames whose MAC-address behavior is unexpected. The three policies are Promiscuous Mode, MAC Address Changes, and Forged Transmits.
These settings help reduce traffic interception and virtual-machine identity spoofing. They apply to virtual networking only: they do not replace physical switch controls, VLAN design, firewalls, network segmentation, or guest operating-system security.
Key virtual networking terms
- vSphere Standard Switch (vSS): An ESXi-host-local virtual switch that connects virtual machines and VMkernel adapters to physical network uplinks.
- Port group: A logical connection point on a virtual switch that supplies shared network settings to attached virtual NICs.
- Virtual NIC (vNIC): The network adapter presented to a virtual machine.
- MAC spoofing: Using a MAC address other than the address legitimately assigned to a network adapter.
- Packet sniffer: A tool that captures and examines network frames or packets.
- Intrusion detection system (IDS): A monitoring system that analyzes traffic or events for suspicious activity.
Why virtual switch security policies matter
A normal virtual machine should generally receive frames addressed to its assigned vNIC MAC address and send frames using that same address. Security policies determine what happens when the VM attempts to receive other traffic, receive traffic for a changed MAC address, or transmit a frame with a different source MAC address.
A restrictive baseline limits the ability of one guest to observe other guests' traffic or impersonate another network identity. However, some monitoring, clustering, virtual-appliance, and software-defined networking workloads deliberately use these behaviors. The correct design is therefore least privilege: start with restrictive settings and create narrowly scoped exceptions when a documented workload requirement exists.
Virtual switch security policy comparison
| Policy | Traffic direction or behavior | Effect of Reject | Effect of Accept | Typical secure baseline | Common legitimate exception |
|---|---|---|---|---|---|
| Promiscuous Mode | Receiving frames not addressed to the vNIC's assigned MAC | The guest-connected vNIC receives only traffic permitted for its normal addressing behavior. | The vNIC may receive traffic beyond frames addressed to its assigned MAC. | Reject | Approved packet capture, network monitoring, or a guest-based IDS |
| MAC Address Changes | Inbound delivery after the guest changes the MAC address it uses | If the guest changes its effective MAC, inbound traffic to that changed address is not delivered. | The guest may receive traffic using its changed MAC address. | Use the restrictive compatible setting | Clustering, virtual appliances, or software-defined networking that must receive traffic for a changed MAC |
| Forged Transmits | Outbound validation of the source MAC on frames sent by a VM | Frames whose source MAC differs from the assigned vNIC MAC are discarded. | The VM may transmit frames with a different source MAC. | Reject | A floating or virtual MAC, clustering, or an appliance that must originate frames from another MAC |
Promiscuous Mode
Promiscuous Mode controls whether a guest-connected virtual NIC can receive frames that are not addressed to its assigned MAC address. In ordinary operation, a VM does not need to see unrelated traffic.
Setting Promiscuous Mode to Accept can allow a guest to observe traffic traversing the relevant virtual switch or port group. This creates a traffic-interception risk, especially when multiple workloads share the same virtual network.
Reject is the normal secure setting. Accept is appropriate only for an approved function such as a packet sniffer, network monitor, or guest-based IDS. Place that VM on the smallest dedicated monitoring port group that provides the required visibility, and document the exception.
MAC Address Changes
MAC Address Changes controls inbound traffic when a guest changes the MAC address it uses from the address assigned to its vNIC.
- Reject: If the guest changes its effective MAC address, inbound traffic addressed to that changed address is not delivered.
- Accept: The guest may receive traffic using its changed MAC address.
This behavior can be required by certain clustering systems, virtual appliances, failover designs, or software-defined networking components that use a virtual or floating MAC. Accepting the setting also permits a MAC-based identity change inside the virtual network, so it should not be enabled broadly without a workload justification.
Forged Transmits
Forged Transmits validates the source MAC address on frames sent by a VM. Older material may use the label Forget Transmits; the current VMware term is Forged Transmits.
- Reject: Outbound frames whose source MAC differs from the MAC assigned to the vNIC are discarded.
- Accept: The VM may transmit frames using a source MAC different from its assigned vNIC MAC.
Reject provides an important anti-spoofing control because a guest cannot easily originate frames while claiming another network identity. Accept may be necessary for a clustering product, virtual appliance, load-balancing design, or other workload that must send frames from a floating or virtual MAC.
How the three policies differ
The policies address different traffic behaviors:
- Promiscuous Mode concerns receiving traffic that is not addressed to the VM's assigned MAC.
- MAC Address Changes concerns inbound delivery after the guest changes the MAC address it uses.
- Forged Transmits concerns outbound frames whose source MAC is not the assigned vNIC MAC.
MAC Address Changes and Forged Transmits are separate controls. A workload may need one, both, or neither. For example, a guest might need to receive traffic for a changed virtual MAC but not transmit with a non-assigned source MAC, or it might need to transmit from a floating MAC while continuing to use its assigned MAC for receiving.
Recommended baseline and exceptions
| Workload | Promiscuous Mode | MAC Address Changes | Forged Transmits | Design guidance |
|---|---|---|---|---|
| Ordinary application VM | Reject | Restrictive compatible setting | Reject | Confirm that the application does not change its effective MAC address. |
| Approved security-monitoring VM | Accept only on a dedicated monitoring port group | Restrictive unless required | Restrictive unless required | Validate the monitoring design and authorization before enabling visibility. |
| Workload using a floating or virtual MAC | Reject unless independently required | Accept if it must receive traffic for the changed address | Accept if it must originate frames from the floating address | Use the narrowest port group or workload scope that supports the product. |
For every accepted setting, record the business or technical justification, workload owner, affected port group, approving authority, and review date. Prefer a dedicated exception port group rather than weakening a shared network used by unrelated VMs.
Policy scope and inheritance
On a vSphere Standard Switch, security policies can be configured at the standard-switch level and at the port-group level. A port group can inherit the switch setting or define its own value.
| Configuration location | Scope | Inheritance behavior | Precedence | Recommended use |
|---|---|---|---|---|
| Standard switch | Default for port groups on that switch | Port groups use this value when they do not override it. | Lower than an explicit port-group override | Set restrictive defaults for ordinary workloads. |
| Port group | Attached vNICs in that port group | May inherit the parent or define an explicit setting. | Higher than the parent switch setting when overridden | Isolate and document narrowly scoped exceptions. |
Always verify whether the target port group is inheriting its settings or overriding the parent switch. A switch-level change may not affect a VM if its port group has an explicit policy.
Configure policies in the vSphere Client
- Select the correct ESXi host in the vSphere Client.
- Open the host's networking management area.
- Identify the target standard switch and the port group used by the affected VM vNIC.
- Select the standard switch or port group whose policy should change.
- Open the object's edit-settings workflow.
- Open the Security section.
- Set Promiscuous Mode, MAC Address Changes, and Forged Transmits to Accept or Reject according to the approved design.
- Save the configuration.
- Return to the target port group and confirm the displayed effective values and inheritance state.
Use the exact object identified during planning. Changing a parent switch, changing a port-group override, and restoring inheritance have different effects. If production traffic could be affected, perform the change during an approved maintenance window and arrange a rollback plan.
Validation after a policy change
First check the effective policy at the port-group level and then check the parent switch. Do not rely only on the switch-level value. Next, test the expected behavior from the affected VM using normal traffic flows, application health checks, and authorized packet capture.
- For a monitoring VM, confirm that it sees only the traffic included in the approved monitoring design.
- For a changed-MAC workload, confirm inbound connectivity to the changed address.
- For a floating-MAC workload, confirm that outbound frames use the required source MAC and that the application remains healthy.
- For an ordinary VM, confirm normal connectivity and verify that no exception was applied more broadly than intended.
Symptoms and likely policy causes
| Observed symptom | Likely policy | Verification method | Least-permission remediation |
|---|---|---|---|
| A guest changes its MAC and stops receiving expected traffic. | MAC Address Changes is Reject at the effective port group or switch level. | Compare the guest's active MAC with the vNIC assignment and inspect inheritance. | Permit MAC Address Changes only on a dedicated port group if the workload genuinely requires it. |
| A clustering or appliance workload cannot send from a virtual or floating MAC. | Forged Transmits is Reject. | Inspect outbound frames and confirm that their source MAC differs from the assigned vNIC MAC. | Allow Forged Transmits only for the required workload or port group. |
| A packet-capture VM cannot observe expected traffic. | Promiscuous Mode is Reject, or the monitoring design does not make the traffic visible. | Confirm the capture interface's port group, effective policy, VLAN path, and monitoring authorization. | Enable Promiscuous Mode only on the dedicated monitoring port group if required. |
| A switch-level change does not alter a VM's behavior. | The VM's port group has an overriding policy. | Inspect the port group settings and identify the port group used by the VM vNIC. | Modify the override or restore inheritance according to the intended design. |
Example troubleshooting workflow
- Confirm the MAC address assigned to the VM's vNIC in the virtualization configuration.
- Check the MAC address currently used inside the guest operating system or application.
- Identify the port group connected to the affected vNIC.
- Review the port group's effective Promiscuous Mode, MAC Address Changes, and Forged Transmits values.
- Check whether each value is inherited from the standard switch or explicitly overridden.
- Confirm from the product documentation or design that the workload genuinely requires the changed behavior.
- Apply the narrowest justified exception, retest connectivity or monitoring, and record the result.
Security review checklist
- Is Promiscuous Mode set to Reject except on an approved monitoring port group?
- Is Forged Transmits set to Reject unless a documented workload must send a non-assigned source MAC?
- Has the restrictive compatible MAC Address Changes setting been tested for ordinary workloads?
- Are exceptions isolated from shared application networks?
- Does every accepted setting have a documented owner, scope, reason, and review date?
- Have effective port-group values and inheritance states been verified after the change?
- Have physical switch security, VLAN segmentation, firewalls, and guest security also been reviewed?
For related administration, see VMware switch network security policies.