- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Announcing Quantum R82.10!
Learn MoreOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
R77.30 Reference - sk106597
Does such a thing exist for R81.10? I've looked at the R81.10 Security Management Administration Guide and R81.10 Logging and Monitoring Administration Guide per the suggestion of the R77.30 reference article, but nothing concrete jumps out at me.
The main thing I am wondering is, is it still best practice to have VPN (site-to-site) rules at the top of the rulebase, or should it follow more of a hit count approach now?
I will tell you approach I have and works perfectly fine, but, everyone is different.
-generic rules, such as geo blocks, vpn rules, blocking known bad IPs etc, top of the rulebase
-for each interface that belongs to specific zone, inline layer inside default network layer
-separate ordered layer that has appc+urlf enabled for those rules (MAKE SURE that layer has any any allow at the bottom, otherise all traffic would be blocked)
-any additional ordered layer for specific blade if needed
Alsom keep in mind, link you gave is indeed good reference, but, it was written when layers with CP did not exist back in the day, unlike some other vendors.
Hope that helps.
Andy
Computers are really, really fast. The only rule order optimization worth caring about is stuff which disables SecureXL templates. Check 'fwaccel stat' to see if it says templates are "disabled from rule ###" or something similar, and consider moving that rule lower.
Otherwise, arrange your rules to make sense for the humans who have to deal with them.
The Admin guide contains guidance on crafting the Access Policy:
Yes, I went over that in my original post. The section of the Admin guide you linked to and that I've read as well, does not spell out VPN rule placement like the R77.30 SK did, that's why I made this post, to see if VPN rules should still be placed at the top of the rulebase as was once suggested in R77.30. This appears to no longer be a thing from the feedback I am getting due to the evolution of the software, which is great.
Alongside all the other advice in this thread, I'd suggest that putting VPN rules into an inline layer (one layer per VPN community) is a good idea, as it means you can manage that traffic without having to be concerned about it accidently matching any general rules lower down in the policy. A parent rule with 'any any any' but with the VPN community specified probably would work, but I've not personally tested that.
It does work, I tried that before, but honestly, I always prefer to have VPN rules in general section, BEFORE any inline layers, but again, thats just me.
Andy
I've started doing this recently and I've been a big fan. Easier to manage and I feel better about getting more granular with the security policy as it doesn't add to the overall length of the main policy, just uh the inline, which is fine.
It was not easy to get used to from R77 code, but it makes so much more sense. Cisco had layered approach for who knows how long now, but obviously, as their web filtering feature is not that great, thats where CP comes in.
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 26 | |
| 20 | |
| 16 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 |
Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY