Route Based VPN on one side and Domain Based VPN on other

[Serhii_Yaholnyt]

I have to configure site to site VPN between CIsco and CheckPoint. The problem is that this is R77.30 gateway and I cannot upgrade to R80.10 as we have SandBlast Agents and only one management server can be installed. There is a limitation in R77.30: CoreXL does not support Route Based VPN. So the only way is domain based VPN. But it is very uncomfortable in CISCO router to configure Crypto Map for our topology. I decided to configure Route Based VPN on Cisco and Domain Based VPN on CheckPoint. I have tried it in my lab and it seems like it works. Is it strange that it works or it does not matter what kind of VPN is configured on sites? Have anybody configured VPN in such way? What problems can I meet in production environment?

[G_W_Albrecht]

I would  think that the important part is that VPN negotiations succeed - the decision which packets are sent thru VPN tunnel for CP side is based on VPN Domain/Community definition. There is also sk108600 VPN Site-to-Site with 3rd party  that may help...

[Timothy_Hall · Accepted solution]

The underlying mechanics of IKE and IPSec work exactly the same regardless of whether domain-based or route-based VPNs are used; the only difference is how traffic is determined to be "interesting" and in need of encryption.  With domain-based VPNs if the source IP is in your firewall's VPN domain AND the destination IP address is in a peer's VPN domain, the traffic is interesting and needs to be encrypted.  If only one or neither are true, the traffic goes in the clear.

For a route-based VPN, if IP routing determines that the egress interface is a VTI the traffic is interesting and will be encrypted, then forwarded out the appropriate physical interface.  If IP routing determines that the egress interface is a physical one (i.e. eth0), the traffic simply goes in the clear.  Note that the routes making this determination can be statically created, or dynamically learned through a routing protocol such as OSPF.

The main thing you have to watch out for when mixing domain and route-based setups on the same tunnel is how the Phase 2 Proxy-IDs are negotiated.  As the initiator, domain-based VPN setups will negotiate subnets (i.e. 192.168.1.0/24) because the VPN domains are fixed and known ahead of time.  However with a route-based VPN setup, the firewall does not necessarily know ahead of time which IP addresses will be used in the tunnel because routes can be dynamically received through OSPF.  For that reason when the route-based VPN side initiates a Phase 2 negotiation, it will request a universal tunnel (i.e. 0.0.0.0/0, 0.0.0.0/0) unless told otherwise which will most definitely honk off the domain-based VPN side.

Almost all existing Check VPN implementations are domain-based due to the CoreXL limitations with route-based VPNs in R77.30 and earlier.  Route-based VPNs will definitely become more common now that this restriction has been lifted in R80.10+.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Serhii_Yaholnyt]

Hello, Tim.

Could you please clarify, when there will be such divergence during Phase 2, will negotiation fail or tunnel will be up but traffic will not be decripted by CheckPoint which is configured with Domain-Based VPN?

[Timothy_Hall]

It depends on which peer is attempting to initiate the tunnel.

If it is the domain-based side initiating, it will propose subnets in Phase 2 which will be a subset of a universal tunnel (0.0.0.0/0) and generally accepted by the route-based side.  Phase 2 will complete, and traffic will flow for the proposed subnets through the VPN tunnel.

If it is the route-based side initiating, usually it will propose a universal tunnel in Phase 2 which the domain-based side will reject with a "no proposal chosen" error. 

Keep in mind that a separate IPSec tunnel is formed for each successful Phase 2 negotiation, so there can be situations where interesting traffic arrives at the domain-based side, it proposes subnets which are accepted and a two-way tunnel is formed for those subnets.  Then some interesting traffic arrives at the route-based side for which there is no existing Phase 2 tunnel, so it tries to negotiate a universal tunnel with the domain-based side which fails.  So basically it looks like some subnets are working in the "tunnel" and some are not.  If you look closely in the logs through you'll see that Phase 2 tunnels (Quick Mode) have successfully formed for the subnets that are working, but there are Phase 2 errors such as "no proposal chosen" or "Invalid ID" constantly being spewed trying to form tunnels for the subnets which are not working.

Hopefully that made sense.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[NunoAlves22]

Hi all,

I´m having an issue with this scenario. I have on my side a Checkpoint with a domain based VPN configured and on the other side a Cisco router with route based VPN configuration. When phase 2 is renegotiated and initiated by the router if it sends 0.0.0.0 the tunnel doesn´t come up and only after, when it probably learns the specific route 10.0.1.0/24 for exemple, is when the tunnel comes up. If it´s Checkpoint on my side to initiate the tunnel there are no issues.

Is there any workaround for this? This haves little impact but generates some alarms on our monitoring platform so we would like to solve this.

thank you.

Nuno