What is NSX-T DFW?

What is NSX-T DFW is an article that explains a little bit about the NSX-T Distributed Firewall and how rules are applied on Hosts Transport Nodes.

Security is a subject that needs careful attention for all administrators at all levels of business (from small to bigger companies). Cybercrime is more sophisticated and new malware is released every day. So, we need to improve our digital security to avoid or minimize risks related to it.

In this context, the DFW acronym for Distributed Firewall can help to protect the virtual workloads inside an NSX-T infrastructure. Each Host Transport Node has firewall modules and receives rules from the NSX Manager Cluster. So, because of it, this firewall is distributed (every Host Transport Node has firewall modules working based on firewall rules pushed by NSX Manager Cluster).

With the DFW we can filter the East-West traffic. In other words, we can filter the traffic between virtual machines (even VMs in the same subnet we can apply some filter).

DFW Architecture – Simple Overview

In the picture below, we can see the simple workflow from the user starting the interaction with the NSX Management Cluster (creating a firewall rule or editing an existent firewall rule, for example) and NSX Manager pushing these rules for all Hosts Transport Nodes:

In the Host Transport Node, there are a lot of modules that have interaction to achieve the security goals.
As we can see in the below picture, NSX Manager Custer sends (pushes) all configurations for the nsx-proxy module running in the Host Transport Node. This module (nsx-proxy) is responsible for communicating with every other module as necessary. The module “vmware-sfw” is responsible for maintaining the Connection and Rule tables:

Another important thing is that each firewall rule is enforced at the vNIC level, as we can see in the below picture. So, the firewall rules need to be made thinking on it:

DFW POLICY x RULE

Firstly, we need to talk about what is a firewall policy and what is a firewall rule.
It’s normal when we are talking about firewalls to hear both terms. Basically, firewall policy is a logic group of firewall rules. In a practical way, we need to create a firewall policy first and then we can create a lot of firewall rules.

The basic hierarchy is:

POLICY_01
——– RULE_01
——– RULE_02
——– RULE_03

POLICY_02
——– RULE_01
——– RULE_02
——– RULE_03

Each firewall can be one or several firewall rules. Each firewall rule can satisfy different goals. For example:

• Rule 01: Allow HTTP, HTTPS, and DNS traffic from the local network to the Internet;
• Rule 02: Allow HTTP and HTTPS traffic to the DMZ;
• Rule 03: Block all traffic from any to any.

DFW RULE CATEGORIES

By default, we have some firewall categories. Basically, the main aim of these categories is to organize the firewall rules.

The firewall categories are checked from LEFT to RIGHT and inside each category, the firewall rules are checked (lookup) from TOP to DOWN.

As we can see in the below picture, we have five default categories:
ETHERNET –> EMERGENCY –> INFRASTRUCTURE –> ENVIRONMENT –> APPLICATION

After selecting one category, we can see all firewall rules that we have inside this category.
As we said, all firewall rules inside the specific category are checked from TOP –> DOWN. If some rule matched, the rule lookup is finished:

In the below link we can see more details about firewall categories:
https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-6AB240DB-949C-4E95-A9A7-4AC6EF5E3036.html

Deeping Dive Into a Firewall Policy

Here we have an example of a firewall rule:

• Name = Firewall policy and rule name;
• ID = Each firewall rule has a unique identification;
• Sources = VMs, IPs, Subnets, as a source of the traffic;
• Destinations = VMs, IPs, Subnets, as a destination of the traffic;
• Services = Services or protocols (HTTP, HTTPS, DNS, etc);
• Context Profiles = Used by advanced filtering (such as L7 Filtering);
• Applied To = This field can be used to define the scope to which this rule should be applied. By default, DFW is the default scope. We can change it by specific groups for example to minimize the scope for rule lookup;
• Action = The action that will be taken with the traffic (Allow | Drop | Reject).

Below, we can see an example of the “Applied To” field in action.
The default option for the “Applied To” is DFW. When we use the “DFW” in the “Applied To” field, the firewall rule will be enforced on all vNICs of the VMs running in the ESXi host.

In this example, the firewall rule “App-PRD_to_DEVQA” blocks ICMP echo requests (ping) from App PRD VMs to App DEVQA VMs. So, in this case, changing the field “Applied To” from DFW and specifying the Groups will limit the lookup scope for the firewall rule analysis – In this case, the firewall lookup process only will happen in VMs inside these groups:

How Policy is Realized on vSphere Hosts?

We can access an ESXi host (Host Transport Node) by SSH and see all firewall rules applied on all vNIC interfaces:

summarize-dvfilter

In this example, we can see the DVFilter applied to the “app-01-prd” vNIC:

To see what firewall rules are applied at the vNIC level, we can run the below command:

vsipioctl getrules -f nic-3851537-eth0-vmware-sfw.2

Where:
— nic-3851537-eth0-vmware-sfw.2 = Is the name of the DVFilter applied to the VM “app-01-prd”

Look at the rules 3048 and 3049. In the field “addrset” we cannot see the value (we only see a code like a UUID). To get the value for these fields, we can use the below command:

vsipioctl getaddrsets -f nic-3851537-eth0-vmware-sfw.2

As we can see in the below picture, both addrset are composed of IPs and Mac Addresses:

Note: These commands can be executed on any ESXi host part of the NSX-T infrastructure!