Troubleshooting NSX Identity based Firewall from Global Protect

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.

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.

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.

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

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

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

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 3.2.0.1.0.19232400. Fortunately, my setup did work and I’ll show you how to double check that.

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.

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

As you can see the IP-addresses 172.16.255.17 and 172.16.255.18 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 3.2.0.1 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 3.2.0.1. So, I have upgraded the lab to version 3.2.1.1 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 4.0.0.1 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.