- Products
- Learn
- Local User Groups
- Partners
- More
Step Into the Future of
AI-Powered Cyber Security
When the Agents Attack
A Live Look at Agentic Exposure Validation
Bridge the CAASM Gap
with Exposure Management
AI Security Masters E8:
Claude Mythos: New Era in Cyber Security
CheckMates Go:
CheckMates Fest
Hi,
Actually working on an 23000 Appliance on R80.40.
I'm working on moving up the most used policy rules to help on performance issues we've encountered, and I was wondering about NAT rules.
We have about 1200 NAT rules on the gateway cluster, and some of the most used NAT rules are at the very bottom.
For performance tuning, do I have to move up these NAT rules too ?
Thanks,
Regards
Moving up frequently-hit Access Control policy rules will have little effect on rulebase lookup performance in R80.10+ due to the advent of Column-based matching.
NAT rules did pick up a hit counter in R81+, however the position of NAT rules in the policy once again has little impact on NAT rulebase lookup performance in most cases due to the caching of NAT rulebase lookups in a table called fwx_cache. This table can store up to 10,000 source/dst cached NAT rule matches, so in the case that the cache becomes completely full (fw tab -t fwx_cache -s) additional NAT rule lookups will need to occur, and in that specific case NAT rulebase lookup performance will be improved by moving rules up as the NAT policy matching is still top-down, first fit and not Column-based matching. So unless you have thousands of NAT rules there is generally little to be gained by moving them up.
My advice is yes, though technically, from my experience, does not matter whole lot for NAT rules, as it does for access control rules.
Rulebase order matters less in R8x releases.
There are a handful of instances where rulebase order still matters…in the access policy…for SecureXL templating purposes.
I don’t believe it matters for NAT rules.
Moving up frequently-hit Access Control policy rules will have little effect on rulebase lookup performance in R80.10+ due to the advent of Column-based matching.
NAT rules did pick up a hit counter in R81+, however the position of NAT rules in the policy once again has little impact on NAT rulebase lookup performance in most cases due to the caching of NAT rulebase lookups in a table called fwx_cache. This table can store up to 10,000 source/dst cached NAT rule matches, so in the case that the cache becomes completely full (fw tab -t fwx_cache -s) additional NAT rule lookups will need to occur, and in that specific case NAT rulebase lookup performance will be improved by moving rules up as the NAT policy matching is still top-down, first fit and not Column-based matching. So unless you have thousands of NAT rules there is generally little to be gained by moving them up.
Thanks for your answers.
My first impression was wrong then, I'm glad I asked on the forum.
I'll keep the shared link on my bookmarks, always interesting to have more details !
Thats what te forum is all about, mate. By the way, to add to what @PhoneBoy said, though he probably remembers this way better than I do (lol), back in old days of CP, rule orded DID matter (big time actually), specally I would say R65 and before. But, as he mentioned, in R80+, its not overly relevant, though me personally, I like to keep it clean and in order.
Rulebase order mattered until R8x, specifically because of:
Unless you're using one of the handful of services that can't be templated by SecureXL (traffic must go F2F), access policy rulebase order shouldn't matter.
Like what @PhoneBoy said yes that is true and I have seen NAT rules close to 2000 and system was functioning well. My 2 cents here since I faced the issue numerous times and helped me a lot is crating a domain UDP object for port 53 and remove sync on cluster from Advanced. Since its a UDP Traffic this is stateless at first place and it does not make any sense syncing the UDP connections on cluster. I always create this object and put the DNS rule on much top
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 29 | |
| 15 | |
| 6 | |
| 6 | |
| 5 | |
| 5 | |
| 5 | |
| 4 | |
| 4 | |
| 3 |
Wed 10 Jun 2026 @ 01:00 PM (EDT)
Deep Dive: When the Agents Attack: A Live Look at Agentic Exposure ValidationThu 11 Jun 2026 @ 11:00 AM (EDT)
Tips and Tricks 2026 #8: Say Yes to AI Without Saying Yes to RiskFri 12 Jun 2026 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 47: Continuous Threat Exposure ManagementTue 16 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point SASE | Internet Access Optimization & Performance TuningWed 10 Jun 2026 @ 01:00 PM (EDT)
Deep Dive: When the Agents Attack: A Live Look at Agentic Exposure ValidationThu 11 Jun 2026 @ 11:00 AM (EDT)
Tips and Tricks 2026 #8: Say Yes to AI Without Saying Yes to RiskFri 12 Jun 2026 @ 10:00 AM (CEST)
CheckMates Live Netherlands - Sessie 47: Continuous Threat Exposure ManagementTue 16 Jun 2026 @ 05:00 PM (CEST)
Under the Hood: Check Point SASE | Internet Access Optimization & Performance TuningThu 18 Jun 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point WAF - The Next Generation of AI powered protectionAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY