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

[TranceforLife]

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:

[acc6d0b3610eec313831f7900fdbd235]

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.

https://www.paloaltonetworks.com/documentation/61/pan-os/newfeaturesguide/networking-features/sessio...

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.

[Remo · Accepted solution]

@TranceforLife

• 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: 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")

[jsalmans]

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

[Remo]

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

[BPry]

@jsalmans,

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.

[TranceforLife]

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

[AaronAxvig]

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.