Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Dale_Lobb
Advisor
Jump to solution

Can Policy based VPNs and Route based VTI coexist on the same checkpoint firewall?

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?

0 Kudos
2 Solutions

Accepted Solutions
Alex-
Leader Leader
Leader

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.

View solution in original post

Bob_Zimmerman
Authority
Authority

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.

View solution in original post

4 Replies
Alex-
Leader Leader
Leader

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.

Bob_Zimmerman
Authority
Authority

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.

the_rock
Legend
Legend

100% they can coexist, no issues, works 100%
Andy

0 Kudos
Dale_Lobb
Advisor

Thanks everyone!

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events