Palo Alto Networks NGFWs are quite specific and different compared to other firewall vendors. The first and biggest difference is App-ID, which you can learn more about in the following blog posts:
Troubleshooting with Palo Alto Networks NGFWs is also unique. To identify the root cause of an issue, you need to understand the packet flow sequence and know what happens at each stage. More details can be found here: Packet Flow. In this post, I won’t elaborate on packet flow; instead, I’ll provide practical examples of how to troubleshoot and explain my methodology.
You may encounter situations where someone claims the firewall is blocking something, yet nothing is visible under Monitor -> Traffic logs. Typically, a firewall admin might respond that the traffic isn’t reaching the firewall, suggesting the server or app team check their side. However, PANW NGFWs can block traffic without log recorded under Monitor tab. There are two main reasons why nothing appears in the logs.
By default, the firewall generates logs when a session ends (“Log at session end”). If a session is still ongoing, nothing will be recorded. “Log at Session Start” should be used only for troubleshooting purposes, as it generates a lot of log entries and can quickly fill up storage if used otherwise.
The second case is more complicated. If the firewall decides to drop packets at an early stage, called Session Setup or Slow Path, nothing will be recorded under Monitor. During the Slow Path stage, the firewall checks many things (refer to the mentioned KB above), leading to various reasons why PANW might block traffic.
To identify if the firewall is blocking something, my first step is to use the built-in packet capture. The second step is to use counters to determine the root cause.
Let’s elaborate with an example. Suppose I cannot ping Google DNS 8.8.8.8, and no logs appear under the Monitor -> Traffic section. To confirm the firewall is blocking the traffic, set up filters for the relevant traffic, then configure the capture stage. Details about packet capture stages can be found here: Packet Capture Guide.
Generate traffic, and if the firewall creates a pcap file, you know the firewall is blocking traffic.
This pcap file can be downloaded and opened with Wireshark.
Next, identify the root cause using global counters. The command show counter global filter delta yes severity drop allows viewing packets dropped since the last command issue.
Now, I see there’s a routing issue. The root cause is simple; for demonstration purposes, I just removed the default gateway. More information about using counters can be found here: Counter Usage.
My example is trivial, just to illustrate the methodology. Using this same methodology, you can troubleshoot much more complex scenarios. It’s useful not only for networking issues but also for firewall capabilities. For instance, when Zone Protection is blocking traffic, a log will be generated under Monitor -> Threats, but what specific Zone Protection capability is blocking the traffic? To find out, global counters are your friends.