Identify Policy Deny Source

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Identify Policy Deny Source

L1 Bithead

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:

policy deny.PNG

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.

1 accepted solution

Accepted Solutions

L7 Applicator

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-...

View solution in original post

2 REPLIES 2

L7 Applicator

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-...

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

  • 1 accepted solution
  • 3502 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!