06-28-2023 09:24 AM
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?
06-28-2023 01:01 PM
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.
06-28-2023 01:15 PM
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.
06-28-2023 01:23 PM - edited 06-28-2023 01:24 PM
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.
06-29-2023 01:14 AM - edited 06-29-2023 01:14 AM
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.
06-29-2023 04:36 AM
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.
06-29-2023 07:03 AM
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
07-10-2023 07:15 PM
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.
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!