Category: Security

The power to secure workloads at their very core is what excites me most. With technologies like the vDefend Firewall, we can stop threat actors in their tracks, long before they ever touch an operating system. This isn’t security bolted on after the fact; it’s protection woven directly into the I/O chain at the vNIC level, where it’s most effective. And my passion for this goes far beyond my role at Broadcom, it comes from years of working in network and security architecture and knowing firsthand how critical it is to prevent threats before they have a chance to spread.

What makes this different is where the enforcement happens. We stop unwanted traffic right at the vNIC level in the I/O chain deep in the kernel, before it ever has a chance to propagate. There’s no need to hairpin traffic, no complex re-architecture of the network, and no forced dependencies on fragile designs. We’re already in the hypervisor, already in the kernel; we just need to enable the functionality, on board your Distributed Virtual Port Groups (DVPGs), and apply policy.

Contrast this with “micro-segmentation” approaches elsewhere:

• In the public cloud, security often means slicing networks into increasingly smaller subnets just to make use of Security Groups. It’s a process that’s time-consuming, complex, and unforgiving, demanding absolute precision. The trade-off? You lose advanced controls and visibility, leaving you dependent on protections inside the operating system rather than stopping threats before they get there.
• In traditional environments, segmentation often requires hairpinning traffic through multiple physical firewalls. These appliances are not optimized for East-West traffic, making the approach costly, inefficient, and difficult to scale.

Both approaches add operational complexity. With vDefend, we can achieve segmentation in a more direct, efficient, and inherently secure way.

This is why I say from a security perspective, we’re built different.

And to make this journey even smoother, I will be using Nikodim Nikodimov’s GitHub repo as my 🛠️ Terraform baseline for automating port association, group creation, and tagging of my Distributed Firewall (DFW) policies for my Management Domain:
👉 vcf-mgmt-wld-security on GitHub

For anyone diving into VMware Cloud Foundation and vDefend Firewall looking to truly segment their Management Domain, this is an incredible starting point.

A few requirements before you get going:

• A VCF Environment and NSX Managers
• In VCF 9.0 your NSX will grab a valid VCF license from the vCenter that it’s connected to, this happens automatically
• A valid vDefend Firewall License (The VCF license must be present prior to adding the vDefend Firewall license)
• Activate NSX on DVPGs, this can be done from the NSX Manager → System Tab → Fabric Drop Down → Hosts Sub Tab in the ⚙️ Actions menu. (Screenshot below)
• A machine with Terraform installed
• Nikodim’s GitHub Repo 👉 vcf-mgmt-wld-security on GitHub

In my environment, I’ve already Activated NSX on my DVPGs, and the process completed fairly quickly.

The number one question I am asked, is there any impact on existing traffic?

• No Outage on Existing Traffic → The action does not bounce VMs or drop traffic. VMs attached to those DVPGs keep running normally.
• Policy Enforcement Becomes Active → Once activated, NSX policies (DFW rules, groups, tags, etc.) can be applied to workloads on those port groups. That’s the main effect.
• No Network Rewiring → This doesn’t rewire your uplinks or force a switch migration. Traffic forwarding continues as before.

What’s included in Nikodim’s GitHub:

After downloading the repo, your primary focus should be the terraform.tfvars file, this is where you’ll define the details of your environment. Files with the m01 prefix correspond to your Management Domain, while those with the w01 prefix are for your Workload Domain. In my Home Lab, I don’t have a Workload Domain deployed, so I simply commented out several of the w01 entries to make everything work smoothly.

Here’s how I edited my terraform.tfvars file:

dns_server          = "10.20.254.254"
ntp_server          = "10.20.254.254"
dhcp_server         = "10.20.254.254"
ad_server           = "10.20.254.250"
smtp_server         = "10.20.254.251"
bastion_host        = "192.168.1.169"
#make sure you put a valid host here, this was my main workstation. If you fail to list a valid value here you won't be able to access your Management Components.
tools_server        = "10.20.254.100"
backup_server       = "10.20.254.100"
#sftp server
siem_server         = "10.20.250.221"

#mgmt-domain
nsx_manager         = "nsx.varchitected.com"
nsx_username        = "admin"
nsx_password        = "VMware123!VMware123!"
sddc_manager        = "sddc-manager" 
#this is a virtual machine name
m01_vcenter         = "vcenter"
#this is a virtual machine name
m01_nsx_manager_a   = "nsx-a"
#this is a virtual machine name
m01_nsx_manager_b   = "nsx-b"
#this is a virtual machine name
m01_nsx_manager_c   = "nsx-c"
#this is a virtual machine name
m01_edges           = "10.90.250.91-10.90.250.92"
m01_hosts           = "10.20.250.101-10.20.250.104"
#this is looking for an IP Address or Range
m01_sspm            = "10.20.255.100-10.20.255.130"
#this is looking for an IP Range
vm_management_dvpg  = "vcf-vds01.[DVPG 250] SDDC MANAGEMENT"
aria_x_ans          = "vcf-vds01.[DVPG 250-1] ARIA SUITE"
#DVPG
aria_ans            = "vcf-vds01.[DVPG 250-1] ARIA SUITE"
#Same as above
m01_ssp_dvpg        = "vcf-vds01.[DVPG 255] VDEFEND SSP"
#I have a dedicated DVPG for SSP
m01_sspi_vm         = "ssp-deploy"

#wld-domain
w01_vcenter         = ""
w01_nsx_manager_a   = ""
w01_nsx_manager_b   = ""
w01_nsx_manager_c   = ""
w01_edges           = ""
w01_hosts           = ""
w01_sspm            = ""
w01_ssp_dvpg        = ""
w01_sspi_vm         = ""
#I don't have a Workload Domain in my lab

Don’t be me. I accidentally assigned my entire SDDC-MGMT DVPG (vcf-vds01.[DVPG 250] SDDC MANAGEMENT) as a member of the Aria Suite group. While this Terraform works fine if you have configured a dedicated DVPG for your Aria Suite components, it’s something to be careful with. You may need to change the Terraform to validate against a Tag. Terraform will validate any DVPG listed in the tfvars file, so a misconfiguration here could unnecessarily block traffic.

I updated the group membership to use a tag-based approach for the VMs tied to the Aria Management components. I made the change through the GUI, though it could just as easily have been done in Terraform. Nikodim’s Terraform configuration provides a solid head start by eliminating much of the manual policy creation, it’s then up to you to tailor and complete it for your specific environment.

The policy is now behaving as intended, with traffic reaching the Application category without being denied first.

Another critical rule is outbound internet access. While your Network team may enforce this at the perimeter firewall, you should also enforce it yourself. In this case, we’re using Context Profiles to allow outbound HTTPS traffic only to the Broadcom Depot FQDNs for updates, nothing more.

This INTERNET_FQDNs Context Profile is configured to target wildcard domains for the destination of your rules, you can be more specific with the domains used if you want (see below):

Remember, NSX evaluates policies left to right, top to bottom → policy and rule order matters:

• Ethernet → Layer 2 rules.
• Emergency → High-priority, critical rules.
• Infrastructure → Rules for core network services and infrastructure components.
• Environment → Rules for specific environments like production or development.
• Application → Application-specific rules.

Here are a few best practices and preparation tips to keep in mind before moving into Production.

• Flip any Default Drop rules to allow initially in Terraform until you have it working the way you want, once you validate traffic flow you can flip these rules to drop. A list of the Default Drops are below:
  • M01_WLD Default Drop → M01_WLD Policy
  • W01_WLD Default Drop → W01_WLD Policy
  • Aria Suite Default Drop → VCF01 Aria Suite Policy
• Lock down management access to your trusted Bastion Hosts, and always plan for disaster. Because it’s not if it happens, it’s when.
• Tighten your outbound internet policy so only your vCenter and SDDC Manager have the outbound access they truly need. Threat groups like Scattered Spider have abused outdated vCenter appliances to maintain persistence in environments. With proper segmentation in place, it becomes highly unlikely that these clowns could scale the walls you’ve built. Restrict only to HTTPS and use Context Profiles only for the specific Domain Names that the Appliances need.
• Always use Applied To wisely, let your policies land only where they’re needed. No sense in weighing down every VM’s firewall when a few will do.
• Test, validate, verify, and confirm that your rules are working the way you want. Leverage CURL, Netcat, Telnet, and Ping to validate the connectivity between your appliances.
• Use the Security Services Platform (SSP) included with vDefend Firewall to uncover unprotected flows in your environment, and secure them.
• Don’t forget to consider 3rd party solutions like Backup Vendors that heavily interact with your vCenter and Hosts. Also ensure that your SFTP Backups for your VCF Appliances are working as expected.
• Use the VMware Ports and Protocols site as a reference point of the ports used for communication in VCF: https://ports.broadcom.com/
• And as always… keep your layers tight and your traffic light, stay segmented, my friends.

Ultimately, the takeaway is simple: with the right policies and segmentation, you can secure your Management Domain, VI Workload Domains, Virtual Machines, Containers, and AI workloads, all from a single platform. Bringing enterprise-grade protection to your modern private cloud. I hope this walkthrough showed you not just the “how,” but also gave you the confidence to take the next steps in hardening your environment.