Security Policy action is "allow", but session end reason is "policy-deny"

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

Security Policy action is "allow", but session end reason is "policy-deny"

L6 Presenter

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:



1 accepted solution

Accepted Solutions


  • Are you on 8.0.x or 7.1.x?
  • Do you see these specific logs only with decrypted sessions?

If you can answer these questions with yes

--> Read my last post in this topic:

(It is at least very likely that you see the same "issue")

View solution in original post


Hi @TranceforLife

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:Interzone-default-nooverride.PNG

 Default Interzone Read-only:Interzone-default-nooverride-readonly.PNG Default Interzone default action:Interzone-default-nooverride1.PNG


 Override Default Interzone-PolicyInterzone-default-nooverride.PNG

 Note: Click the Override button at the bottom of the screen




Change Default Interzone default action:Interzone-default-override-write1.PNG


 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.






















  • Are you on 8.0.x or 7.1.x?
  • Do you see these specific logs only with decrypted sessions?

If you can answer these questions with yes

--> Read my last post in this topic:

(It is at least very likely that you see the same "issue")

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

I have just upfated the other post with the newest TAC reply ... but as this seems to me still like the same issue :
"The issue is due to a current limitation in identifying session end reasons with SSL code values, which is expected to be fixed in the upcoming maintenance releases (ETA unknown). As of now, the session-end-reason is working as designed and uses the generic "policy-deny" for certain failure condition."


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.



L6 Presenter

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

L3 Networker

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.

  • 1 accepted solution
  • 7 replies
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!