Securing the Virtual Switch Layer (vSwitch / vDS) in VMware vSphere — A Complete Guide

Securing the Virtual Switch Layer (vSwitch / vDS) in VMware vSphere — A Complete Guide

What You Will Learn

This guide walks you step-by-step through securing VMware vSphere’s virtual networking layer using the vSphere Distributed Switch (vDS). After reading, you will understand:

  • How to design, deploy, and harden a vSphere Distributed Switch

  • How to secure port groups and enforce best-practice security settings

  • How to use PowerCLI to automate switch creation, port groups, and security configuration

  • How to protect management networks (vCenter, ESXi mgmt, vMotion, vSAN)

  • How to implement Private VLANs for secure multi-tenant or isolated workloads

  • How to monitor, audit, and verify vSwitch/vDS security

  • How to apply VMware hardening and STIG recommendations

  • How to structure RBAC and change control for safe operations

This orientation ensures new readers know exactly what practical skills and configurations they’ll gain from the post.

__________________________________________________________________________________

Why This Matters

The vSwitch / vSphere Distributed Switch (vDS) is the logical network fabric that connects your VMs, VMkernel services (vMotion, vSAN, management), and the physical NICs/Uplinks. Misconfigured or overly-permissive vSwitches are a frequent path for lateral movement, data leakage, spoofing, and VLAN hopping. Hardening this layer dramatically reduces attack surface.

___________________________________________________________________________________

Visual Overview



Securing the Virtual Switch Layer (vSwitch / vDS) in VMware vSphere — A Complete Guide

Why this matters (short): the vSwitch / vSphere Distributed Switch (vDS) is the logical network fabric that connects your VMs, VMkernel services (vMotion, vSAN, management), and the physical NICs/Uplinks. Misconfigured or overly-permissive vSwitches are a frequent path for lateral movement, data leakage, spoofing, and VLAN hopping. Harden the vSwitch/vDS and you dramatically reduce your attack surface.

Table of Contents

  1. Planning & prerequisites

  2. Create and design the vDS (step-by-step)

  3. Add hosts and uplinks safely

  4. Create port groups and assign VLANs

  5. Harden security policies (Promiscuous, MAC changes, Forged transmits) — UI & PowerCLI

  6. Private VLANs (PVLAN) for intra-VLAN isolation

  7. Lock down management & VMkernel networks (vCenter, vMotion, vSAN)

  8. Disable/monitor port-level overrides & audit configs

  9. Automation and PowerCLI recipes (examples)

  10. Testing & verification checklist

  11. Monitoring, logging, and alerting recommendations

  12. RBAC, change control & recovery

  13. Summary & final notes

  14. Sources & further reading

___________________________________________________________________________________

1) Planning & prerequisites

Before you touch anything:

  • Inventory hosts, physical uplinks, and mapping to top-of-rack/core switches (which VLANs and MTU/Jumbo frames are required).

  • Determine which VLANs will carry management, vSAN, vMotion, VM traffic, and any tenant/guest VLANs.

  • Plan separate VLANs for management services (vCenter, ESXi mgmt, NSX/vShield, backup appliances). Never share management with general VM traffic unless you have a validated reason. VMware+1

2) Create and design the vSphere Distributed Switch (vDS) — step-by-step (vSphere UI)

Goal: centralize network config and apply consistent security policies.

  1. Log into vCenter using the vSphere Client (HTML5).

  2. In the Inventory, select the Data Center where you want the vDS.

  3. Right-click → Distributed Switch → New vSphere Distributed Switch (follow wizard). Choose an appropriate vDS version (use latest compatible). Broadcom TechDocs

  4. Configure number of uplinks (commonly 2+ for redundancy). Consider naming (uplink1, uplink2) and enable features you need (LLDP/LLDP Tx/Rx only if you will consume that info).

  5. Set MTU now if you require jumbo frames (e.g., 9000) — this must match upstream physical switches.

  6. Complete creation — you’ll now add Distributed Port Groups (next).

Why vDS: allows centralized, consistent policies and automation across hosts — recommended for medium/large clusters. Broadcom TechDocs

3) Add hosts & uplinks safely

  1. Right-click the vDS → Add and Manage Hosts → Add hosts. Select hosts and assign physical NICs to the defined uplinks.

  2. Prefer binding a single physical NIC per uplink and document which pNIC maps to which physical switch port.

  3. After adding, check the Uplink status on each host — ensure LACP or LAG requirements are satisfied on physical switches if you use link aggregation. Broadcom TechDocs+1

Important: only trunk required VLANs on the physical switch ports attached to the ESXi host. Avoid native/vlan 1 for management where possible.

4) Create distributed port groups and assign VLAN IDs (step-by-step)

  1. On the vDS, right-click → New Distributed Port Group.

  2. Name it clearly (e.g., PG-MGMT-vCenter, PG-vMotion, PG-Production-APP01).

  3. Under VLAN, choose the type:

    • VLAN (normal 802.1Q tag) → enter VLAN ID, or

    • VLAN Trunk → for ranges, or

    • Private VLAN / Promiscuous (if using PVLANs; see section 6).

  4. Finish and verify VMs/VMkernel adapters are attached to correct port groups. Broadcom TechDocs+1

5) Harden port group security settings (the three knobs)

Principle: set the three security flags to the most restrictive (Reject) by default and only open where a legitimate technical requirement demands it.

Security settings found on each distributed port group (Security tab):

  • Promiscuous Mode — controls whether VMs can see traffic not addressed to their MAC. Set to Reject except for monitoring appliances that explicitly need it (sniffers, IDS VMs).

  • MAC Address Changes — set to Reject. Prevents a VM/guest from modifying its effective MAC and impersonating other devices. Exceptions: nested ESXi or appliances that require MAC changes (document & isolate).

  • Forged Transmits — set to Reject. Prevents ESXi from sending frames with a source MAC different than the VM’s configured MAC. Exceptions exist for load balancers/HA appliances. Broadcom TechDocs+1

UI steps

  1. Right-click distributed port group → Edit Settings → Security.

  2. Set Promiscuous Mode = Reject, MAC Address Changes = Reject, Forged Transmits = Reject.

  3. Save and document exceptions.

PowerCLI example (safe pattern)

Use PowerCLI to change many port groups consistently — example pattern (read docs and test in lab first):

# Connect to vCenter
Connect-VIServer -Server vcenter.example.local -User admin -Password 'Secret'

# Example: set security policy to reject on a distributed portgroup
$pg = Get-VDPortgroup -Name "PG-Production-APP01"
$pg | Get-SecurityPolicy | Set-SecurityPolicy -AllowPromiscuous $false -MacChanges $false 
-ForgedTransmits $false

(See PowerCLI docs for Set-VDPortgroup / Set-SecurityPolicy usage). Broadcom Developer+1

Note on exceptions: some HA/clustering, load balancer, nested hypervisor, or gateway appliances may need MAC changes or forged transmits — place those VMs on dedicated, documented port groups and restrict access to those port groups.

6) Private VLANs (PVLAN) — when to use and how (brief)

When: multi-tenant or DMZ scenarios where you want VMs on the same primary VLAN but prevented from talking to each other (isolate guests while allowing external routing).

High level steps:

  1. On the vDS, create PVLAN entries (Primary/Secondary) — vCenter/vDS supports PVLANs.

  2. Create distributed port groups attached to the PVLANs with type: Promiscuous/Community/Isolated.

  3. Attach VMs accordingly and test.
    PowerCLI has New-VDSwitchPrivateVlan for PVLAN creation. PowerCLI Core Documentation+1

7) Lock down management VMkernel and other special networks

Separate networks: place vCenter, ESXi Management, vMotion, vSAN, and any backup or replication VMkernel NICs on dedicated port groups and VLANs. Examples:

  • PG-ESXi-MGMT (VLAN 10)

  • PG-vMotion (VLAN 20)

  • PG-vSAN (VLAN 30)

Steps:

  1. Create VMkernel adapters attached to proper distributed port groups (vSphere UI → Host → Configure → Networking → VMkernel adapters → Add).

  2. Restrict access via upstream switch ACLs so only allowed admin workstations/networks can reach management VLANs. Avoid routing management VLANs to untrusted networks. VMware

vMotion encryption & vSAN encryption: enable encrypted vMotion for privacy and vSAN encryption to protect data at rest. Both are recommended where compliance or sensitive data exist. VMware

8) Disable/monitor port-level overrides & enforce cluster policy

Why: vCenter allows port-level configuration overrides — this can create inconsistent security settings and be abused by admins or attackers.

Steps:

  1. Ensure Port-level configuration overrides are disabled where your policy requires uniformity. (vSphere default is to disallow overrides; verify).

  2. Use the vSphere STIG and the VMware Hardening Guide as policy baseline and harden accordingly. STIG VIEWER+1

9) Automation & PowerCLI recipes (practical)

Create a vDS and port group, attach hosts, set security policy (sketch):

Connect-VIServer -Server vcenter.example.local

# Create vDS
$dc = Get-Datacenter -Name 'DC1'
$vd = New-VDSwitch -Name 'vDS-Prod' -Location $dc -NumUplinks 2

# Create distributed port group
New-VDPortgroup -VDSwitch $vd -Name 'PG-Production-APP01' -NumPorts 128

# Add hosts & map physical NICs
Add-VMHostNetworkAdapter -VMHost (Get-VMHost 'esxi01.example.local') -DistributedSwitch $vd 
-UplinkPort 'Uplink1'

# Set security policy
Get-VDPortgroup -VDSwitch $vd -Name 'PG-Production-APP01' | Get-SecurityPolicy | 
Set-SecurityPolicy -AllowPromiscuous $false -MacChanges $false -ForgedTransmits $false

Note: run in a lab first. See official PowerCLI documentation for the exact cmdlet parameters and versions. Broadcom TechDocs+1

10) Testing & verification checklist

  • Validate each distributed port group has Promiscuous, MAC changes, Forged transmits = Reject (except documented exceptions). (Use UI or PowerCLI script to audit.) VMware Communities

  • Attempt a controlled MAC spoof from a test VM (in a lab) to confirm MAC changes are blocked.

  • Confirm vmkernel services are on separate VLANs and not reachable from untrusted networks.

  • Verify vMotion is encrypted if handling sensitive workloads.

  • Back up your vDS configuration (export settings) before mass changes. Use Export-VDSwitch for vDS export. Broadcom Developer

11) Monitoring, logging & alerting

  • Forward vCenter/ESXi logs to centralized SIEM/Graylog for detection of suspicious events (unexpected port-security changes, change in trunk config, unusual MAC table changes).

  • Monitor for: DHCP rogue servers, unexpected MAC movements between hosts, and new port group creation.

  • Consider enabling NetFlow (or equivalent) at distributed switch level (if using NSX or third-party monitoring) to inspect East-West flows. VMware

12) RBAC, change control & recovery

  • Use least-privilege roles in vCenter — separate Network Admin vs VM Admin roles so fewer admins can change network security settings. Enable SSO + MFA (e.g., Duo) for all vCenter administrators. VMware

  • Require change control for any port-level overrides and keep an audit trail.

  • Regularly export vDS configs and store off-site for recovery.

13) Summary & final notes

  • Default to Reject on Promiscuous Mode, MAC Address Changes, and Forged Transmits — document exceptions. Broadcom TechDocs+1

  • Use vDS to centralize policies and PowerCLI to automate consistent settings across clusters. Broadcom TechDocs+1

  • Separate management traffic, enable encryption where appropriate, and monitor/log changes. Use the VMware Hardening Guide and STIGs as baselines. VMware+1

14) Sources & further reading (live links)

I checked official docs and community sources—below are curated, live links you can read now. I filtered out broken/404s.

  • VMware TechDocs — Create a vSphere Distributed Switch and general vDS docs. Broadcom TechDocs

  • VMware TechDocs / PowerCLI — Create and customize vSphere distributed switch via PowerCLI. Broadcom TechDocs

  • VMware Security Hardening Guides — the official security configuration & hardening baseline. VMware

  • VMware STIG (vSphere 8.0 vCenter) — security technical implementation guidance (useful controls). STIG VIEWER

  • Broadcom / VMware TechDocs — Forged Transmits, Promiscuous Mode and MAC Address Changes explanations. Broadcom TechDocs+1

  • PowerCLI Reference — Set-VDPortgroup, New-VDPortgroup, Set-VDSwitch docs and examples. Broadcom Developer+2Broadcom Developer+2

  • vSphere Distributed Switch configuration & best practices (community guides & blogs). Virtualization Howto+1


Comments

Post a Comment

Got something to say? Drop a comment below — let’s chat!

Popular posts from this blog

Proxmox VE + full Kubernetes (kubeadm) step-by-step

  Production-ready guide: Proxmox VE + full Kubernetes (kubeadm) step-by-step A practical, end-to-end walkthrough to deploy a hardened Proxmox VE environment and run a production-grade Kubernetes control plane and worker nodes (kubeadm). Includes HA control-plane, etcd considerations, load-balancing, networking (Calico), storage (Longhorn + option for Ceph), security hardening, backups, and monitoring. This blog assumes you have basic Linux + virtualization familiarity and a small cluster of physical servers for Proxmox (3+ nodes recommended for HA). Where choices exist I explain trade-offs and give concrete commands and config snippets you can copy. Outline Goals & prerequisites Logical architecture (ASCII diagram) Prepare Proxmox VE hosts (install & base hardening) Proxmox networking and storage planning Create cloud-init VM template for Kubernetes nodes Deploy VMs for Kubernetes control plane and workers Provision HA load balancer for kube-api (H...
Read more

Monitoring Virtualized Environments with Graylog: A Complete Guide

  Monitoring Virtualized Environments with Graylog: A Complete Guide Virtualization has become the backbone of modern datacenters, but as environments grow, so does the challenge of monitoring them effectively. Whether you’re running VMware vSphere, Hyper-V, Proxmox, KVM, Xen, or Nutanix , log visibility is essential for performance, capacity planning, and security. Graylog , with its flexible pipelines, dashboards, and alerting capabilities, provides a powerful centralized logging solution for virtualized infrastructures of all sizes. This guide walks through everything you need to know to monitor your virtual environment using Graylog—from collecting hypervisor logs to building dashboards and alerts that actually matter. Why Graylog for Virtualization Monitoring? Virtualization platforms all generate significant amounts of structured and unstructured log data: Host health VM lifecycle changes Storage access Virtual network changes Failovers and migrations ...
Read more

Building a Secure Virtual OPNsense 26.1 Firewall with VLANs, DMZ, and CARP High Availability

  Building a Secure Virtual OPNsense 26.1 Firewall with VLANs, DMZ, and CARP High Availability In this guide, we’ll walk through setting up OPNsense 26.1 as a primary gateway in a virtualized environment using Hyper-V , with VLAN segmentation, a DMZ, staged VPN, and optional CARP failover for high availability. This architecture ensures strong isolation, centralized traffic control, and enterprise-grade security — all without joining the firewall or hypervisor to Active Directory , reducing the attack surface. 1️⃣ Architecture Overview Logical Design Internet │ [External vSwitch] │ WAN (OPNsense) ┌──────────────────┐ │ OPNsense │ │ VLAN Gateways + HA│ └──────────────────┘ │ [Internal vSwitch - Trunk] │ ┌───────────────┬──────...
Read more