Limits of VLAN ID 0 and Promiscuous Mode Settings on vSphere Distributed Switch Port Groups for Preventing Public Exposure

Answer to the Core Question

Leaving a vSphere Distributed Switch (vDS) port group with VLAN ID 0 (untagged) and the three security policies set to Reject is not a guarantee that VMs cannot reach the public Internet when the uplink connects to a physical network that lacks VLAN segmentation. The policies block unauthorized traffic originating from the VM, but they do not prevent the physical uplink from forwarding that traffic if the switch port is mis‑configured or if other VLANs are injected.

Confirmed Facts (vSphere 7.x)

• The vDS enforces Promiscuous Mode, Forged Transmits, and MAC Address Changes before traffic leaves the port group, regardless of the uplink’s physical configuration.
• VLAN ID 0 forwards packets unchanged; any VLAN tag on the uplink is ignored unless the port is configured as a trunk.
• Binding an active uplink to a NIC that faces an untrusted zone does not bypass the vDS security policies, but it can expose the VM to traffic that the policies cannot filter if the physical port is a trunk or lacks port‑security.
• Legacy monitoring tools that require promiscuous mode must be enabled with caution; enabling Accept increases the risk of cross‑VLAN traffic unless additional segmentation or monitoring is in place.
• VMware documentation states that the security settings are mandatory for preventing MAC spoofing but do not guarantee isolation if the underlying physical network is mis‑configured.

Likely Explanation for Residual Risk

When the physical uplink port is a trunk or is left unprotected, packets from other VLANs or spoofed MACs can reach the VM’s NIC. Because VLAN ID 0 does not add a tag, the vDS treats the traffic as untagged and applies the Reject policies, but if the physical port forwards all traffic, the VM can still receive packets from the public network that are not originated by it. This can lead to inadvertent exposure, especially in converged data‑center environments where the same uplink serves multiple tenants.

Practical Verification Steps

1. Check port group settings:

   Connect to vSphere Client → Hosts & Clusters → Host → Networking → Distributed Switch → Port Group → Properties.
   Verify VLAN ID = 0 and all three security policies = Reject.

2. Inspect the physical uplink port:

   On the edge switch, run commands such as show interface port switchport to confirm it is an access port, not a trunk, and that port‑security is enabled (e.g., switchport mode access, spanning-tree portfast, storm-control).

3. Test connectivity from a VM: Run ping -c 4 8.8.8.8 from a VM in the port group. The ping should fail if the policies are effective.
4. Capture traffic on the physical NIC: Use tcpdump -i vmnicX -nn to verify that no untagged traffic from the VM reaches the public network and that no unexpected tags appear.
5. Review host logs: Check /var/log/vmware/hostd.log for entries like "Rejecting traffic due to security policy" to confirm the policies are actively blocking traffic.

Recommended Configuration for Strong Isolation

• Prefer explicit VLAN tagging for port groups that connect to untrusted or shared uplinks (e.g., assign a dedicated VLAN per tenant).
• Keep Promiscuous Mode, Forged Transmits, and MAC Address Changes set to Reject unless a monitored environment absolutely requires Accept, in which case add a separate monitoring VLAN.
• Ensure the physical uplink is an access port with port‑security enabled, or use a dedicated trunk with strict VLAN assignment.
• Consider placing the port group in a vDS VLAN segmentation policy that allows only the intended VLAN, preventing accidental VLAN hopping.

Missing Diagnostic Detail That Could Change the Recommendation

To finalize the recommendation, please confirm whether the physical uplink port on the edge switch is configured as a trunk or an access port, and whether port‑security is enabled. If it is a trunk, the default Reject policies alone will not suffice; you will need to enforce VLAN segmentation or additional switch‑side controls.