l think l am missing something fundamental. l have a policy with "allow" action, but in the traffic logs session end reason is "policy-deny" :
Despite all this, l am still able to access the server:
Solved! Go to Solution.
According to this new feature guide, since PAN-OS 6.1 the "policy-deny" reason, is because the session matched a security policy with a deny or drop action.
In other words, the app-id or port being hit, does not match an explicity policy; hence, it is most likely hitting the interzone-default policy.
By the way, the interzone-default policy (at the bottom of the rule base) is not logged by default; however, you can override this configuration.
Default Interzone Policy:
Default Interzone Read-only: Default Interzone default action:
Override Default Interzone-Policy
Note: Click the Override button at the bottom of the screen
Change Default Interzone default action:
The reason I want to log the session at the start is because the action is "Deny" or "Drop", and I don't care about having the full session view in this case. In other words, as soon as the traffic is denied, a log is generated right away and not only at the end of the session. I hope it makes sense.
Now to your original question, my point is that the policy-deny reason you are seeing is because the app-id or port is not explicitly placed in an allow policy; hence, it will hit the default deny (Interzone) policy, which is not logged by default, as I stated before.
I hope this helps.
If you can answer these questions with yes
--> Read my last post in this topic: https://live.paloaltonetworks.com/t5/General-Topics/Action-and-Session-End-Reason-conflict-when-SSL-...
(It is at least very likely that you see the same "issue")
@Willian if the traffic was hitting their interzone-default, wouldn't the log reflect that? It would appear that it is hitting a security rule that they've set up with the name "OUT".
I think @vsys_remo may be correct in that it is related to the decryption.
I've also seen in my testing where SSL is decrypted into "web-browsing" and is then denied because it is going across 443 instead of 80 if the rule was set to application-default. While I'm not suggesting that is happening here (it looks like it is still showing it as SSL traffic), decryptiong seems to add some potential complexity to the security policy design.
There is a lengthy on-going discussion on how to properly address the 'web-browsing' issue when using SSL decryption. As of Ignite17 to recommended soution is still to enable a browsing rule with web-browsing using a specified tcp-443/80 service instead of application-default.
Thanks for all your input.
@vsys_remo yes 8.0.3 and yes exactly the same issue as yours (initially I thought l missed some fundamentals :D)
Kudos for all replies!!
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 Live Community as a whole!
The Live Community thanks you for your participation!