NSX - IDFW & DFW Troubleshooting

Introduction

Today, I would like to keep it brief and share a quick tip for all Identity (distributed) firewall administrators. I’m sure everyone has been in this situation: you’ve written a nice new Identity firewall, but for some reason it doesn’t work. If it were a normal firewall rule in NSX, I would first check the Traceflow Tool, but unfortunately that doesn’t work with the Identity firewall.

What is the Identity Firewall?

An identity firewall does not make firewall decisions based on IP addresses, but uses user and group information to apply security policies. It identifies users based on their login credentials and dynamically assigns them appropriate access rights and firewall rules. This enables more granular control and improved protection, as access permissions are directly linked to the actual identity of the user. If you want to know how I used this for one of my customers, you can read about it here.

How do I now fix my firewall rule?

There may be several reasons why my Identity Firewall is not working. Here is a list of some of them:

• Group memberships in AD have been changed or new users have been created.

  This is one of the simplest cases. The default Delta Sync with AD is 180 minutes, and in larger environments, this sync interval may be higher for performance reasons. There are two solutions here: either wait or force a Delta Sync under System - Identity Firewall AD.

• The Identity Firewall is turned off.

  This may sound a bit silly, but it has actually happened to me. You can create Identity Firewall Rules and groups, push the policy, and then find that the rules do not work. You don’t get an error message or notification. If this is the case, the Identity Firewall may not be allowed for the cluster on which the source VMs are located. To do this, go to Security - Distributed Firewall and under Settings, you can enable or disable the Identity Firewall for each cluster.

• Guest Introspection not installed

  If you want to use Guest Introspection, i.e. the version with VMware Tools, then these must also be installed on the source VM. The standard VMware Tools installation does not install these. Either install VMware Tools full or select Guest Introspection explicitly. The source of the error is of course eliminated if you do log scraping (which I personally do not prefer).

What should you do if you want to know whether rules have actually been implemented for a VM?

As mentioned at the beginning, unfortunately you cannot use the Traceflow tool to check a firewall rule. However, there are ways to see if there are Identity Firewall user sessions and which rules have been implemented.

The easiest way to check the sessions is in the GUI under Security - Security Overview and then scroll all the way down to Identity Firewall User Sessions. The VM is not displayed in plain text, but Universal Search in NSX resolves the VM.

The other option is to view it via the CLI.

CLI - Find the rules!

To find out which firewall rules are actually implemented on a VM, we first need to log in to the ESX server on which the VM is currently running. First, we use a simple CLI command to find the network card of our VM.

summarize-dvfilter | grep -A16 WinClientA0001

The result should look like this:

[root@esxnuc03:~] summarize-dvfilter | grep -A16 WinClientA0001
world 1085633 vmm0:WinClientA0001 vcUuid:'50 27 d1 31 1f 89 df b1-65 58 00 d0 ab 64 1f 91'
 port 67108888 WinClientA0001.eth0
  vNic slot 2
   name: nic-1085633-eth0-vmware-sfw.2
   agentName: vmware-sfw
   state: IOChain Attached
   vmState: Attached
   failurePolicy: failClosed
   serviceVMID: 1
   filter source: Dynamic Filter Creation
   moduleName: nsxt-vsip-24765085
[root@esxnuc03:~] 

The name of the NIC is important for our next step. In my example, it is nic-1085633-eth0-vmware-sfw.2.

Next, let’s display all realized rules for the VM:

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

[root@esxnuc03:~] vsipioctl getrules -f nic-1085633-eth0-vmware-sfw.2
ruleset mainrs {
  # generation number: 0
  # realization time : 2025-06-23T18:55:56
  # FILTER (APP Category) rules
  rule 16360 at 1 inout protocol any from any to any with extended src ba9e01bc-5779-4eb2-813e-4c5b8e3ff1bf drop;
  rule 14312 at 2 inout protocol icmp from any to addrset a34212cb-acb2-49b3-b74c-7683c0345a19 accept;
  rule 14312 at 3 inout protocol ipv6-icmp from any to addrset a34212cb-acb2-49b3-b74c-7683c0345a19 accept;
  rule 14316 at 4 inout protocol any from addrset a34212cb-acb2-49b3-b74c-7683c0345a19 to any drop with log tag 'alpine-drop';
  rule 2 at 5 inout protocol any from any to any accept with log tag 'debug';
}

ruleset mainrs_L2 {
  # generation number: 0
  # realization time : 2025-06-23T18:55:56
  # FILTER rules
  rule 1 at 1 inout ethertype any stateless from any to any accept;
}

We can see in the output that firewall rule 16360 has been implemented on my test VM and is therefore active. This firewall rule is my identity firewall rule, and a user who is enabled for this rule is logged in.

We can also see that the VM has implemented two additional rules, namely 14312 and 14316. Although these rules have nothing to do with the VM, the VM is still assigned these rules because the Apply to field is set to dfw, meaning that all VMs receive these rules. I have described the importance of the Apply to field here.

Theoretically, you can also see this in the GUI, but with a delay, and in my experience it was more unreliable than reliable. Nevertheless, I want to show it. If you look at the firewall rule and then go to the group and look at the effective members, a VM should be implemented. As I said, the GUI is very slow here, and if I have problems with the IDFW, I prefer to rely on the CLI.

This method allows you to quickly check whether an IDFW / DFW rule has been realized on the VM. If, as in the example above, the IDFW is disabled for the cluster, I can see the FW rule in the GUI, but it is not displayed in the CLI. The same would be the case if I had an error with the apply to field. The rule would not be realized on my VM and also not shown in the cli.

Summary

Troubleshooting the IDFW can sometimes be a little difficult, but it’s not impossible. I hope this quick practical tip helps you. It has often helped me when the GUI has tricked me. In combination with the check mechanisms in the GUI (even if these are sometimes slow) and the logging the IDFW / DFW is easy to troubleshoot.