Dr. Pranay Jha

People conflate the two NSX firewalls constantly, and the confusion costs them, because the right control in the wrong place either does nothing or breaks something. The Distributed Firewall from Part 12 is an east-west tool: it lives at every vNIC and governs how workloads talk to each other inside the data center. The Gateway Firewall is a north-south tool: it lives at the gateway and governs traffic entering and leaving the network at the perimeter. Same word, firewall, very different jobs. This part draws the line clearly, because once you see where each one belongs, designing layered security stops being guesswork and becomes obvious.

DFW vs Gateway Firewall

The cleanest way to hold this is by direction and location. The DFW is distributed across every host and enforces at the virtual interface of each VM, so it sees and controls the lateral, east-west conversations between workloads, the traffic that never leaves the overlay. The Gateway Firewall is centralized on the Edge service router and enforces at the gateway, so it sees the north-south traffic crossing the boundary, the traffic going to or coming from the physical network and the world beyond it. The DFW asks “can these two VMs talk?” The GFW asks “can this traffic cross the perimeter?” Both are stateful by default, both use the same groups and services, but they hold separate, independent rule sets, and a packet can be evaluated by both as it travels.

Where to place the Gateway Firewall

Because the GFW is configured per gateway, where you put it shapes what it protects. A Tier-0 Gateway Firewall sits at the estate edge, governing what crosses between your entire NSX environment and the physical fabric, the place for broad, organization-wide ingress and egress policy. A Tier-1 Gateway Firewall sits at the perimeter of a tenant or application zone, governing what enters and leaves that specific slice, the place for per-tenant north-south rules. The two compose naturally: the Tier-0 GFW enforces the rules that apply to everyone leaving the estate, and each Tier-1 GFW enforces the rules that apply to its own tenant, so a tenant cannot loosen the estate-wide policy and the estate policy does not have to know every tenant’s specifics.

Stateful, active-standby, and licensing

The GFW inherits the same constraint as NAT from Part 11, for the same reason. A stateful Gateway Firewall tracks connection state, and that state cannot be shared across the multiple active forwarders of an active-active Tier-0, so a stateful GFW, along with Layer 7 application-ID rules, URL filtering, and TLS inspection, requires the gateway to be in active-standby. If your Tier-0 is active-active for ECMP throughput, you cannot bolt a stateful firewall into its path; you put the stateful perimeter on an active-standby Tier-1 instead, which is the same pattern I recommended for NAT. There is also a licensing line: the base VCF entitlement includes only the stateless gateway firewall, while the stateful GFW and the threat features are part of vDefend (Part 3). Plan both the HA mode and the license before you design perimeter rules.

Defense in depth: use both

The mistake is treating the GFW and DFW as alternatives, as if you pick one. You use both, deliberately, at different layers. The Gateway Firewall is your perimeter: a coarse, high-level control over what enters and leaves, the equivalent of the firewall at the edge of a traditional network. The Distributed Firewall is your interior: fine-grained micro-segmentation that assumes the perimeter can be breached and limits how far an attacker can move once inside. Perimeter security alone is the hard-shell, soft-center design that ransomware feasts on; micro-segmentation alone leaves the front door without a guard. Together they are defense in depth, and NSX is one of the few platforms where you can run both from a single policy model with the same groups underneath.

How a packet meets both firewalls

Tracing one north-south flow makes the relationship concrete. A VM on an overlay segment opens a connection to the internet. The packet first leaves the VM’s vNIC, where the Distributed Firewall evaluates it on egress, can these two endpoints talk at all? If allowed, it is routed through the Tier-1 and up to the Tier-0, and at the gateway the Gateway Firewall evaluates it again, is this allowed to cross the perimeter and leave the estate? Only if both say yes does the packet reach the fabric. The return traffic retraces the path, and because both firewalls are stateful, the reply is permitted automatically by each. So a single north-south packet is checked twice, by two independent policies, at two different layers, and that is exactly the point: a gap in one is covered by the other.

East-west traffic, by contrast, never reaches the Gateway Firewall at all, because it never crosses a gateway perimeter. Two VMs on the same Tier-1 talking to each other are governed entirely by the DFW. This is why the GFW is the wrong tool for internal segmentation: most of the traffic you want to micro-segment never passes through it. Understanding which firewall sees which traffic is the difference between a control that works and one that silently never engages.

Verifying and the mistakes that bite

Because the GFW lives on the service router, you verify it on the Edge node hosting that gateway. The same firewall context that processes NAT shows the gateway firewall rules and their hit counts, which is how you confirm a perimeter rule is actually being evaluated rather than bypassed.

# On the Edge node hosting the gateway's service router
get firewall                       # the gateway firewall context
get firewall <interface> ruleset rules   # rules on a specific uplink

# Zero hits on a rule you expect traffic to match usually means
# the traffic is east-west (never reaches the GFW) or the gateway
# HA mode does not support the stateful rule you configured.

What I’d Do

Use the Gateway Firewall for what it is good at, coarse north-south perimeter control, and the Distributed Firewall for what it is good at, fine-grained east-west micro-segmentation, and never ask either to do the other’s job. Put broad ingress and egress policy on the Tier-0 GFW, per-tenant perimeter on the Tier-1 GFW, and keep both stateful by leaning on active-standby gateways for anything that needs Layer 7 or TLS. Confirm the HA mode and the vDefend licensing before you write a single perimeter rule, because both are easy to design around and painful to discover late. Above all, run both firewalls: perimeter plus micro-segmentation is the layered posture that actually survives a breach. Next up is Part 15: Distributed IDS/IPS and malware prevention, where the security stack moves from allow-and-deny to detect-and-stop. Are you running both firewalls, or leaning on just one and calling it secure?

Gateway firewall is perimeter; the distributed firewall is lateral

It is worth being precise about what the gateway firewall is for, because conflating it with the distributed firewall leads to bad designs. The gateway firewall runs on the service router of a Tier-0 or Tier-1, on the Edge, and it filters north-south traffic, the flows entering and leaving through that gateway. It is stateful and it sits at the boundary. The distributed firewall, by contrast, runs in every hypervisor and filters east-west, the workload-to-workload traffic that never touches the Edge. They are complementary controls operating at different places in the path, and a good design uses each for what it is built to do.

The clearest way to hold it is this: the gateway firewall is your perimeter and your zone edges, the distributed firewall is your lateral, workload-level segmentation. North-south policy, the rules about what may enter or leave a zone, belongs on the gateway. East-west policy, the rules about which workloads may talk to which, belongs in the distributed firewall where it scales with your hosts. Keep that division clean and each control stays simple and fast; blur it and you end up enforcing workload-level rules at a perimeter that was never meant to carry them.

Putting everything on the gateway rebuilds the chokepoint you removed

The tempting mistake, especially for teams with a traditional firewall background, is to push all the policy onto the gateway because that is where firewalls have always lived. Do that and you quietly rebuild the exact centralized chokepoint that the distributed firewall exists to eliminate. Every workload-to-workload flow that should have been filtered in the hypervisor now has to hairpin out to the Edge to be inspected, which loads the Edge, adds latency, and reintroduces the single bottleneck that distributed enforcement was designed to remove. The architecture still looks like NSX, but it performs like the centralized firewall you were trying to leave behind.

The discipline is to resist the gravitational pull toward the perimeter. Use the gateway firewall for genuine north-south and zone-boundary policy, and put workload-to-workload rules where they belong, in the distributed firewall on the hosts. The reward is a design where east-west enforcement scales with compute and the Edge only carries the traffic that genuinely needs to cross a boundary. When you find yourself writing a gateway rule about two internal workloads talking to each other, stop and move it to the distributed firewall, because that rule is in the wrong place and it is making the Edge do work it should never see.

References

• Gateway Firewall (Broadcom TechDocs, NSX 9.0)
• Well-Architected Design: Gateway Firewalls Use Cases and Scope (VMware)
• NSX 9 Distributed Firewall Fundamentals (NSX Series, Part 12)

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts