- Products
- Learn
- Local User Groups
- Partners
- More
CheckMates Fifth Birthday
Celebrate with Us!
days
hours
minutes
seconds
Join the CHECKMATES Everywhere Competition
Submit your picture to win!
Harmony Mobile 4:
New Version, New Capabilities
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
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
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?
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
Thank you guys! Needed this sanity check
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
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
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.
Does the traffic in question ends-up using a general rule or is it being processed by the implied rules found in Global properties?
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.
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.
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."
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY