NSX distributed firewall and vDefend: VCF 9 licensing, DFW rules and phased microsegmentation

NSX distributed firewall: how it works and where vDefend comes in

The NSX distributed firewall (DFW) is a stateful Layer 2 to 7 firewall that runs on every ESXi host prepared for NSX and applies its rules at each virtual machine’s virtual NIC (vNIC). Each vNIC has its own filter, which holds the rules applied to that VM, and the firewall “maintains active flows per VNIC”, per Broadcom’s vDefend 9.1 troubleshooting guide, so traffic between two VMs on the same host is filtered without leaving the host. In VCF 9 the firewall is bought separately: the VCF licence brings NSX networking, and the distributed and gateway firewalls come with VMware vDefend, whose products “can be purchased as add-ons with a VMware Cloud Foundation purchase”, per Broadcom’s vDefend edition guide, updated 1 October 2026.

On VCF, the DFW protects VMs on NSX segments, VLAN-backed or overlay, and VMs on vSphere Distributed Switch port groups once NSX is activated on them, so a VLAN-based estate need not move workloads to overlay networks first. VMware vSphere Foundation (VVF) has no NSX and therefore no distributed firewall; our comparison of VVF and VCF 9.1 covers the rest. Zones, flow mapping and the vendor-neutral route to default deny are in our guide to network segmentation and microsegmentation.

What VCF includes and what the vDefend add-on adds

Broadcom’s vDefend 9.1 entitlement tables mark the networking and inventory features as “Provided by VCF License”; the firewall and threat prevention features belong to the vDefend editions.

Broadcom TechDocs: vDefend Firewall 9.1 feature and edition guide, with the edition summary and the distributed and gateway firewall entitlement tables (all updated 1 October 2026); NSX overview in the VCF 9.1 documentation (5 October 2026).

As of October 2026, Broadcom’s edition guide lists one edition for purchase, VMware vDefend, which combines stateful firewalling with IDS/IPS, malware prevention, network sandboxing, network traffic analysis (NTA) and network detection and response (NDR). The Advanced Threat Prevention (ATP) add-on gives owners of the older vDefend Firewall edition the threat prevention functions. vDefend Firewall and vDefend Firewall with Advanced Threat Prevention are “no longer offered for sale”. Broadcom’s VCF 9.1 FAQ of 3 September 2026 names vDefend Firewall among the advanced services that “continue to be licensed separately”.

vDefend licensing: per-core counts, keys and License Hub

Broadcom’s vDefend programme document of 13 August 2026 licenses vDefend per core. The distributed firewall takes “one (1) Core of VMware vDefend to deploy one (1) Core of Distributed Firewall on the deployed host”, with at least 16 cores per processor, the same counting rule as for VCF, which our guide to counting VMware cores explains. A gateway firewall takes three vDefend cores for each of its vCPUs. The agent for a physical server takes one vDefend core for every four of its cores, again with the 16-core minimum per processor. Since vDefend 9.1 the DFW can be enabled per cluster, and disabling it removes the DFW filters from the cluster’s hosts, “impacting licensing core counts”, so the vDefend count can follow the clusters that need microsegmentation. NSX Manager writes a weekly report of the security features’ core usage, exported through /api/v1/licenses/security-usage.

Broadcom TechDocs: vDefend Firewall 9.1 prerequisites (1 October 2026) and 9.1 release notes (initial edition 12 May 2026); Broadcom KB 430651 and KB 446503 (no date shown, read on 6 October 2026).

Broadcom’s VCF 9.1 design blueprint (5 October 2026) places the License Hub appliance in the management domain of the first VCF instance, one per fleet; in disconnected mode “the license must be manually uploaded at least once every six months”. KB 451106 describes NSX 9.0 hosts that, without the vDefend licence and once the grace period was over, received only the default rule, so we would have License Hub and the converted licence ready before NSX Manager is upgraded to 9.1.

Our VMware optimisation service audits your estate and licences and matches Broadcom editions to your actual workloads. Send us the core count of each cluster and the clusters where you would run the distributed firewall.

How NSX DFW rules are processed

NSX sorts distributed firewall policies into five categories, evaluated from left to right: Ethernet, Emergency, Infrastructure, Environment and Application. Inside a category the rules are read from the top, and “The first rule in the firewall table that matches the packet parameters is enforced.” Traffic that matches nothing reaches the default rule at the bottom, which allows traffic after host preparation and is the last rule to switch to block, as our segmentation guide explains.

Layer 3 rules are stateful unless set otherwise, while Layer 2 rules can only be stateless. Drop discards a packet silently, Reject answers with a TCP reset for TCP and an ICMP administratively prohibited message for other traffic, and Jump to Application, available only in the Environment category, passes matching traffic on to the Application category.

Each policy has an Applied To field. “By default, the policy Applied to field is set to DFW, and the policy rules are applied to all workloads”, which puts every rule on every vNIC filter. Set to a group, it limits the policy to that group’s members, and a policy-level Applied To overrides the rule level. IP addresses, MAC addresses and directory objects in such a group are not processed. Rules take effect when published, and logging is off by default; with logging on, each host writes to /var/log/dfwpktlogs.log.

NSX DFW rule design: tags, groups and categories

Write the rules against groups, and fill the groups from tags rather than IP addresses. NSX tags VMs, segments and segment ports, and a group takes members dynamically by tag, VM name or segment, or statically. We would start with three tag scopes, environment, application and tier, so that a new database VM joins the right groups when it is tagged, without a rule edit.

Broadcom’s staged model puts shared services in the Infrastructure category: allow rules to the approved directory, DNS and logging servers first, then lockdown rules that block “communications to rogue servers”, and rules that block Telnet, FTP and TFTP across the data centre. Zones such as development, QA, UAT and production are separated in the Environment category, with Jump to Application for traffic inside a zone. Each application then gets one policy in the Application category, applied to its group, with rules between its tiers and a catch-all at the end.

For FQDN rules, Broadcom writes that “DNS traffic needs to go through the rule that has the DNS Service defined”, placed above them, and that VMs must resolve names through a DNS server, not static entries. Keep the exclusion list, which takes segments, ports or groups out of enforcement, short. The DFW filters workload traffic at vNICs; ESXi management interfaces need their own controls, covered in our guide to hardening ESXi hosts and vCenter against ransomware.

Monitoring mode and rule analysis tools

None of the DFW rule actions is monitor-only, so a rule set to allow with logging on serves as the monitoring stage. Broadcom’s deployment guide uses Jump to Application the same way in the Security Services Platform: the protection rule between two zones passes traffic while its flow counter shows what still crosses, “Protection Rule Flow: 0” is the indicator that nothing does, and Broadcom recommends “monitoring each environment pair for days”. Without that platform, the rule’s hit count and logs show the same flows. Hit counts lag, since “Rule level statistics are aggregated every 15 minutes from all the transport nodes”, and a counter read straight after a test can still show zero.

Every publish creates an auto draft that can be published to return to the previous configuration, and NSX keeps up to 100 auto drafts and 10 manual ones. A draft holds the distributed firewall’s “policy sections and rules”, so record changes to groups and tags separately. Broadcom’s DFW lifecycle has a Refine phase, to review rule hit counts, tune rules on flow visibility and “Run a Firewall Rule Analysis Report”, before obsolete rules are disabled or deleted.

Security Intelligence, a vDefend feature, visualises flows between groups, VMs and IP addresses and recommends policies, groups and services. It runs on the Security Services Platform, which its own installer deploys as a separate instance, so plan its capacity before the assessment. For troubleshooting, Broadcom’s lifecycle names Traceflow, included in VCF; on a host, summarize-dvfilter lists each VM’s filter and vsipioctl getrules -f <filter> the rules applied to that vNIC.

NSX DFW performance considerations

Because each host filters its own VMs, firewall capacity grows with the cluster, and the filtering uses host CPU. L7 App ID, FQDN rules and IDS/IPS look beyond ports and protocols and take more CPU per flow than port rules; for IDS/IPS, the vDefend 9.1 release notes make “Turbo Mode IDS/IPS” the default on 9.1 ESXi hosts, for “higher inspection throughputs”. ESXi 8.x hosts keep the Classic mode, which Broadcom advises against “due to significant performance degradation”. Keep L7 and IDS/IPS rules for the flows that need them, and leave CPU headroom on those hosts.

Broadcom’s DFW lifecycle advises scoping rules through Applied To “to optimize performance”: a policy applied to an application’s group reaches only its VMs and keeps the per-vNIC rule tables short. Logging every rule adds disk and network load on each host, so log the catch-all rules and the rules under observation, and forward the host logs to a central log server.

Rolling out NSX microsegmentation in phases

Broadcom’s vDefend 9.1 documentation presents the rollout as a staged “Security Journey” in four stages, Security Assessment, Infrastructure Services Protection, Environment-level Protection and Application-level Isolation, which its design library turns into the self-deployment guide “DFW 1-2-3-4”. The steps below follow those stages, with a maintenance window and a rollback for every step that enforces. Where microsegmentation fits among identity, devices and access is in our zero trust roadmap for a mid-size company.

1. Settle the licence path: a vDefend key in NSX Manager on 4.x and 9.0, or License Hub and converted licence files on 9.1, and the clusters that will run the DFW.
2. Tag the VMs by environment, application and tier, build the groups and collect flows through at least one month-end, with Security Intelligence if deployed.
3. In the Infrastructure category, publish the allow rules for directory, DNS, logging and other shared services, then the lockdown rules and the block on Telnet, FTP and TFTP.
4. In the Environment category, set one protection rule per pair of zones to Jump to Application, watch its flow counter or hit count for days and switch it to Drop or Reject in a maintenance window once it stays at zero.
5. In the Application category, take one application at a time: a policy applied to its group, rules between tiers and a catch-all on allow with logging, switched to Drop after the next month-end.
6. Switch the default rule to Drop last, once every VM falls under a policy; the auto draft of the previous publish is the rollback.
7. Review hit counts, run the rule analysis report and check that new VMs carry their tags, since an untagged VM falls outside the tag-based groups.

Under our Cyber Resilience service, our engineering partner Vixen.UNO segments the network and rolls changes out step by step, in agreed maintenance windows with a rollback plan. Describe the first application you would isolate and how its VMs are tagged today.

What we do

Eurokommerz holds the contract; our engineering partner Vixen.UNO delivers the engineering. Under VMware optimisation, Vixen.UNO audits your estate and licences, matches Broadcom editions to your actual workloads, and modernises vSphere, vSAN, NSX and VCF in agreed maintenance windows with a rollback plan at every stage, then provides support under an agreed SLA. Under Cyber Resilience, the same partner sets up network segmentation and zero-trust access following NIST CSF 2.0, after an assessment that ends with a risk map and a prioritised action plan. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ