The importance of NSX Distributed Firewall “Applied To” setting

By default, Distributed Firewall (DFW) rules configured on NSX Manager are applied to all vNICs of all VMs in the vCenter inventory. The only exclusion is for VM added to a specific Exclusion List (see my previous post for this topic: NSX Distributed Firewall Exclusion List)

The DFW configuration provides a section called “Applied To” that enable the Administrator to limit the scope of applicability of a specific rule, providing a so called Point of Enforcement. You can limit the scope of a rule filtering on all objects that NSX Manager recognize for DFW rules configuration (Clusters, Logical Switches etc.)

Leveraging “Applied To” is fundamental in at least two scenarios:

  1. Avoid processing of unnecessary rules on a vNIC in an environment with hundreds or thousand of configured rules;
  2. Provide the capability to manage Virtual Machines with the same IP Address (Multi Tenancy scenario), avoiding the application of wrong rules to objects.

I want to use a specific example to show “Applied To” in action.

I have a 3-Tier Application composed by the following Virtual Machines:

  • web-01a and web-02a, attached to a Logical Switch called Web_Tier_01;
  • app-01a attached to a Logical Switch called App_Tier_01;
  • db-01a attached to a Logical Switch called DB_Tier_01.

Note: Routing and Load Balancing services have been configured appropriately to publish the application but this configuration is out of scope for the purpose of this article.

To avoid unnecessary traffic flows, I create specific Micro-Segmentation rules to grant communication between Application Tiers (and also infra-tier) only on the needed Ports and Protocols.
I want to obtain the following configuration:

  • No communication between VMs attached to the Web-Tier_01 Logical Switch;
  • Only PING and https traffic allowed from any source to the Load Balancer IP Address ( and to all VMs attached to the App-Tier-01 Logical Switch;
  • Only PING and https (port 8443, Tomcat) from all the VMs attached to the Web-Tier-01 Logical Switch to all the VMs attached to the App-Tier-01 Logical Switch;
  • Only PING and TCP Port 3306 (MySQL) from all the VMs attached to the App-Tier-01 Logical Switch to all the VMs attached to the DB-Tier-01 Logical Switch.

The configuration of the NSX DFW is the following:

By default, “Distributed Firewall” is the value configured for the “Applied To” field. This means that all the configured rules will be applied to all the vNICs of all the VMs.
If we focus on the DataBase Virtual Machine, db-01a (attached to the DB-Tier-01 Logical Switch), you can see the unneeded rules (these rules have nothing to do with the DB machine) highlighted in red and the only needed rule highlighted in green. Let’s keep note of the IDs of unneeded rules: 1006, 1007, 1008.
Note: Using Logical Switches instead of the VM name (or the legacy way, the IP Address) enables you to have a dynamic environment, all the VMs you’ll attach to a specific Logical Switch will implicitly inherit the needed rules.

I want to leverage the NSX Command Line to show the different impact you may have leaving the default “Applied To” instead of (recommended) change “Applied To” to a specific scope.
I will look at the specific vNIC DFW configuration applied at ESXi Host level.

First step, I connect to NSX Manager to leverage the centralized CLI. The first command I run is “show cluster all” to obtain the list of all clusters under the related vCenter management:

The Web, App and DB Virtual Machines are hosted on my Compute Cluster named “Compute Cluster A”. To work on objects using the CLI I need to use their IDs, in this case domain-c33 is the ID of my Compute Cluster.
I run the command “show cluster domain-c33” to obtain the list of all the Hosts that are members of this Cluster:

I decide to look at the configuration of the Host esx-01a.corp.local, running the command “show host host-28“, where host-28 is the ID of my Host:

The output of the “show host” command is the list of all VMs hosted on this specific ESXi Host, with their ID. Our focus is on the DataBase machine, db-01a with ID vm-218.
I run the command “show dfw vm vm-218” to obtain the details of all the vNIC configured in this Virtual Machine. Details are vNIC Name, vNIC ID and Filters.

Filters output shows which filter is applied to the vNIC. In this case the VMware DFW in the Slot 2 of the IOChain. In this slot all the DFW rules are stored and enforced.
I use the obtained Filter to get the list of all rules applied to the only vNIC configured on db-01a.
The command I need to run is “show dfw host host-28 filter nic-39230-eth0-vmware-sfw.2“:

From the output of the command you can see that rules with ID 1006, 1007, 1008 are enforced on the db-01a vNIC.
These rules are not needed for the DB Server and only cause overhead in the overall processing of DFW rules.

To maximize the benefits of DFW, I leverage the “Applied To” section to apply only the needed rules to each specific vNIC.
To do this, I change the “Applied To” field to the value of the relevant objects, this is the outcome:

Web Tier Micro-Segmentation rule will only be applied to the vNICs of VMs attached to the Web-Tier-01 Logical Switch.
The Rule that govern traffic flows from any source to the Web Tier will only be applied to the vNICs of VMs attached to the Web-Tier-01 Logical Switch.
Rules that govern traffic flows from the Web Tier to the App Tier will only be applied to Web-Tier-01 and App-Tier-01 Logical Switches.
Rules that govern traffic flows from the App Tier to the DB Tier will only be applied to App-Tier-01 and DB-Tier-01 Logical Switches.

To check the rules enforced at the vNIC level to db-01a, I run the command “show dfw host host-28 filter nic-39230-eth0-vmware-sfw.2“:

Not needed rules are not applied to the DB Virtual Machine vCNIC, avoiding unnecessary overhead in the Firewall rules processing.
This shows one of the most important benefits of the “Applied To” section of the NSX Distributed Firewall.

NSX Distributed Firewall Exclusion List

Quick article on an important topic: don’t lock yourself out when enabling NSX Distributed Firewall.

When you prepare vSphere Clusters for NSX and the DFW kernel module is injected into the Host’s kernel, Distributed Firewall is automatically enabled on any vNIC with a default “allow any-any” rule.

By default, some VMs are excluded from DFW and traffic can flow freely on them:

  • NSX Manager;
  • NSX Controller Cluster;
  • Edge Service Gateways.

It is recommended to manually exclude some other service VMs:

  • vCenter Server;
  • SQL Server Database used by vCenter (if you’re using the Windows version of vCenter);
  • Partners Service Virtual Machines;
  • vCenter Web Server (if installed on a different VM than vCenter).

Following, the NSX 6.3 official documentation for the Exclusion List.

It may happen to forgot to add vCenter to the exclusion list and change the defaul DFW rule to “deny any-any”.
In this case, you will no more be able to reach your vCenter and manage it using the vSphere Web Client.

To regain access to the vCenter, you can use the following API call against the NSX Manager (remember, NSX Manager is automatically excluded from DFW so you can always call APIs against it!).
You can use your favorite REST Client to perform the operation with the following parameters:
Header: “Content-Type: application/xml”
Header: “Accept: application/xml”
Authentication: “Basic”
DELETE https://nsx_manager_ip/api/4.0/firewall/globalroot-0/config
The API call should return Status Code 204.

This call erase all DFW configuration and reset the default rule to “allow any-any”.
After you regain access to your vCenter, you can load the saved (or auto-saved) firewall configuration.

In the case you don’t have a saved NSX DFW configuration (not a best practice!) and you don’t want to lose your configured rules, my colleague Angel Villar Garea has elaborated a way to recover access to vCenter without resetting the overall configuration, creating a rescue rule. you can check his article here:

UPDATE August 11th, 2017:

With NSX 6.3.3, released on August 11th 2017, the previous DELETE API call to erase the entire Firewall configuration has been deprecated.

A new method has been introduced to get the default Firewall configuration.
Use the output of this method to replace the entire configuration or any of the default sections:

  • Get default configuration with GET api/4.0/firewall/globalroot-0/defaultconfig
  • Update entire configuration with PUT /api/4.0/firewall/globalroot-0/config
  • Update single section with PUT /4.0/firewall/globalroot0/config/layer2sections|layer3sections/{sectionId}