Palo Alto policy-deny though Action allow

I came across some strange behaviors on a Palo Alto Networks firewall: Certain TLS connections with TLS inspection enabled did not work. Looking at the traffic log the connections revealed an Action of “allow” but of Type “deny” with Session End Reason of “policy-deny”. What?

Long story short: This seems to be the way Palo Alto handles certificate issues such as “certificate unknown” due to certificate pinning within a third party application.

During troubleshooting I found the following facts. (Capturing on a Palo Alto Networks firewall PA-5050 with PAN-OS 7.1.14.) Running a custom Java application the connections aborted while the traffic log on the Palo showed the following. Note the “deny” Type while “allow” Action:

Using the packet capture feature on the Palo Alto itself on the “receiving” stage we could verify that the application sent an “Alert Level: Fatal, Certificate Unknown”, followed by a FIN, ACK:

Interestingly, using the packet capture on the “firewall” stage revealed an additional RST, ACK packet from the original source to the internal client. But since we did not see this packet on the receiving stage it was inserted by the Palo Alto:

With these captures in mind one of my colleagues told me that he has already seen this behaviour in some other cases that were all related to certificate pinning issues. That is: the custom application does recognize any TLS Man-in-the-Middle attacks since it does only allow connections to its pinned server certificate. But since we used TLS inspection at this firewall, the certificate was unknown to the application which terminated the session. Of course I am not happy with the traffic log on the Palo which did not clearly reveal for what reason it “policy-denied” the session!

Later on I searched on my Palo Alto lab unit for sessions with ( subtype neq end ) and ( action eq allow ), i.e., denied connections that have an action of allow as well. Indeed I found some with “session end reason” of either “decrypt-unsupport-param” or “decrypt-error“. Well, this at least gives some information about the root cause rather than a simple “policy-deny”:

Featured image ““The question is not what you look at, but what you see.” – Henry David Thoreau” by Sam Antonio Photography is licensed under CC BY-NC-ND 2.0.

2 thoughts on “Palo Alto policy-deny though Action allow

  1. Hi

    I think this also applies to FortiGate devices.
    I think I read about this in fortigate flags, “may_dirty” and “dirty” sessions.

Leave a Reply

Your email address will not be published. Required fields are marked *