route based VPN requires VPN domain

[dehaasm]

We are trying to setup a route based VPN where all current site to site VPN are now domain based. all VPN communities have their local and remote network defined. However for the route based VPN it seems that the gateway properties VPN domain needs to be configured on User Defined with a empty dummy object?

So we should configure this as follows as displayed in the screenshot? What would happen with the existing domain based VPN will they keep on working with their own community based local and remote networks?

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_Gaia_AdminGuide/Topics-GAG/VPN-Tun...

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.

Without this setting both IPsec tunnels are up but the tunnel interface topology settings cant be configured to "based on routes". When trying to send traffic via the route based VPN (with static route to peer tunnel IP) traffic is also not matched on the security policy forcing it into the VPN community, so it is not being send into the VPN tunnel. Security policy is correctly configured with these settings using the correct VPN community.

When trying to ping the remote tunnel IP it seems that the reply is currently being dropped, again i believe due to the lack of above setting and defining route based on the tunnel interface topology spoofing settings. 

MyIntranet > MyIntranet

MyIntranet > Internal_Clear

Internal_Clear > MyIntranet

Would above setting fix all these issues and could this be done witouth impacting currently active domain based VPNs?

[G_W_Albrecht]

See sk109340: Mixing Route Based VPN with Domain Based VPN on the same Security Gateway

[dehaasm]

That explains my issue indeed and is what i am seeing. Inside the VPN communinity i have already configured a empty local object to prevent domain based VPN from taking place. But I guess the issue is that on the gateway level, network management, VPN domain it is configured on all ip addresses behind cluster member based on topology information" however as explained in referenced article should be configured as well as user defined with empty object for routing based VPN to take place. That would probably fix the issue but i am not sure it this would impact the existing VPNs which are domain based. But i guess the other VPN domain based VPN communities have their own local and remote subnets defined so should not be impacted from my point of view.

[dehaasm]

funny thing is that a ping is working (domain VPN based) by implied rules and the other route based VPN rule is not being matched on other TCP ports.

Here you see in the community it has empty object with nothing inside of the local gateway.

So not sure if this is causing the enforcement of Domain based VPN and should also be configured with empty object manually.

[Bob_Zimmerman · Accepted solution]

Your mention of "the other route based VPN rule" makes me suspect you're using the VPN community for the route-based VPN in a rule. That won't work. As far as the rulebase is concerned, traffic over a route-based VPN doesn't use any VPN community. It will only match rules with the VPN Community column set to Any Traffic.

[dehaasm]

Hi Bob thanks for the heads up, in the security rule in source i have any in destination the network that i am trying to reach over the VPN and in the VPN column i have the directional match, where my intranet is basically the VPN community, that isn't correct?

MyIntranet > MyIntranet

MyIntranet > Internal_Clear

Internal_Clear > MyIntranet

[Bob_Zimmerman]

The encryption-domain-based VPN decision happens very early (before any NAT can happen, even). If the source is in my encryption domain and the destination is in a peer's encryption domain, the connection gets flagged for encryption to that peer.

The empty encryption domain isn't technically a requirement of route-based VPNs. All you need to do is break the encryption-domain-based decision above. There are two ways you can do this: either ensure the source isn't in your encryption domain or ensure the destination isn't in any peer's encryption domain. Unless you're trying to set up an encryption-domain-based VPN and a route-based VPN as multiple separate paths to reach the same remote network, this can generally be done by setting the object for the remote peer to use an empty group for its encryption domain. You don't need to do this for both ends of the tunnel, just for one.

[dehaasm]

I understand the VPN community VPN domain setting is empty and the VPN domain on the satellite gateways also put on empty, we defined the static routes to point to the tunnel interfaces remote IP as next hop. Now when i do a ping i see that implied rules allow it and it is correctly send over the VPN route based. Other ports that should match the directional match rule are not matching this rule still. Is my security rule incorrect in VPN column?

[dehaasm]

when i put the security rule VPN column to any it is indeed matching the rule and encrypting properly. Does this mean that the directional rule match is not a requirement anymore?

[PhoneBoy]

Strictly speaking, no.

Directional VPN rules are necessary to support specific use cases with domain-based VPNs as described in the documentation.
Directional VPN rules cannot be applied to Route-based VPN as communities are not used for these VPNs.

[PhoneBoy]

In general, domain-based VPNs take precedence over route-based ones.
See also: https://support.checkpoint.com/results/sk/sk109340 

[Lesley]

You can not just configure the empty encrpytion domain on the relevant route based VPN community?

I would not mess with the global encryption domain, this could affect more tunnels.

I have big setups with route and domain based tunnels on same fw so it is an option for sure

[Duane_Toler]

Route-based VPNs imply a routing protocol between the gateways inside the VPN.  You also need to configure VTI [in Gaia WebUI or CLISH] on each gateway and use either static routes (static-route 10.1.1.0/24 nexthop logical vpnt1) or BGP between the gateways (please don't do OSPF).  Your VPN tunnel sharing needs to be "one tunnel per gateway pair" to get universal tunnels.  You'll need IKEv2 as well [but you should always use IKEv2].

With VTIs configured, fetch interfaces without topology, to get the VTIs added to gateway topology.  You can configure anti-spoofing on the internal interfaces to "determined by routes" [not on the VTIs; disable anti-spoofing on the VTIs].