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 (172.16.10.10) 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.