Interzone default deny rule with logging is allowing traffic and shows up in traffic logs

[Akhil_B]

We have a PA-3220 which is running in 10.2.4 Pan OS, we observed something really weird in the traffic logs this morning which shows 'ms-rdp' connections allowing through the default interzone deny rule which we re-verified again to see it is still set to 'deny' and no one really touched the rule. This is really freaking us out? Any insight on why this is happening and what would be a solution to this?

[TonyDeHart]

I'm definitely no expert but I have had some odd things occur with traffic when doing commits to the firewall particularly when changing the name of anything.  I don't see how that would apply here though. I'd be curious if these two bits of traffic were allowed during a commit and how much traffic was allowed to traverse the firewall.

Might be helpful to have the details on the allowed traffic from the magnifying glass. It would disturb me enough to open a ticket with support to find out why.

[Akhil_B]

Hi Tony, I did open a ticket with PA and they are also researching the issue. And yes, there was some traffic that was leaked during one of the commits as in out of the 3 logs, 1 out 3 logs match one of the commit times but the other 2 won't. Even leaking traffic during commit is a huge flag as far as i know. Here are the screenshots from magnifying glass.

[TonyDeHart]

I'd agree.  Leaks would be disturbing.

I find it interesting though that in session 923204 which has a massive amount of traffic labeled to that interzone rule if the firewall is getting confused when labeling what rule it applies to. I'm curious why it started under a different rule at 8:56 but then shifted at the end to interzone at 9:46 despite nothing obvious changing. Was that rule removed or changed (the Aany2Ju...) that would have caused that session to stay open or change which rule would apply?

I'm not sure what the firewall does usually with open sessions when the rules change mid-session but I have had some things done that presumably would shut down a GlobalProtect session yet its still open even after a rule change which makes me think its taking a shortcut when applying the rules later in the session.

[kiwi]

Hi @Akhil_B ,

I've seen similar behavior with Panorama managed firewalls where the customer configured an override on the local firewalls for the interzone-default security policy with action set to 'allow' directly on the firewall itself.

Could it be that you are running into a similar issue ?

Kind regards,

-Kim.

[TonyDeHart]

I hadn't thought of the override but that is an excellent point. I've run into others issues with overrides that aren't obvious from the start or with duplicate names at different template stack levels.

[reaper]

Have you been able to verify @kiwi 's pointer?

Another thing you may want to check is the deeper details of the log:

A session might get allowed at an early stage (source/destination/port) but eventually no longer be able to hit an security rule because it morphed into an application for which there is no allow OR drop rule. This will cause the session to fizzle out on the default rule and this may look weird

[Akhil_B]

Hi Kiwi,

This is not a panorama managed firewall. We just started introducing Panorama into our environment but this firewall is not even connected to the Panorama yet.