- Products
- Learn
- Local User Groups
- Partners
- More
Policy Insights and Policy Auditor in Action
19 November @ 5pm CET / 11am ET
Access Control and Threat Prevention Best Practices
Watch HereOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hello Everybody,
I have a little question that has been bothering me for while. Let's say that I have management with a VSX with 2 Virtual Systems (VS_A and VS_B) . The VS_A has a VPN site to site with peerA that has the network 172.16.20.0/24(remote domain) and now I want to create a site to site with VS_B with peerB (a total different site that peerA) that has as remote domain 172.16.20.1, 172.16.20.2 (and maybe also the whole 172.16.20.0/24).
Would this cause overlapping even though are different Firewalls?
If that is the case, is there a way to solve this? (maybe having a multidomain with different CMAs for each VS for example)
Thanks in advance
You can resolve this issue, but: You are forced to do a manual routing, and this will get more and more complicated as new sites are added to the VPN community. See sk31021:
Common VPN routing scenarios can be configured using a VPN star community, but not all VPN routing configuration is handled through SmartDashboard.
VPN routing between Security Gateways (star or mesh) can also be configured by editing the configuration file: $FWDIR/conf/vpn_route.conf.
For information on Route Based VPN, refer to the Route Based VPN section in the R80.10 VPN Site to Site Administration Guide
Thank you for the answer. So, according to what you mentioned, there will be indeed overlapping even if the firewalls are different but are managed by the same Smartcenter. As you said, It looks that using vpn routing will cause this to get more difficult to manage with time so I was thinking, if I use a multidomain with different CMA for each Virtual System, I wouldn't this "limitation" (the overlapping in this case), right?
You are missing the problem here - not the same SMS is an issue, but the CP Domain Based VPN ! An Encryption Domain can not contain duplicate subnets or routing will not work. So the solution is not MultiDomain, but no duplicate subnets at all for Domain VPN or no Domain VPN but PBR...
Got it!, I'll keep this in mind. Thank you so much!
More information can be found in CP R80.30 Site to Site VPN AdminGuide, chapter Domain Based VPN p.74f and Route Based VPN p.79f !
Hi @G_W_Albrecht,
I'm a bit confused here as I have a similar, albeit slightly different, scenario I'm looking for assistance with. In my scenario, peerA and peerB will both have VPNs to peerC. So the remote encryption domain does not span multiple peers, however, the local encryption domain on peerA and peerB will contain overlapping subnets. Is this still not supported?
If possible, can you provide assistance in the linked forum post?
MEP (Multiple entry point) VPN may solve your use case
Multiple Entry Point (MEP) VPNs
I think that we have to divide the question in two parts: Overlapping encryption domains and routing.
VSX is a great way to overcome overlapping of DEs since each VS will have their own VPN Encryption domain and their own VPN tunnels. You can create specific groups for each one with the relevant networks, of course this will depend on your VSX architecture.
The routing issue is how the packet reach the correct VS, after that it will be solved.
Hope it helps!
Federico Meiners
@VictorPG It will not cause overlap since peers are associated with a specific S2S VPN, you can have different peers with the same remote encryption domain as long as they are not in the same VS.
What a peer encryption domain does is injecting routes to the routing table so your firewall knows that that IP is reachable via that peer. If you have two peers with the same Remote DE in the same firewall (VS or not) then you will have overlapping routes.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 28 | |
| 15 | |
| 13 | |
| 13 | |
| 12 | |
| 7 | |
| 6 | |
| 6 | |
| 5 | |
| 5 |
Wed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchWed 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 - AmericasWed 26 Nov 2025 @ 12:00 PM (COT)
Panama City: Risk Management a la Parrilla: ERM, TEM & Meat LunchAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY