- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
07-11-2017 09:12 AM
Hi All,
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:
07-11-2017 10:23 AM
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")
07-11-2017 10:01 AM
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.
07-11-2017 10:23 AM
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")
07-11-2017 10:37 AM
@acc6d0b3610eec313831f7900fdbd235 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 @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.
07-11-2017 10:53 AM
07-11-2017 12:17 PM
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.
07-11-2017 03:05 PM - edited 07-11-2017 03:05 PM
Hi All,
Thanks for all your input.
@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!!
07-25-2023 02:14 PM - edited 07-25-2023 02:19 PM
I just had to figure out an issue with an allow rule that was doing policy-deny. It turned out to be an Authentication Policy rule configured with Authentication Enforcement value "default-web-form".
I wasn't able to find this in the traffic logs, as we were logging at session end and I guess it didn't consider my sessions to have started. But it did show in the Session Browser. ICMP packets mentioned below did show up in traffic logs though! Very confusing.
More info to help future me and others:
PAN-OS 10.2.4-h2
The firewall does the default-web-form (redirect?) action by generating a packet out of thin air: UDP to port 4501, source being the server, destination being the client device, containing the URL to the Auth Portal in the packet data. My test clients were not listening on port 4501 so responded with ICMP port unreachable messages to the server. Very odd to see in packet captures. I suppose a client running GlobalProtect may be listening on port 4501?
BTW the URL that it sends ends with rule=2 (or some number) which refers to which Auth Policy rule is causing this. It is zero-indexed so rule=2 means rule 3 in the GUI.
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!