NSX: distributed firewall basics

The VMware NSX Distributed Firewall (DFW) provides micro-segmentation capabilities by enforcing security policies at the vNIC level of virtual machines.…

The VMware NSX Distributed Firewall (DFW) provides micro-segmentation capabilities by enforcing security policies at the vNIC level of virtual machines. Unlike traditional perimeter firewalls, the DFW is embedded in the hypervisor kernel, enabling granular traffic inspection and control between workloads within the same logical network, or even on the same host, without traffic hair-pinning through a physical appliance.

This article details the fundamental components and steps for configuring basic DFW policies within NSX-T Data Center (versions 3.x to 4.x), focusing on common use cases and best practices for network segmentation.

DFW Architecture and Policy Enforcement

The NSX DFW operates as a stateful firewall directly within the ESXi kernel via the NSX Virtual Switch (N-VDS or VDS 7.0+). Each vNIC of a virtual machine is associated with a DFW instance. When a VM attempts to send or receive traffic, the DFW rules are evaluated at the earliest possible point (ingress/egress from the vNIC) before traffic leaves or enters the hypervisor. This architecture allows for:

Granular Control: Policies can be applied down to individual VM vNICs.
Performance: Rules are enforced in the kernel, minimizing latency.
Scalability: DFW scales with your compute infrastructure; as more hosts/VMs are added, DFW capacity increases.
Zero Trust: Enables a "deny by default" security posture between workloads.

DFW policies are organized hierarchically in NSX Manager, processed from top to bottom. The standard order of processing is Gateway Firewall (if enabled for traffic traversing NSX Gateways), then DFW rules, then Endpoint Protection (Guest Introspection) if configured.

Core DFW Components

Understanding these components is crucial for effective DFW configuration:

Security Policies and Sections

A security policy is a container for a set of DFW rules that share a common purpose. Policies are organized into sections within the DFW configuration. NSX DFW uses a "section-based" rule hierarchy, where sections are processed sequentially. Within each section, rules are also processed sequentially.

Ethernet Sections: Processed first, apply to L2 traffic. Less commonly used for general DFW.
Emergency Section: Highest priority, processed before all others. Reserved for critical "break glass" rules.
Infra Section: For infrastructure services like DNS, NTP, Active Directory. Higher priority than Application sections.
Environment Section: Often used for environment-specific rules (e.g., development, staging).
Application Section: Default section type for application-specific rules. Most granular policies reside here.
Shared with Edge Section: For rules that need to be enforced on both DFW and NSX Edge Gateway Firewall.
Default Rule: The implicit "deny all" rule at the very bottom of the DFW policy, unless explicitly overridden.

Groups (Sources and Destinations)

Groups are dynamic or static collections of objects used as sources or destinations in DFW rules. Using groups simplifies rule management and makes policies more scalable and readable.

VMs, vNICs, Logical Ports: Specific NSX inventory objects.
IP Addresses/Subnets: CIDR blocks (e.g., 10.0.0.0/24).
MAC Addresses: Less common for DFW.
Security Tags: Most powerful method for dynamic grouping. VMs are tagged, and rules reference these tags. As VMs acquire/lose tags, they dynamically enter/exit groups.
NSGroup (Security Group): A primary object for grouping. Can contain static members (VMs, IP sets) or dynamic members based on criteria (e.g., VM Name contains "web", OS type is "Windows", Security Tag equals "App-Web").

Services

Services define the protocols and ports allowed or denied. NSX includes a library of common services (e.g., HTTP, HTTPS, SSH). Custom services can be created for specific applications or port ranges.

TCP/UDP Ports: Single ports (80), ranges (8000-8009), or lists (22, 3389).
ICMP: ICMP types and codes.
IP Protocols: E.g., ESP (50), AH (51).

Configuring a Basic DFW Policy: Web Application Segmentation

Let's walk through a common scenario: segmenting a 3-tier web application (Web, App, DB tiers) using security tags. We'll ensure only the Web tier can talk to the App tier on specific ports, and only the App tier can talk to the DB tier.

Step 1: Define Security Tags

First, we create security tags to logically identify our application tiers. These tags will be applied to the respective VMs.


NSX Manager UI:
1. Navigate to Inventory > Tags.
2. Click "ADD TAG".
3. Create tags:
   - Scope: "App-Tier", Tag: "Web"
   - Scope: "App-Tier", Tag: "App"
   - Scope: "App-Tier", Tag: "DB"
4. Apply these tags to your virtual machines. For example, attach "App-Tier:Web" to all web servers.
   (Inventory > Virtual Machines > Select VM > Actions > Add/Edit Tags)

Step 2: Create NSGroups (Security Groups)

Next, we create NSGroups that dynamically include VMs based on the security tags. This ensures that as VMs are added or removed, or their tags change, the groups automatically update.


NSX Manager UI:
1. Navigate to Inventory > Groups.
2. Click "ADD GROUP".
3. For each tier:
   - Name: "SG-Web-Tier"
     - Membership Criteria: "VM Tag Equals 'App-Tier : Web'"
   - Name: "SG-App-Tier"
     - Membership Criteria: "VM Tag Equals 'App-Tier : App'"
   - Name: "SG-DB-Tier"
     - Membership Criteria: "VM Tag Equals 'App-Tier : DB'"
   - Name: "SG-Management-Jumpboxes" (assuming a jump box group exists)
     - Membership Criteria: "VM Tag Equals 'Mgmt : Jumpbox'"

You can verify group membership by selecting a group and checking the "Members" tab.

Step 3: Define Custom Services (if needed)

If your application uses non-standard ports, define custom services. For this example, let's assume standard ports.

HTTP/S: Built-in service.
App-to-DB: Let's assume TCP 1433 for SQL Server.
SSH: Built-in service for management.


NSX Manager UI:
1. Navigate to Inventory > Services.
2. Click "ADD SERVICE" > "Add Custom Service".
3. Name: "SQL-1433", Protocol: "TCP", Destination Ports: "1433".

Step 4: Create DFW Sections and Rules

Now, we'll build the DFW policy. The order of sections and rules is critical.


NSX Manager UI:
1. Navigate to Security > Distributed Firewall.
2. Ensure you are on the "Category Specific Rules" tab.
3. Click "ADD SECTION" and select "Add Section Above/Below" to create sections in a logical order.
   - For management traffic, create an "Infra" section.
   - For application traffic, create an "Application" section.

// Example Policy Structure
//
// Section: Infra_Management
// --------------------------------------------------------------------------------------------------------------------------------------
// | Rule Name        | Source                      | Destination              | Services          | Action | Applied To             |
// |------------------|-----------------------------|--------------------------|-------------------|--------|------------------------|
// | Allow SSH to all | SG-Management-Jumpboxes     | Any                      | SSH               | ALLOW  | SG-Web-Tier, SG-App-Tier, SG-DB-Tier |
// | Allow DNS        | Any                         | NSGroup_DNS_Servers_IP   | DNS               | ALLOW  | Any                    |
// --------------------------------------------------------------------------------------------------------------------------------------
//
// Section: App_Web_Tier
// --------------------------------------------------------------------------------------------------------------------------------------
// | Rule Name        | Source                      | Destination              | Services          | Action | Applied To             |
// |------------------|-----------------------------|--------------------------|-------------------|--------|------------------------|
// | Allow HTTP/S     | Any                         | SG-Web-Tier              | HTTP, HTTPS       | ALLOW  | SG-Web-Tier            |
// | Web to App       | SG-Web-Tier                 | SG-App-Tier              | HTTP, HTTPS       | ALLOW  | SG-Web-Tier, SG-App-Tier |
// --------------------------------------------------------------------------------------------------------------------------------------
//
// Section: App_App_Tier
// --------------------------------------------------------------------------------------------------------------------------------------
// | Rule Name        | Source                      | Destination              | Services          | Action | Applied To             |
// |------------------|-----------------------------|--------------------------|-------------------|--------|------------------------|
// | App to DB        | SG-App-Tier                 | SG-DB-Tier               | SQL-1433          | ALLOW  | SG-App-Tier, SG-DB-Tier |
// --------------------------------------------------------------------------------------------------------------------------------------
//
// Implicit Deny at the end of the DFW policy.

Detailed Steps for creating rules:

Click "ADD POLICY" or "ADD RULE" within an existing policy.
Rule 1 (Management - SSH):
- Name: Allow SSH to All Tiers
- Source: SG-Management-Jumpboxes
- Destination: Any
- Services: SSH (built-in)
- Action: ALLOW
- Applied To: SG-Web-Tier, SG-App-Tier, SG-DB-Tier (this scope optimizes rule distribution)
Rule 2 (Web Tier - Ingress):
- Name: Allow Ingress to Web Tier
- Source: Any
- Destination: SG-Web-Tier
- Services: HTTP, HTTPS (built-in)
- Action: ALLOW
- Applied To: SG-Web-Tier
Rule 3 (Web to App):
- Name: Web to App Tier Communication
- Source: SG-Web-Tier
- Destination: SG-App-Tier
- Services: HTTP, HTTPS (or specific application ports)
- Action: ALLOW
- Applied To: SG-Web-Tier, SG-App-Tier
Rule 4 (App to DB):
- Name: App to DB Tier Communication
- Source: SG-App-Tier
- Destination: SG-DB-Tier
- Services: SQL-1433 (custom service created earlier)
- Action: ALLOW
- Applied To: SG-App-Tier, SG-DB-Tier

Step 5: Publish the Configuration

After defining your sections and rules, they are in a draft state. You must publish them for enforcement.


NSX Manager UI:
1. On the Distributed Firewall page, locate the "PUBLISH" button (top right).
2. Click "PUBLISH".

The NSX Manager pushes these rules to the NSX Policy Service, which then compiles them and distributes them to the NSX Enforcement Points (ESXi hosts). Rule deployment typically takes seconds to a few minutes, depending on the scale of the environment.

"Applied To" Field Optimization

The "Applied To" field is a critical optimization parameter for DFW rules. Instead of applying every rule to every VM, "Applied To" restricts the enforcement scope of a rule to specific VMs or groups. This reduces the number of rules pushed to each hypervisor and vNIC, improving performance and troubleshooting. For instance, in the "Web to App Tier Communication" rule, applying it only to SG-Web-Tier and SG-App-Tier ensures that only VMs within these groups have this rule enforced on their vNICs, preventing unnecessary rule processing for other VMs.

Common Pitfalls and Troubleshooting

Rule Order: DFW rules are processed top-down. A broad ALLOW rule higher up can inadvertently permit traffic that a more specific DENY rule lower down is intended to block. Always arrange rules from most specific to most general.
Implicit Deny: Remember the implicit "deny all" rule at the very end of the DFW policy. If traffic isn't explicitly allowed by an earlier rule, it will be dropped.
"Applied To" Misconfiguration: If rules aren't being enforced as expected, check if the "Applied To" scope correctly includes the intended source and destination VMs. An incorrectly scoped rule might not be pushed to the relevant hypervisor.
Security Tags Not Applied: Verify that your VMs have the correct security tags assigned. Dynamic groups rely entirely on accurate tagging.
IP Address Changes: If using IP sets instead of dynamic groups, ensure they are up-to-date. Using dynamic groups with security tags is generally preferred for VM workloads.
NSX Alarms and Events: Check the NSX Manager for DFW-related alarms (e.g., rule deployment failures) or events to identify issues.
Traceflow Tool: Use the NSX-T Traceflow utility (Networking > Plan & Troubleshoot > Traceflow) to simulate packet flow and identify exactly where traffic is being dropped by DFW rules. This is an invaluable tool for DFW troubleshooting.
Distributed Firewall Exclusion List: VMs on this list bypass DFW entirely. Ensure critical infrastructure VMs (e.g., vCenter, NSX Managers) are on this list to prevent accidental lockout, but be aware of the security implications. (Security > Distributed Firewall > Exclusion List)