TL;DR · Key Takeaways
- The Distributed Firewall is a stateful firewall in the hypervisor kernel, enforced at every VM vNIC. It is distributed across every host and the policy follows the VM on vMotion.
- Rules are organized into ordered categories: Ethernet, Emergency, Infrastructure, Environment, Application, evaluated top to bottom, category by category, then the default rule.
- Applied-To is the field that matters most. It scopes where a rule is enforced. Get it wrong and you change behaviour far beyond the VMs you meant to.
- Host prep activates the DFW with a default rule of allow. Moving to zero trust means flipping that to deny, but only after the explicit allow rules are in place.
- The DFW is a vDefend feature (Part 3), not part of the base VCF entitlement. It is the main reason most teams license vDefend at all.
This is the part of the series people came for. Micro-segmentation is the headline reason most organizations buy NSX, and the Distributed Firewall is how it happens. It is also the most unforgiving object in the platform. The DFW puts a stateful firewall at every virtual NIC in your data center, which is enormous power, and the same power means a single careless rule can sever traffic for a thousand VMs in one publish. I have watched a confident engineer take out a production segment with one rule that had the wrong Applied-To, in front of the customer. So we are going to go slow here, because understanding the DFW model before you write a rule is the difference between security and an outage.
What the DFW is, and where it runs
The Distributed Firewall is not an appliance and not a chokepoint. It is enforcement code in the ESXi kernel, applied at the virtual interface of each VM, on every prepared host. When a packet leaves a VM, the DFW evaluates it right there at the vNIC before it ever reaches the segment, and the same happens on the way in. Because it lives on every host, it scales with your compute, there is no central box to overload, and because the policy is attached to the workload rather than to a physical location, it moves with the VM when it vMotions. East-west traffic between two VMs is filtered without ever leaving the host they share. That is what makes micro-segmentation practical: the firewall is everywhere at once.
Rule categories and evaluation order
DFW rules are not one flat list. They are organized into ordered categories, and the order is fixed: Ethernet, Emergency, Infrastructure, Environment, Application. The firewall evaluates them left to right, top to bottom within each, and the first matching rule wins. Understanding this order is what stops your rules fighting each other. Emergency is where you put a quarantine or a break-glass block that must beat everything below it. Infrastructure is for the shared platform services every workload needs, DNS, NTP, AD, backup. Environment separates broad zones like production from development. Application is where the specific app-tier rules live, the web-to-app-to-database micro-segmentation that is the whole point. Put a rule in the wrong category and it either never matches or matches before something it should not.
| Category | Purpose | Typical rules |
|---|---|---|
| Ethernet | Layer 2 filtering. | MAC-based rules (rare). |
| Emergency | Break-glass, highest precedence. | Quarantine a compromised VM. |
| Infrastructure | Shared platform services. | Allow DNS, NTP, AD, backup. |
| Environment | Broad zone separation. | Block prod from dev. |
| Application | Per-app micro-segmentation. | Web to app to database tiers. |
Anatomy of a rule, and why Applied-To matters most
A DFW rule has the fields you would expect, source, destination, service, action, and logging, plus one that NSX newcomers underestimate every time: Applied-To. Source, destination, and service decide whether a packet matches the rule. Applied-To decides where the rule is enforced, that is, on which VMs’ vNICs NSX actually installs it. These are different questions, and conflating them is the single most expensive DFW mistake. If you leave Applied-To at the default of DFW, the rule is pushed to every VM in the deployment. Scope it to a security group, and it is installed only on those VMs. Applied-To is both a performance control, fewer rules per vNIC, and a blast-radius control, a mistake stays contained.
| Field | What it controls |
|---|---|
| Source / Destination | Which traffic matches (groups, IPs, segments). |
| Service | Ports and protocols, or an app-ID service. |
| Applied-To | Where the rule is enforced. Scope it to a group, not the whole DFW. |
| Action | Allow, Drop, or Reject. |
| Logging | On or off (rate-limited per host); essential for tuning. |
The default rule and the zero-trust pivot
When NSX prepares your hosts, the DFW comes up with a default rule of allow, so that turning on the firewall does not instantly break every VM-to-VM flow. That is a sensible starting point, but it is the opposite of zero trust. The goal of micro-segmentation is a default rule of deny, where nothing is permitted unless an explicit rule allows it. The pivot from allow to deny is the most consequential change you will ever make in the DFW, and the order is everything: you build and validate all the explicit allow rules first, confirm with logging that real traffic is matching them, and only then flip the default to deny. Flip it first and you black-hole the data center. This migration is a project, not a checkbox, and it is the subject of Part 21.
Stateful by default
The DFW is stateful out of the box, which means you write a rule for the connection’s initiating direction and the return traffic is allowed automatically, the same model every modern firewall uses. You can make a policy section stateless if you have a specific reason, but you rarely should, because stateless rules force you to hand-write return rules and they lose the connection tracking that makes the firewall both safe and simple. Leave it stateful unless something concrete demands otherwise. Combined with the categories and Applied-To, statefulness is what lets you express security as intent, allow web to app on 8443, rather than as a pile of bidirectional port rules you have to maintain by hand.
Verifying the DFW on the host
Because the DFW is enforced in the kernel, the truth about what is actually installed on a VM lives on the host, not just in the UI. When a rule does not behave as you expect, drop to the host and look at what the datapath really has. The vsipioctl tooling shows the rules and connection state for a given virtual interface, and it is how you confirm whether your Applied-To landed where you intended.
# On the ESXi host, find the VM's filter (vNIC), then read its rules
summarize-dvfilter # list filters; find your VM's vNIC filter name
vsipioctl getrules -f <filter-name> # the rules actually installed on that vNIC
vsipioctl getflows -f <filter-name> # live connection state for that vNIC
# If a rule you expect is missing here, the Applied-To did not include
# this VM. If an unexpected rule is present, your scoping is too broad.This single check settles most DFW arguments. If the rule is on the vNIC and traffic still drops, the rule logic is wrong. If the rule is not on the vNIC at all, the Applied-To or the group membership is wrong. Knowing which of those two it is saves you from changing the right rule for the wrong reason.
The DFW mistakes that cause outages
Almost every serious DFW incident I have been called into traces back to a small set of mistakes. None of them are exotic; they are the predictable ways a powerful tool gets misused under time pressure. Keep this list where you can see it before you publish.
| Mistake | Result | Avoid it by |
|---|---|---|
| Applied-To left at DFW | Rule pushed to every vNIC; wide blast radius. | Scope Applied-To to a group, always. |
| Default flipped to deny too early | Black-holes traffic with no allow rules. | Build and verify allow rules first. |
| Rule in the wrong category | Matches too early or never matches. | Match category to the rule’s job. |
| No logging while tuning | You cannot see what real traffic needs. | Log allow rules during the build phase. |
| IP-based rules that never update | Rules drift as workloads change. | Use dynamic groups and tags (Part 13). |
What I’d Do
Learn the model before you write a rule. Put each rule in the right category, scope Applied-To to a group every single time, and treat the default of DFW as the dangerous setting it is. Keep the firewall stateful, use logging to validate that real traffic matches your allow rules, and treat the move from default-allow to default-deny as a staged project with a rollback, never a one-click flip. Above all, internalize that the DFW’s power and its danger are the same property: it is everywhere at once, so a good rule protects everything and a bad rule breaks everything. Respect that and micro-segmentation becomes the strongest control in your data center. Next up is Part 13: security groups, tags, and dynamic membership, the engine that makes these rules describe workloads instead of IP addresses. Is your Applied-To scoped on every rule you have written so far?
Default deny is a destination, not a starting point
The distributed firewall ends in a default rule, and the instinct of every security-minded engineer is to flip that default to deny as fast as possible. Resist it. Flipping to default-deny without a real picture of how your applications actually communicate is the single fastest way to take down production, because the rules you have not written yet are exactly the flows you did not know existed. The category model and the ordered evaluation give you the structure to do this safely, but structure does not substitute for knowing the traffic.
The path that works is the one the micro-segmentation methodology lays out: discover the flows, build allow rules from what you actually observe, validate them in a monitoring posture, and only then tighten the default. Default-deny is the destination you arrive at after you have earned the visibility, not the switch you throw on day one. Along the way, the discipline that prevents most self-inflicted outages is precise applied-to scoping and deliberate rule ordering within categories, so a rule lands exactly where you intend and is evaluated in the order you expect. Get there gradually and default-deny is a milestone you celebrate; get there in one reckless step and it is an incident you explain.
Section design keeps a large rule base readable
As the distributed firewall grows, the thing that keeps it operable is not cleverness in individual rules but structure across them. Organizing rules into clear policy sections, per application, per zone, per purpose, is what lets a human still reason about a rule base that has grown to thousands of entries. A flat list of rules with no sectioning is unauditable the moment it gets large, while a well-sectioned table reads like a document with chapters, where you can find the rules that govern a given application without scrolling through everything else.
Good section structure also makes applied-to scoping and change review tractable, because a section carries intent that an individual rule cannot. When you add a new application, it gets its own section in the application category, with its rules scoped to its workloads, and the rest of the table is untouched and unaffected. Curate the sections as deliberately as the rules, and the firewall stays something a new team member can read and a security auditor can follow, rather than a sprawling artifact that only its original author could ever explain.
References
- NSX Distributed Firewall (Broadcom TechDocs, NSX 9.0)
- NSX 9 Licensing and Editions: the vDefend trap (NSX Series, Part 3)
- NSX 9 Segments and Logical Switching (NSX Series, Part 8)
About The Author
