Issue Establishing VPN Tunnel Between Test Firewall and Azure Cluster (Route-Based & Domain-Based)

[jennyado]

Hi,

We have a cluster in Azure that uses a route-based VPN with the BGP protocol. This VPN connects to an Azure VPN Gateway (VPN GW), which in turn connects to Cisco SD-WAN routers.

• The VPN community used is route-based.
• The central gateway is the Azure cluster, with an empty encryption domain.
• The satellite gateway is the Azure VPN GW, also with an empty encryption domain.

In the on-prem environment, we have several firewalls that we want to migrate to this Azure cluster. However, these firewalls require a domain-based VPN instead of a route-based VPN.

To validate the configuration, we have added a test firewall to a new domain-based VPN community with the following setup:

• Central gateway: Azure cluster with an empty encryption domain.
• Satellite gateway: Test firewall with a defined encryption domain (contains some networks, not empty).

Before integrating more firewalls, we are performing tests with this single firewall.

Problem:

The VPN tunnel between the test firewall and the Azure cluster is not establishing successfully.

We have done some research and found the following posts stating that, in a domain-based VPN, networks must be defined in each domain for the tunnel to establish correctly:

Route-Based VPN on one side and Domain-Based VPN on the other
Route-Based VPN with Domain-Based VPN
Checkpoint Support: Route-Based and Domain-Based VPN

1️⃣ In our case, for the VPN between the test firewall and the Azure cluster, is it mandatory to define networks in each encryption domain for the tunnel to establish correctly?
2️⃣ If not, are there any other factors we should consider to ensure the VPN tunnel is established correctly?

[Duane_Toler]

You can't do it this way.

* Domain based VPNs take precedence over route-based VPNs.  If you have multiple communities, (some route-based, some domain-based), *AND* there's a chance of a pair of networks overlapping across the communities, then a domain-based VPN will be attempted.

* You can't have a VPN community with GwA having a VPN domain [with objects] defined, and GwB an empty VPN domain.  This won't trigger the route-based VPN domain code.

* Route-based VPNs need to be IKEv2 with Universal Tunnels (One subnet per gateway pair), for best effects (yes you can do it with IKEv1 but it's not as compatible; just avoid it).

* You mention cluster, with BGP, so you'll want to consider:

• unnumbered VTIs
• create a loopback on the cluster members (because VTIs are unnumbered)
• attach the VTI to the loop00 interface on each member (VTI has to proxy off of something)
• create a cluster VIP for the loop00 interface in the gateway topology (VIP is the BGP peering point)
• configure eBGP with multi-hop and TTL 2 or 3 (2 should be enough) (because loop00 is 2 hops across the VTI)
• configure the remote gateway's BGP peer to use the loop00 VIP (the purpose of this mission)
• add a static route to the loop00 VIP onto the local vpnt interface (nexthop gateway logical vpnt#)

The static route establishes reachability to the BGP peer loop00 (because the eBGP peer is now 2 hops away).

Using loop00 VIP for eBGP on route-based VPNs is the best way to go.  You can then build your routemap policies as needed.

You can even enable BFD (ip-reachability-detection) for the BGP peers; be sure to use "ip-reachability-detection multihop local-address <ip of loop00>" on the BGP configuration.  This is because BFD must originate from the BGP peer IP.

Tread carefully with mixing route-based and domain-based VPNs.  You'll almost certainly want to use Encryption Domains per Community instead:

* Edit community

* Click on a gateway in the list

* Click the pencil icon (or double-click) to open a new VPN domain window for the gateway

You can choose a new VPN domain group to be active per community.  This has some other limitations, but overall it works well. 

[jennyado]

Thank you for your very detailed and insightful response.

I understand that, to integrate the new firewalls into the Azure cluster, I need to create a community where both gateways (the Azure cluster and the new firewalls) have defined encryption domains with networks specified, so that the domain-based VPN tunnel can establish successfully.

I have one concern regarding the impact on our existing production VPN (the route-based one, shown on the right side of the diagram). This VPN operates in a separate community with the Azure cluster as the central gateway and the Azure VPN Gateway as the satellite gateway, both with empty encryption domains. I’m worried that adding a domain-based VPN community with defined networks might cause issues or even bring down the route-based VPN. Would this only be a concern if there’s an overlap between the networks defined in the two communities, where the domain-based VPN would take precedence? Or could it affect the production route-based VPN even if they are in different communities?

If the solution is to create a separate VPN community for the domain-based VPN and assign encryption domains with defined networks to both gateways in that community, I assume those domains would be used exclusively by the domain-based VPN and should not impact the community used for the route-based VPN. Could you confirm if this understanding is correct?

Additionally, you mentioned that using encryption domains per community has "some other limitations." Could you please share more details about these limitations you referred to?

Thanks again for your help!

[Duane_Toler]

You'll need to use Encryption Domain per Community for the on-premises gateway communities with the Azure cluster (where you create a domain-based VPN per-community with the on-premises gateways), and use the empty domain/route-based VPN between Azure cluster and the AzVPNGW gateway.  This will work.  I presume you aren't using BGP across the domain-based VPN here (no need, really).

So long as a network from the left side diagram doesn't have an overlap on the Cisco vEdge and AzVPNGW VPNs, then you're ok. 

• For limitations, you still need to be mindful of the default gateway VPN domain, if you have this on any gateway in your management domain:  https://support.checkpoint.com/results/sk/sk182946
• There was also an older issue with the traffic selectors, but looks like R&D fixed this: https://support.checkpoint.com/results/sk/sk170857

If you need the walk-through, here's where to configure EDPC:  https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SitetoSiteVPN_AdminGuide/Con...

You can also handle VPN-routing traffic, at the Azure cluster, with VPN Directional matching:  https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SitetoSiteVPN_AdminGuide/Con...

Without directional matching, you could end up with traffic flowing, or matching, in odd places you didn't expect.  This would be most applicable on the Azure cluster.  On the Star communities, you can enable VPN Routing, then use Directional matching rules to enforce that policy.