topic Re: Inconsistent behavior in SmartConsole | Not showing last matched rule number & name in logs in Firewall and Security Management

Inconsistent behavior in SmartConsole | Not showing last matched rule number & name in logs

B_P — Thu, 12 Dec 2024 20:04:51 GMT

-- Edit --

As noted by @Paul_Warnagiris [ here ], there is now (at least) a workaround. 🤮

-- Original --

It would be nice if could set the log view to show the last matching rule number and name all the time. For some reason there's a difference for allowed and blocked traffic. If allowed, it will show the first matching rule in the logs view, if blocked, it shows the last matching rule.

This became very annoying after implementing layered policies, specifically for Geo IP filtering as discussed here. Now, the "Access Rule Number" and "Access Rule Name" column in the logs shows "Geo IP" for all Allowed traffic and the block rule number & name for all blocked traffic.

This makes the two columns in the log view practically worthless, so I'm a little suspect that there's already a fix out there, but I'm not finding anything.

Example:

What's stranger yet, is it does the exact opposite for Drops which is even inconsistent with the above and is the correct way it should display.

It is also this way in Web SmartConsole.

Re: Always show last matched rule number & name in logs

Tomer_Noy — Wed, 08 Jun 2022 05:30:30 GMT

Thanks for this feedback.

We'll try to look internally to better understand why there is a difference in behavior.

BTW, do you think that it makes sense for all customers and all cases to always show the last matching rule? (assuming that this remains a "single value" field)

Re: Always show last matched rule number & name in logs

B_P — Wed, 08 Jun 2022 13:14:08 GMT

Yes, it makes sense for all customers and all cases to show the last matching rule. I think any other way changes the purpose of the log view, which is to see why a packet was allowed or blocked.

Re: Always show last matched rule number & name in logs

B_P — Fri, 18 Nov 2022 21:07:13 GMT

5mo later.... The "Access Rule Number" and "Access Rule Name" are default columns in almost every log view and they're completely worthless. Why is this not fixed? Am I the only one that does GEO IP Protection in the recommended way?

Here's what I see:

Re: Always show last matched rule number & name in logs

the_rock — Fri, 18 Nov 2022 21:17:52 GMT

I dont see why you would say its worthless this way...I never have any issues showing the right rule, regardless if its ordered or inline layer. Unless Im not understanding something, it behaves exactly the way its designed.

When you say it would be nice to show last matched rule, well, the rule thats hit is technically "last matched rule", isnt it? Because, in this case, or any case for that matter, implicit clean up rule will be last rule in network layer, so the only logical option is to hit rule that blocks specific countries.

Again, sorry if Im not connecting the dots here, but thats the way I look at it.

Re: Always show last matched rule number & name in logs

B_P — Fri, 18 Nov 2022 21:28:57 GMT

@the_rock wrote:
the rule thats hit is technically "last matched rule", isnt it?"

💯! So why is it showing the first matched rule? Going off the original post, I should see "17.45.23" for the "Access Rule Number" and "Group A Service" for the "Access Rule Name". Instead I'm seeing "6" and "Geo IP Cleanup".

My guess as to the reason you're not seeing it, is because you don't have multiple access control policies like you would if you did GEO IP in the new / recommended way.

Re: Always show last matched rule number & name in logs

the_rock — Fri, 18 Nov 2022 21:33:17 GMT

Ok, maybe we are using different wording here :-). Regardless...just so theres no confusion, can you send screenshots of those rules you are referring to? That would clear some things.

Re: Always show last matched rule number & name in logs

B_P — Fri, 18 Nov 2022 22:12:25 GMT

Well, it looks like this in SmartConsole:

Access Control

- Policy

- Geo IP

- Rule: 6 | "Geo IP Cleanup" | Accept

- General

- Rule 17 | "GroupARules" | Inline

- Rule 17.45 | "GroupAServices" | Inline

- Rule 17.45.23 | "Group A Service" | Accept

Re: Always show last matched rule number & name in logs

the_rock — Fri, 18 Nov 2022 22:21:03 GMT

I would still like to see it, if possible (blur out any sensitive info), but to me, if it hits rule 6, then I cant see what else is there to be hit. So, if that geo rule is hit, then it will be first AND last matched rule. Anyway, sorry mate, not trying to be difficult, but thats the way I look at this. But, if you could attach what it looks like in your rulebase, it may prove me wrong. So far, just going based on what you wrote here.

The only possible way it would hit more than 1 rule if traffic is allowed is if you have multiple ORDERED layers.

Re: Always show last matched rule number & name in logs

B_P — Fri, 18 Nov 2022 22:29:29 GMT

@the_rock wrote:
is if you have multiple ORDERED layers.

You must not have clicked the link in the original post.

https://community.checkpoint.com/t5/Threat-Prevention/R81-Geo-policy-updatable-objects-with-exceptions/m-p/127455/highlight/true#M3279

Fist sentence says "use ordered layers". 😉

Re: Always show last matched rule number & name in logs

the_rock — Fri, 18 Nov 2022 22:35:20 GMT

Alright, I admit when Im wrong :). Anywho, regardless, I would STILL like to see what rules look like, that would help for sure. So, if you can attach a screenshot(s), would be awesome. I will say though, no idea if that post is indeed an official CP recommendation for geo policy, but I never do it like that. I always create geo rules way on top of network layer and it seems to work the best that way. I personally dont see sense in creating ordered layer just for geo block/allow, but again, thats just me.

Re: Always show last matched rule number & name in logs

B_P — Fri, 18 Nov 2022 23:05:32 GMT

@the_rock wrote:
I always create geo rules way on top of network layer

Sure, but there's severe limitations to that which don't work for us.

Re: Always show last matched rule number & name in logs

the_rock — Fri, 18 Nov 2022 23:12:19 GMT

Like what exactly? Please elaborate...

Re: Always show last matched rule number & name in logs

B_P — Fri, 18 Nov 2022 23:40:54 GMT

I think you can answer that with "Why did Check Point create ordered layers?"

Re: Always show last matched rule number & name in logs

the_rock — Fri, 18 Nov 2022 23:45:26 GMT

Sorry mate, but I strongly disagree there. I am pretty positive that reason why CP created ordered layers was NOT with geo stuff in mind : - )). Maybe someone from R&D will confirm or deny that. Either way, I cant really answer your inquiry any further, unless I see what those rules you mentioned look like.

Have an amazing weekend!!

Re: Always show last matched rule number & name in logs

_Val_ — Mon, 21 Nov 2022 07:19:02 GMT

Can we please see a full example of one of those log entries?

Re: Always show last matched rule number & name in logs

B_P — Mon, 21 Nov 2022 16:09:55 GMT

Updated original post with example screenshot.

Re: Always show last matched rule number & name in logs

B_P — Thu, 15 Dec 2022 18:52:25 GMT

Just noticed that Drops display correctly and added another reference picture to the original post. That is very inconsistent behavior.

Re: Inconsistent behavior in SmartConsole | Not showing last matched rule number & name in logs

B_P — Thu, 14 Dec 2023 15:28:48 GMT

Still happening. I can't believe people just don't look at their rules. This tells me Check Point QA is not really testing much because they would immediately see something like this if they were. "Default Firewall view doesn't work properly with ordered layers" -- what's more obvious of an issue than that?

Re: Inconsistent behavior in SmartConsole | Not showing last matched rule number & name in logs

Amir_Senn — Sun, 17 Dec 2023 17:07:31 GMT

Hi,

This behavior is expected - when traffic is accepted - show first rule, when dropped show the rule it will match the drop on.

This behavior is not related only to inline layers but separate layers policy as well (which beside being in use today, was important for backwards compatibility). This might influenced the decision.

I can strengthen Rock's guess, unified layers was introduced during R80.10 and updateable object were introduced in R80.20 if I'm not mistaken.

I understand that this is not optimal for your needs and you rather have the last rule. I think SmartEvent works very well with this though, you might consider using it. The attached is part of a view I created with recorded traffic from my lab.