Troubleshooting NSX Identity based Firewall from Global Protect

Submitted by Robin van Altena on Mon, 10/03/2022 - 07:13
Follow your favourite author

Leave us your email address and be the first to receive a notification when Robin posts a new blog.

Troubleshooting NSX Identity based Firewall from Global Protect
Mon 03 Oct, 2022
Ever since NSX-V it was possible to use the distributed firewall based on a user-id instead of a server or an IP-address. With NSX 3.2 the option became available to use Log Insight to filter external Firewall VPN access logs like Global-Protect and ClearPass. This sounds cool and is, if it works. But where do you start looking if it doesn’t work as planned? In this blog I will show some of the troubleshooting steps you can take to analyze your setup.

In the first part of this blog, I took you through the steps of configuring the Identity based firewall in NSX-T based on the Global Protect access logs. In this part I will show some of the troubleshooting you can do if something doesn’t go as planned.

Looking at global picture there are a few points we will have a closer look at.

Global overview of the setup

First, the logging in Log Insight, second the mapping information send to NSX and finally the firewall on the data plane. I am not going into the details of configuring Global Protect on the Palo Alto firewall. Forwarding the logging from the Palo Alto is shown in the first part of this blog.

You can go straight to the end by checking if the firewall rule works, but then you probably don’t need to read the rest of this blog.


Troubleshooting at Log Insight

Looking in Log Insight it should be relatively easy to see if the logs are being received from the Palo Alto. An important point is that it should be the USER-ID logs and not the Global Protect logs. Both logs contain relatively the same information, but in a different format. The Global Protect logs are in red and the User-ID logs in green.

Palo Alto logs in Log Insight

From both logs we can derive the user logging on and the assigned IP-address (172.16.255.x). But since both logs are in a different format, the documentation shows the following example, which is similar to the User-ID log.

Example in the NSX documentation

If you want to dig really deep you can check if Log Insight actually sends information towards the NSX Manager, by doing a packet capture. But for me that wasn’t necessary.


Troubleshooting at NSX Manager

On the NSX Manager you can check if the information from Log Insight is received. This can be done with the following API call:

GET https://<NSX Manager>/policy/api/v1/infra/settings/firewall/idfw/user-session-data

Active user session in NSX for IDFW

If the information from Log Insight has been processed correctly you should see an active user session. Or at least an archived user session, from previous connections.

There is also an option to go one step deeper by looking at the logging of the API call from Log Insight to NSX. This can be done on the NSX Manager by looking in the /var/log/proton/nsxapi.log

Here I started to look for ‘login’, but reduced the information by searching on ‘domainName’:

grep -I domainName= nsxapi.log

Logging from the API call from Log Insight to the NSX Manager

Now we know the information is received from Log Insight we can check for the connection between NSX and Active directory.

This can be done by checking the Synchronization Status under System > Identity Firewall AD > Synchronization Status

Synchronization status for an Active Directory connection

If all has been configured correctly, the IP-address of the users Global Protect connection should appear as IP-address in the Security group. Meaning the Security group where an Active Directory group has been added of which the user is a member. Unfortunately, this was not the case in my setup with NSX version Fortunately, my setup did work and I’ll show you how to double check that.

Empty group during IDFW setup in NSX

Verifying on the data plane

The last step is to check if the firewall rule has been programmed correctly on the data plane. We can do this on the ESXi host where the VM, that is receiving the firewall rule, is running. The relevant information can be seen in the following combined screenshot. We see firewall rule 4072, with a source group that contains an Active Directory group and a destination group that contains a VM.

Information regarding a firewall rule

With this information we can retrieve the firewall rule as it is programmed in the data plane. In the following combined screen shot I have run a few commands on the ESXi host where the roblabtest08 VM is running.

  1. summarize-dvfilter, to show the name of the filter for the network adapter of the VM
  2. vsipioctl getrules -f <filter name>, to list the rule applied to that filter
  3. vsipioctl getaddrsets -f <filter name> -a <address set>, to list the contents of the address sets for a specific filter
Distributed firewall information for a network card of a VM

As you can see the IP-addresses and are part of the address set and thus the security group. That is why my setup is working although it isn’t shown in the GUI of NSX for version Build 19232400. Let’s see if we can fix that.

Security Group GUI issue

Although the setup works it is annoying that the IP-address of the Global Protect User isn’t visible in the NSX Manager. My initial setup was with NSX version So, I have upgraded the lab to version Build 20115686. But with this version the Security Group also isn’t populated in the GUI. Which makes troubleshooting a bit more difficult.

I have not tried the first NSX release yet, but hopefully it will be available in future versions.

Hopefully, you have enjoyed reading this blog and please let me know if you can see the IP-address for the Users in the Security group in the NSX GUI. If you have any questions or would like to see some specific content, please leave your questions and remarks at the bottom.


Questions, Remarks & Comments

If you have any questions and need more clarification, we are more than happy to dig deeper. Any comments are also appreciated. You can either post it online or send it directly to the author, it’s your choice.
Let us know  

Questions, Remarks & Comments

Message Robin directly, in order to receive a quick response.

More about RedLogic