- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Precedence in the rule order processing in R80...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
now available at maxpowerfirewalls.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you guys! Needed this sanity check
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Does the traffic in question ends-up using a general rule or is it being processed by the implied rules found in Global properties?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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."