- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
03-30-2018 01:49 PM
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.
03-31-2018 05:12 AM
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-...
03-31-2018 05:12 AM
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-...
04-02-2018 07:42 AM
Alright, thank you for the response and information from your Support experience.
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!