Action of allow but of Type policy deny

[chens]

Hi

panos 11.2:

I am using SSL Inspection for all inbound traffic on my web sites.

Certain TLS connections with TLS inspection enabled did not work. Looking at the traffic log the connections shows an Action of “allow” but of Type “deny” with Session End Reason of “policy-deny”.

No decryption logs issues (even the log flag for decryption profile is enabled for both Start and End sessions.

Policy is quite strict (allow incoming ssl and web-browsing. ports 443 and 80)

I can't find the "policy-deny" root.

Tracing the packets shows no issue with decryption as well.

[TomYoung]

Hi @chens ,

I always liked that when the session end reason was 'threat' that you could see the threat log in the Detailed Log View.  I don't know why PANW does not do that with the session end reason of 'policy-deny'.  It would be so efficient for the NGFW to show the corresponding policy log.

@Remo opened a TAC case on this years ago and TAC said it is always a decryption issue.  https://live.paloaltonetworks.com/t5/general-topics/identify-policy-deny-source/td-p/208306

With that said, you can grab the session ID from the Detailed Log View and use the filter ( sessionid eq '82516' ) under the Decryption logs to confirm there is no decryption log for the session.

The only other issue that I know that does not show up in the decryption log is this one -> https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000kI0RCAU.  You could test by running the CLI command.  If you do not want to make changes to a production NGFW, you could try creating a packet filter to match the session and running the CLI command 'show counter global filter packet-filter yes | match incomplete'.

That's all I got.  To repeat, PANW really should have the Detailed Log View show the corresponding log just like they do with threat.

Thanks,

Tom

[chens]

Hi @TomYoung 

This is quite a concerning situation, isn't it?

We are currently seeing a denial of nearly 50% of the traffic, and we still have no clear indication of the root cause.

I attempted to run the CLI command related to the SSL incomplete issue, but unfortunately, the problem persists. I have not observed the expected SSL incomplete counter anyway.

As for the TAC response from 2018, they mentioned that these are internal SSL messages and assured that a fix would be provided soon.

Looking forward to your insights or any updates on this.

[TomYoung]

Hi @chens ,

Have you opened a TAC case?  I don't have any more insights or updates.

Thanks,

Tom

[chens]

yes, 3 days ago.

They are not answering.

I start to think of offloading SSL using 3rd party device

[TomYoung]

Hi @chens ,

I don't work for PANW.  I create all my TAC cases in the CSP, and I always get an answer.  SSL decryption on my NGFWs works fine.

This community is primarily users that just want to help each other.  I've done what I can.

Good luck with your issue,

Tom

[D.Tamburin]

Having this exact same issue.  Came here to do research before opening a case.  I will open a case and if it gets resolved post here.

Davidt

[chens]

Hi

I have opened a ticket 4 days ago. I dont know what happened but they are just answering: plz wait for engineer. I am waiting 4 days!!

99% its a bug in pan-os.

I dont know if its just false alarms, because we do not see clients or application errors.

Or maybe the tcp stack try resend automtically and thats the reason this issue is transparent for clients.

Anyway, i have decided for the meanwhile to offload ssl with nginx and then forward plain to pan-os.

I am quite sure its pan-os bug.

[D.Tamburin]

Found this...

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000kI0RCAU

[chens]

Hi @D.Tamburin 

Thanks, but i already tryied that.

It's not relevant since the KB refers to other issues (that reflects the same error)

Anyway, if very old and mitigated after 8.x...

[Raido_Rattameister]

Take destination IP of failed session.

Check URL logs to understand what site is being accessed.

It is either strict decryption profile (allows only crypto parameters that client/server are not capable of), pinned certificate or missing CA in client.

If decryption logs say "Received fatal alert UnknownCA from client. CA Issuer URL:..." then either your clients don't trust Palo CA certificate or application inside client has pinned cert.

In case of pinned cert you either pass this traffic through firewall without decryption or block it. No third option.

[chens]

Hi

Thanks for answer.

As i mentioned in the begining, we are dealing here with inbound ssl inspection. Not forwarding.

I am using simple digicert trusted certificate. The palo also holds all the intermediate certs of the CA.

Same issue happens even with self signed by the palo itself.

P.s

All certificates of course installed on backend nginx servers.

Policy deny with no explain or error.

Nothing.

[Raido_Rattameister]

Do you have decryption profile attached to the inbound ssl decryption policy?

What algorithms you permit in decyption profile (Objects > Decryption > Decryption Profile / SSL Decryption > SSL Protocol Settings tab).

Add "Session ID" column into your traffic log view.

Copy session that has issues from traffic log (it looks like "( sessionid eq '3473517' )") and paste it into decryption log.

Do you see any errors or unsupported ssl protocols for the failed session?

[Brandon_Wertz]

From all of the posts here I haven't seen anything where the traffic deny was identified.  The "allow" action was for the Layer 3/4, but somewhere in L5-7 the firewall took a block action and it WILL be logged.  Check the data filtering, URL, threat, decryption...et al logs, somewhere one of these logs will show the reason for your ultimate deny action.  

Like mentioned before it's possible/probable that it would be a decryption issue.  Also previously mentioned was a decryption profile.  You can look there.  What settings do you have enabled there?  Does the server have an encryption certificate using unsupported parameters?

https://docs.paloaltonetworks.com/compatibility-matrix/reference/supported-cipher-suites/cipher-suit...