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

[B_P]

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.

[Tomer_Noy]

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)

[B_P]

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.

[B_P]

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:

[the_rock]

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.

[B_P]

---

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

[the_rock]

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.

[B_P]

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

[the_rock]

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. 

[B_P]

---

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

Fist sentence says "use ordered layers". 😉

[the_rock]

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.

[B_P]

---

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

[the_rock]

Like what exactly? Please elaborate...

[B_P]

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

[the_rock]

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

[_Val_]

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

[B_P]

Updated original post with example screenshot.

[B_P]

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