topic Identify Policy Deny Source in General Topics

Identify Policy Deny Source

CastawayKid — Fri, 30 Mar 2018 20:49:38 GMT

I am seeing some decrypted sessions hitting an allow rule, but the session end reason gets logged as a "policy-deny". Here is a screenshot of one example:

In the above example, rule "outbound" is configured as:

Source Zone: MSUN

Source Address: Any

Destination Zone: Charter

Destination Address: Any

Application: Any

Service: Any

Action: Allow

Security Profile: Security Group 1

How do I go about finding the reason this traffic is getting denied? I've been told to check the URL Filtering log, but I'm not finding any matching logs for this session there.

Re: Identify Policy Deny Source

Remo — Sat, 31 Mar 2018 12:12:54 GMT

Hi @CastawayKid

In a normal situation the url filtering log would be a good start. Even better would be to use the unified log view in such a case, as it shows all logtypes in one view. This way you probably see the problem way earlier than searching through the diffetent logs independently.

The "issue" you are facing here is a little more complex, because there actually is no other log entry than the one in your screenshot. If you really want to know what happens you need to dig deeper: with packet captures to check what the client and server actually send and with a flow basic analysis so see what the firewall is doing with the server and/or client traffic.

But for exactly this situation I already created a TAC case a while ago and the reason simply is: there is a decryption problem happening here.

Because of some reason the firewall is not able to decrypt this session, so the traffic (action allow comes from the security policy) is denied by the decryption policy.

Regards,

Remo

PS: The actual answer from TAC I have posted here (the last post in this topic): https://live.paloaltonetworks.com/t5/General-Topics/Action-and-Session-End-Reason-conflict-when-SSL-decryption/m-p/163593#M52946

Re: Identify Policy Deny Source

CastawayKid — Mon, 02 Apr 2018 14:42:17 GMT

Alright, thank you for the response and information from your Support experience.