Domain based VPN to ANY (0.0.0.0/0) R80.20 question

[Alan_Camelo1]

Hi All,

I am trying to create a VPN to a 3rd party using a backup Tunnel where possible using a destination of ANY on http/https. I only want this rule to be hit after other rules that will NOT route through the tunnel so it will be lower in the rule base. My questions are

1. Can I use a VPN to ANY 0.0.0.0 using Domain based VPN as I only want this rule to be hit after other rules have been satisfied.

2. When defining the local domain e.g 172.16.10.0/24 do I just add it to the Topology/VPN part? what if other subnets exist do they need to be added to the SA? 

3. Can I add a backup tunnel into the start community? if so what is the metric or mechanism that says primary is A secondary is B?

Thanks in advance

Al

[G_W_Albrecht]

Apart from CP R80.20 SitetoSite VPN AdminGuide you should look into:

sk44852: How to configure a Site-to-Site VPN with a universal tunnel

sk108600: VPN Site-to-Site with 3rd party

sk104760: ATRG: VPN Core

sk164355: VPN redundancy does not work when establishing an IPsec VPN Tunnel with a third-party peer

[Alan_Camelo1]

Thanks for the quick reply, the setup in sk44852 seems more relevant but it implies that you want to send all Zeros as a local network, what I want is the remote defined as all Zero's 0.0.0.0/0.
"the local Check Point Security Gateway will send all 0's (zero's) for the network address and netmask for these networks:"

[G_W_Albrecht]

sk44852  is the solution, just read it more carefully:

Topology:

(internal network 10.2.2.0/24)-[Check Point Security Gateway]---{universal VPN tunnel}---(IP 172.16.5.10)-[Remote VPN Peer]-(internal network 192.168.4.0/24)

[Alan_Camelo1]

Thank you, appreciate your help. Just to clarify this is for the remote encryption domain right? I have read it again and its still not very clear.

[Bob_Zimmerman]

From my reading, sk44852 is only about the negotiation. I hesitate to recommend user.def modifications in any circumstance because they're extremely easy to forget when upgrading a SmartCenter. In this case, a universal negotiation could be forced easily enough using the community.

I'm not sure a universal negotiation is the problem, though. There is no way to specify a rule is only valid when not using a VPN. All you can do is specify the rule isn't restricted to a particular VPN. I think a route-based VPN is the solution to that part of the requirements, and they negotiate universal tunnels as a side-effect of how they work. You still can't say a rule only works for traffic not using the VPN, but you can use the routing table to select whether the VPN or some other connection should be tried first.

[Alan_Camelo1]

Many thanks for all your help and comments, I will continue to research and if I find anything I'll let you know.

[Alan_Camelo1]

Hi All,

Many thanks for your comments, I managed to get a routed VPN up and running with a 3rd party vendor and all seems OK apart from some issues with getting to a host behind the vpn. I added a vti interface and attached to the remote end point defined then added a static route and all seems to be in place. However I have noticed the following route.

C 0.0.0.0/26 is directly connected, vpnt10(down)

when doing a vpn tu the p1 and p2 are up so all appears OK, can anyone please comment on the above route and why it mentions down? Also when I look at the vti interface counters they do increase when sending some test traffic.

Thanks in advance