Tools / Guides / NSX Firewall Builder
// Guide · Security

NSX Firewall Builder

Design east-west microsegmentation for your NSX environment. Define security groups (workload tags, IP sets), reusable service profiles, and DFW rules across the four NSX policy categories — then export a numbered, step-by-step guide for applying them via the NSX Manager UI.

NSX DFWAllow / Drop / RejectSource & Destination GroupsService ProfilesRule ValidationStep-by-step Export
Open the tool Jump to walkthrough

Quick start

  1. Define groups — workload groupings by tag, VM name, or IP set. E.g. web-servers, db-servers.
  2. Define service profiles — named port groups (e.g. HTTPS, SQL-Server, custom application ports).
  3. Add rules across the 4 categories — Infrastructure, Environment, Application, Emergency.
  4. Validate — the tool flags shadow rules, missing default policy, and ungrouped workloads.
  5. Export the deployment guide — numbered steps for the NSX Manager UI.
On this page

When to use this tool

Use this tool when you need to:

ℹ
This is for east-west (VM-to-VM) For north-south perimeter rules at your physical firewall, use the Firewall ACL Planner instead.

How it works

NSX DFW evaluates rules in category order from highest priority to lowest:

  1. Emergency — top of the policy. Quarantine rules, incident response.
  2. Infrastructure — foundational rules (allow ICMP, allow DNS to AD, allow vCenter→ESXi).
  3. Environment — zone-based separation (Prod ↔ Dev isolation).
  4. Application — per-app rules (web→app→db tiering).

Within each category, rules evaluate top-down with first-match. A default policy at the bottom (typically Application: deny-all) catches anything not explicitly permitted.

Rules reference groups (sets of VMs identified by tag, name, or IP) and service profiles (named port groups). Both should be reusable across rules.

Step-by-step walkthrough

1. Define security groups

Add groups by membership criteria:

2. Define service profiles

Add reusable port/protocol groups:

Naming matters — App-API communicates intent; TCP-8443 doesn't.

3. Add rules — Infrastructure category

Foundational rules every workload depends on:

4. Add rules — Environment category

Zone-based separation:

5. Add rules — Application category

Per-app microsegmentation. Classic 3-tier:

6. Add rules — Emergency category

Top-priority rules for incident response:

Usually empty during normal operations — populated reactively.

7. Validate

Validation panel checks: shadow rules, workloads not in any group, missing default-deny, unused service profiles.

8. Export deployment guide

Numbered, step-by-step guide for NSX Manager UI: log in → navigate to Security → create groups → create services → create rules per category → publish.

Examples

Example · 3-tier ecommerce app

Groups: ecom-web, ecom-app, ecom-db. Services: HTTPS, App-API, SQL.

Application category:
1. Permit  External-LB → ecom-web   HTTPS
2. Permit  ecom-web    → ecom-app   App-API
3. Permit  ecom-app    → ecom-db    SQL
4. Drop    Any → ecom-db   Any (log)
5. Drop    Any → Any       Any (log) — default deny
Example · Quarantine workflow

Group: Quarantined-VMs (members assigned via tag security=quarantine).

Emergency category:
1. Drop  Quarantined-VMs → Any   Any (log)
2. Drop  Any → Quarantined-VMs   Any (log)

To quarantine a compromised VM: tag it. NSX automatically isolates it.

Common mistakes

🚨
No default-deny at the bottom Without an explicit deny-all rule at the end of the Application category, NSX defaults to allow — defeating the entire microsegmentation. Always end with deny-all-with-logging.
⚠
Tagging not consistent Tag-based groups break if VMs aren't tagged consistently. Establish a tagging policy first, enforce via vCenter automation.
⚠
Drop vs Reject confusion Drop = silently discard. Reject = send TCP RST/ICMP unreachable. Generally use Drop for hostile sources, Reject for internal "should never happen" cases.
🚨
Excluding NSX Manager from DFW by mistake NSX Manager is normally on the Exclusion List. Don't add it to a group with deny rules — you'll lock yourself out.
⚠
Putting Application rules in Infrastructure Categories matter — Infrastructure rules apply before Environment and Application. Putting a deny in Infrastructure overrides anything below it. Use the right category for the rule's scope.

Tools that pair well with NSX Firewall Builder:

Firewall ACL Planner
Design north-south rules at your physical firewall.
NSX Segment & T1 Planner
Design the segments containing the workloads being microsegmented.
VCF Reference Architecture Builder
Plan the NSX edge cluster topology that hosts DFW.
VCF Day 2 Operations Planner
Apply DFW changes through guided runbook procedures.
IP Subnet Planner
Plan IP allocations referenced in DFW IP-set groups.

FAQ

Does this push rules directly to NSX?
No — generates a deployment guide and JSON spec. You apply manually via NSX Manager UI or by replaying the JSON via PowerCLI/API. Deliberate human-in-the-loop.
Can I export to PowerCLI directly?
The exported JSON is suitable for replay via PowerCLI cmdlets. Direct PowerCLI export is on the roadmap.
What if my workloads aren't tagged yet?
Two options: (1) tag them via vCenter PowerCLI/API in bulk, or (2) start with IP-set groups (CIDRs) and migrate to tag-based as workloads get tagged.
How do I roll back a bad rule?
NSX keeps policy versions. In NSX Manager, View Policy History → revert. Always test rule changes in non-prod NSX domain first.
Why categories instead of one big list?
Categories force logical structure. Without them, the policy becomes unmaintainable in 6 months. Categories also allow team-of-teams ownership.