Inconsistent behavior in SmartConsole | Not showin... - Check Point CheckMates

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.

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)

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.

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

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.

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.

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

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?

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.

Thanks @Amir_Senn for the clear and accurate explanation!

Indeed there were challenges when adapting the log behavior that had a single rule match to the new paradigm where multiple matches are possible.

In the last year or so, we see a significant rise in ordered layer usage. Both by customers trying to logically separate parts of their policy, and by our own products who leverage ordered layers to add additional enforcement capabilities (such as Playblocks and IoT).

In case of a block action, I believe that it's the correct choice to put the rule that actually blocked the traffic. Since ordered layers are evaluated in order, that's the first matching rule that has a block action.
In case of an accept action, we understand the feedback that the first layer may not be the correct choice to use in the log. However, the last layer doesn't always make sense either.

@Meital_Natanson 's team is looking into a slightly more "intelligent" mechanism for Accept logs. In this mechanism, Check Point's extra layers (Playblocks, IoT) will be skipped when choosing the rule to place in the log, so that we will choose the layer that matters more to the admin. In case you have your own ordered layer that you want to skip, you'll be able to mark it with a tag or prefix, and we'll take that into account as well.

We'll update the community once we have something available to try.

I will reiterate the word "worthless." If this is expected design, then the it is terrible. Everything in my logs on every gateway is now showing being accepted at rule #4. This is the new automated remediation rule named "Allow traffic if allowed by Network layer and by Playblocks" This effectively makes filtering by rule number useless. You can't move the automated remediation or its not effective. This is just pretty ugly no matter which way you cut it if you are working these logs on a daily basis. YUK! The only way to get what I'm looking for at this point is to click each rule and then click on "matched rule." Four clicks per log entry when I used to be able to filter by rule number with one click. I can't emphasize how bad this is. Every one of my customers using playblocks is complaining about this.

Respectfully, I would disagree that its terrible. To me, it makes total sense, specially if traffic is matched on multiple rules/layers.

Best,