Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Vladimir
Champion
Champion

Precedence in the rule order processing in R80.20

Since introduction of the columnar rulebase processing, I am occasionally getting confused about order of precedence and would like for someone to clarify it for me.

Case in point is the rule allowing communication between two groups of domain controllers in different subnets with Active Directory Services specified that is followed by a more open rule permitting all traffic between same subnets.

Which rule should be triggered first?

If the services are matched in the columnar processing, the rule containing AD services should always be triggered first, but this is not what I am seeing.

Thank you,

Vladimir

11 Replies
Norbert_Bohusch
Advisor

Even with column based approach the rule matching itself didn't change. First rule to match is permitting the traffic!

Can you show a log entry where this is not the case and a screenshot of the two rules in question?

Timothy_Hall
Legend Legend
Legend

Spot-on Norbert, column-based matching is just a more efficient technique that an R80.10+ gateway uses for rulebase evaluation, from a rulebase design perspective one can still assume that it is "top-down, first-fit" as far as finding a matching rule.  The only thing that can sometimes be a bit confusing is an "early drop" as mentioned here:

sk111643: Early drop of a connection before the final rule match

-

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Danny
Champion Champion
Champion

 Create a new rule above the one that should match but doesn‘t, then test again. If it doesn‘t work move it up more and more. If it doesn‘t match at all, check content inspection setting of the service of that rule.
Vladimir
Champion
Champion

Thank you guys! Needed this sanity check Smiley Happy

Aws_Abbas
Explorer

 I am also facing the same with R80.20. What did you do to fix it?

I never saw a good document about the R80.20 so far, if there is any please let me know

0 Kudos
Vladimir
Champion
Champion

Please provide more information on what exactly you are observing that is not working according to design, so that we can better understand your problem.

If possible post the screenshots of the policy sections in question as well as the events that you think violate your policy.

Regards,

Vladimir

Aws_Abbas
Explorer

Same issue with the rules as mentioned earlier in this post. It won't use the most specific one even if I'm putting the rule above the general specific one.

0 Kudos
Vladimir
Champion
Champion

Does the traffic in question ends-up using a general rule or is it being processed by the implied rules found in Global properties?

Aws_Abbas
Explorer

I'm trying to come from outside to connect to a web server (Web-Srv1) in the inside trust. Instead of hitting rule #2 it is always hitting rule #3 which is totally different rule set to allow inside traffic to go outside the internet. So this is  somehow the same type of issue that you guys being discussing in the post. I tried to change the NAT on the firewall NICs and spend many hours without luck. This should be simple, what all firewalls accept is the most specific first hit rule and not the general rule.

0 Kudos
Vladimir
Champion
Champion

I'll take it this is Azure environment?

1. If you do not see the logs of your attempts to connect to the Web-Srv1, either allow or drop, start looking at routing.

run traceroute on your originator and see if you are hitting the firewall's interface (you may want to permit ICMP globally while troubleshooting).

2. You configure NAT not on the firewall's interface, but in the object's properties: I.e. if you are trying to permit outbound connection to the Internet only on the host or a network, choose "Hide NAT behind Gateway's IP". If you are trying to permit inbound or bidirectional access, use Static NAT.

3. From the limited information you have provided, I can only draw limited conclusions, so these may not be accurate:

If you are seeing only replies to your connectivity attempts, it looks like you have a route from your source to the Web-Srv1 that bypassing the Check Point gateway, but not in reverse. Instead, Web-Srv1 is using (probably) its default route that is pointing to the Gateway and that is what is getting logged.

PhoneBoy
Admin
Admin

Without knowing exactly how the gateway is seeing the traffic, it's difficult to know if this is a bug or not.

I would use fw monitor to troubleshoot and "follow the bouncing packets."

R80.x Performance Tuning and Debug Tips – fw monitor

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events