- Products
- Learn
- Local User Groups
- Partners
- More
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hi There,
I need to block (or provide access to specific networks in community). For example, i have one VPN community with five sites and each site has 3 networks, i need to open access:
Site1-Network1 to Site2-Network1
Site1-Network2 to Site2-Network2
Site1-Network3 to Site3-Network3
but Site1-Network1 shouldnt get access Site2-Network2
do i have to create separate VPN rules like:
Source (Site1-Network1) to Dest (Site2-Network1) - VPN Community
or one big rule for VPN
Source (Site 1-5) to Dest (Site 1-5) - VPN Community
and next create separate security rules for each condition? like
Source (Site1-Network1) to Dest (Site2-Network1) - Any - Any
Just not clear for me, is it possible to play with access between networks in one VPN community or all networks inside will be accessible for each other
thanks
Simply defining VPN community establishing the necessary conditions for the encrypted traffic between sites, but it is still subject to the Access Control policy rules.
You can group the VPN rules under the same policy section with individual rules containing groups of networks, for compactness.
You may use a large parent rule for the Inline VPN policy, but then the parent rule should be permissive and the child rules should be restrictive. For me, this second option does not sound very appealing.
Technically, you could do both, as long as there is no rule conflict. Like all vendors, rules go as Im sure you know, top to bottom, left to right. Though, but this is just me, maybe for better "separation", I would create different rules.
Simply defining VPN community establishing the necessary conditions for the encrypted traffic between sites, but it is still subject to the Access Control policy rules.
You can group the VPN rules under the same policy section with individual rules containing groups of networks, for compactness.
You may use a large parent rule for the Inline VPN policy, but then the parent rule should be permissive and the child rules should be restrictive. For me, this second option does not sound very appealing.
Thanks!
do you mean i can create "large parent rule" like all VPN sites - Any - Any - VPN community and next play with security rules - Net1 (site1) to Net(5) site3?
Im pretty sure thats what @Vladimir meant.
Great! thank you very much guys!
Just to share quickly what I usually recommend to people and that seems to work real well. So, for all the interfaces, we assign zones to them and then say you can create inline parent rule, that goes like this ->
src -> internal zone (referencing internal interface), dst -> any -> vpn -> any , services -> any -> action -> create new layer and call it say "internal layer"
Then, below that "parent" rule, you can set up all the child rules (as they call them) and at the bottom, you will have any any drop, which is EXPLICIT clean up rule...NOT to be confused with IMPLICIT clean up rule, always very last at the bottom of the rule base
Having said this, we always say to customers to create VPN rules towards to top of the rulebase, not part of any inline layer, so that way, it would not "conflict" with anything.
Hope it makes sense, but happy to show you in my lab as well.
Yes, but I have stated earlier, the parent rule in this case will be permissive and the child rules restrictive.
You are better off having individual permissive rules grouped in the same policy section.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 26 | |
| 18 | |
| 10 | |
| 8 | |
| 6 | |
| 6 | |
| 6 | |
| 5 | |
| 4 | |
| 4 |
Wed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasWed 03 Dec 2025 @ 10:00 AM (COT)
Última Sesión del Año – CheckMates LATAM: ERM & TEM con ExpertosThu 04 Dec 2025 @ 12:30 PM (SGT)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - APACThu 04 Dec 2025 @ 03:00 PM (CET)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - EMEAThu 04 Dec 2025 @ 02:00 PM (EST)
End-of-Year Event: Securing AI Transformation in a Hyperconnected World - AmericasAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY