- 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
I have about 150 policy based site-to-site VPNs defined on my gateway cluster.
One of these VPNs is with a Cisco ASA peer that is a very complex mixture of network to network and host to host phase 2 SAs. It's a pain to modify because the checkpoint side wants SAs to be all host to host or network to network. I'd like to simply my life by moving to universal traffic selectors (one tunnel per gateway pair). But the Cisco administrator can't figure out how to do that without moving to a full on route-based VTI.
So, I've been reading up on VTIs, and I am concerned about a requirement in the GAIA Administration Guide about setting up VPN Tunnel Interfaces. It seems to imply that policy based VPNs cannot co-exist with route based VTIs on the same checkpoint firewall. The section states:
Make Route Based VPN the default option.
Configuring Route Based VPN
When Domain Based VPN and Route Based VPN are configured for a Security Gateway, Domain Based VPN is active by default. You must do two short procedures to make sure that Route Based VPN is always active.
The first procedure configures an empty encryption domain group for your VPN peer Security Gateways. You do this step one time for each Security Management Server. The second step is to make Route Based VPN the default option for all Security Gateways.
1. Configuring an empty group
2. Configuring the Route Based VPN as the default choice
Do these steps for each Security Gateway.
1 From the left navigation panel, click Gateways & Servers.
2 Double-click the applicable Security Gateway object.
3 From the left tree, click Network Management > VPN Domain.
4 Select Manually define and then select the empty Group object you created earlier.
5 Install the Access Control Policy.
So, the above is telling me to clear my encryption domain, is it not? What about all the other policy based VPNs that depend on that encryption domain?
It's the encryption domain of the relevant VPN community which needs to be empty, not your FW object.
We have R81.20 ClusterXL with a mixture of RB and PB VPN which co-exist without issues.
Route-based VPNs and encryption-domain-based VPNs can absolutely coexist. Use the normal group for your encryption domain and the empty group for the peer's.
That said, the type of VPN is only locally significant. The Cisco end can move to a route-based VPN and you can keep your end encryption-domain-based unless you need the VPN endpoints to talk to each other over the VPN (e.g, if you want to run dynamic routing over the VPN, that will require a numbered VTI). Otherwise, the other end of a tunnel doesn't know if you're using a VTI or not. You could just set your community to negotiate a gateway-to-gateway tunnel.
It's the encryption domain of the relevant VPN community which needs to be empty, not your FW object.
We have R81.20 ClusterXL with a mixture of RB and PB VPN which co-exist without issues.
Route-based VPNs and encryption-domain-based VPNs can absolutely coexist. Use the normal group for your encryption domain and the empty group for the peer's.
That said, the type of VPN is only locally significant. The Cisco end can move to a route-based VPN and you can keep your end encryption-domain-based unless you need the VPN endpoints to talk to each other over the VPN (e.g, if you want to run dynamic routing over the VPN, that will require a numbered VTI). Otherwise, the other end of a tunnel doesn't know if you're using a VTI or not. You could just set your community to negotiate a gateway-to-gateway tunnel.
100% they can coexist, no issues, works 100%
Andy
Thanks everyone!
yes no problem but read this https://support.checkpoint.com/results/sk/sk109340
Glad you pointed that out, certainly something to look out for.
Andy
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 26 | |
| 18 | |
| 12 | |
| 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