Deep Dive of the Day Managing vDefend distributed firewall rules as code, and how they sit alongside VPC rules
If you're starting to bring the distributed firewall under Terraform, Broadcom's own primer, Beginning Micro-segmentation as Code, is a good place to anchor. It uses the vmware/nsxt provider against NSX Manager and builds the model from two resource types: nsxt_policy_group for groups, which land in the default domain at /infra/domains/default/groups/<id>, and nsxt_policy_security_policy for a policy in a category such as Application, with nested rule blocks that reference source and destination groups and services by their path.
The practical lesson from that walkthrough is how many settings you get by default without writing them. A rule with only a name, action, groups and a service comes out of the plan with direction IN_OUT, ip_version IPV4_IPV6, stateful true, locked false and a computed sequence number. That's fine for a demo, but in production it's worth writing the ones you care about explicitly, so a reviewer can see them in the pull request rather than discovering them in terraform plan. Because rules reference group paths, Terraform creates groups before the policy without you having to add depends_on.
The primer also has some sensible hygiene: commit .terraform.lock.hcl so every run uses the same provider version, and remember that a plan run without -out doesn't guarantee the same actions at apply time. Its provider block uses allow_unverified_ssl = true and hard-coded credentials, which is demo shorthand; in real pipelines pull credentials from a secrets store and trust NSX Manager's certificate properly.
Where VCF 9 changes the picture is VPCs. Daniel Krieger's VPC security write-up explains the processing order: default project rules first, then project rules, then VPC rules, then the default Layer 3 rule if nothing matches. VPC admins create their east-west rules under the VPC, and those land in the Application category but are hidden in the DFW view by default, while project and enterprise admins can override them. If your Terraform owns policies in the Application category, that's the overlap to think about before two teams write rules for the same workloads.
Krieger's gotchas are worth carrying into any as-code design. New projects can get generated default DFW rules that allow intra-project traffic and DHCP and block the rest, but those rules can't be deleted and are created without TCP Strict, so he recommends writing your own policies on top rather than adding rules to the generated one, and setting "applied to" even on VPC rules. The default project doesn't get that generated rule set at all, and its default policy allows traffic, so a fresh lab is open until you add rules.
One licensing point affects labs and production alike: Krieger notes that both the DFW and the VPC gateway firewall need an additional firewall add-on licence (the vDefend firewall), which VCF 9 doesn't include. In a nested lab, a good pattern is to keep one small Terraform workspace per project or VPC, start with groups and an allow-list policy with logging on, and only switch the default Layer 3 rule to drop once you've watched the logs for a while.
Based on Terraform and VMware vDefend Firewall: Beginning Micro-segmentation as Code (VMware) Official VCF 9 – NSX VPC Part 3 – Security (SDN-Warrior, Daniel Krieger)
