> Source: [sk183099](https://support.checkpoint.com/results/sk/sk183099)
# sk183099 - Cloud Firewall for Azure Virtual WAN - Site to Site VPN Configuration Guide
| Property | Value |
|----------|-------|
| Solution ID | sk183099 |
| Date Created | 2025-02-02 |
| Last Modified | 2026-04-16 |
| Technical Level | General |
| Products | Cloud Firewall |
| Versions | R82.10, R81.10 (EOS), R81.20, R82 |
| OS | Gaia |
| Platform | Azure |
## Solution
The standard VPN site-to-site connection terminates at an Azure VPN Gateway. This guide explains how to terminate a VPN site-to-site connection directly at a Cloud Firewall Gateway for Azure Virtual WAN instance.
**Overview**
By using Check Point Cloud Firewall, organizations can leverage robust encryption protocols and advanced security features to maintain the integrity, confidentiality, and availability of their interconnected networks.
Click Here to Show the Entire Article
### Route-based VPN {#TARGET_ID_1}
Show / Hide this section
> A route-based VPN is a flexible and scalable approach for connecting on-premises networks to Azure Virtual WAN through IPsec tunnels.
>
> Unlike domain-based VPNs, route-based VPNs rely on dynamic routing protocols like BGP to manage connectivity, making them ideal for complex and evolving network topologies.
>
> For detailed information about route-based VPNs, see the [Check Point Site to Site VPN R82 Administration Guide](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SitetoSiteVPN_AdminGuide/Content/Topics-VPNSG/Route-Based-VPN.htm?TocPath=Route-Based%20VPN%7C_____0#Route-Based_VPN) \> Route-Based VPN.
>
> **System Components:**
>
> 1. Cloud Firewall for Azure Virtual WAN instances are single gateways that are clustered together using the internal load balancer. The gateways are unaware of each other and operate without state synchronization.
>
> 2. VPN tunnels are established to each Cloud Firewall instance from the branch office or on-premises datacenter.
>
> 3. Route-based VPN uses virtual tunnel interfaces (VTIs) for secure routing. Traffic flows through VPN tunnels based on destination IP addresses. VTIs are essential for creating dynamic and scalable VPN configurations. In our design, we use BGP for advanced traffic control and failover scenarios.
>
> 4. Active/Standby setup uses BGP AS-prepending to prioritize the active link by increasing the AS path length of the standby link. The longer AS path makes the standby link's routes less preferred. Traffic flows through the active link and switches to the standby link only if the active link fails and the active path becomes unavailable, ensuring seamless failover.
>
> 5. BGP monitors the link health with keepalive messages and hold timers to make sure the connection remains active. In a 10/30 configuration, the router sends a keepalive message every 10 seconds, and if no response is received within the 30-second hold timer, the session is terminated. This mechanism provides a reliable way to detect link failures while balancing network overhead.
>
> 6. BGP route maps let you control and manipulate routing decisions by matching specific prefixes or AS paths and applying actions like permitting, denying, or changing route attributes. This allows precise control of routing policies and traffic between connected sites by influencing which routes are advertised, accepted, or preferred.
>
> |---------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|
> | **Single Region Design**  | **Multi-Region Design**  |
>
> **Considerations:**
>
> * The public IP addresses for Cloud Firewall instances in Virtual WAN are not preserved. If the managed application is deleted, these IP addresses are lost.
>
> **Logical Configuration Steps:**
>
> 
> **Lab Network Diagram:**
>
> 
>
> ### Procedure
>
> * **Step 1 - Make sure to have the required permissions and roles**
> > * Read/Write access to Smart Console or Smart-1 Cloud
> > * Read/Write access to Cloud Firewall for Virtual WAN NVA instances
> > * Access to the ?zure Portal
> * **Step 2 - Gather the necessary network information**
> > The values in this table are used as an example (except for the Virtual WAN BGP ASN default value). You must change them according to your environment settings.
> >
> > |------------------------------------------------|----------------------|-----------------|
> > | VPN Detail | Key | Value |
> > | Virtual WAN Cloud Firewall Gateway: `` | Public IP | \<1.1.1.1\> |
> > | Virtual WAN Cloud Firewall Gateway: `` | VTI IP | \<172.17.0.1\> |
> > | Virtual WAN Cloud Firewall Gateway: `` | Public IP | \<1.1.1.2\> |
> > | Virtual WAN Cloud Firewall Gateway: `` | VTI IP | \<172.17.0.2\> |
> > | Branch Gateway: `` | Public IP | \<1.1.1.3\> |
> > | Branch Gateway: `` | VTI IP 1 | \<172.17.0.3\> |
> > | Branch Gateway: `` | VTI IP 2 | \<172.17.0.4\> |
> > | BGP Information | vWAN CGNS ASN | \<64512\> |
> > | BGP Information | Branch ASN | \<64513\> |
> > | BGP Information | Import Routemap Name | \ |
> > | BGP Information | Export Routemap Name | \ |
> > | Virtual WAN BGP Information | vWAN BGP ASN | 65515 (default) |
> > | Virtual WAN BGP Information | vWAN BGP Peer IP 1 | \<10.1.0.68\> |
> > | Virtual WAN BGP Information | vWAN BGP Peer IP 2 | \<10.1.0.69\> |
> >
> > * The default Autonomous System Number (ASN) for Azure Virtual WAN hub is 65515 (this value is fixed and cannot be changed). This ASN is automatically assigned to the virtual hub router and used for BGP peering with on-premises devices and other networks.
> >
> > * Use ASN range 64512-65534 for Cloud Firewall (according to RFC6996). Default Cloud Firewall ASN is 64512.
> >
> > * The import route map name "`im_vpn`" and export route map name "`ex_vpn`" are used as examples. You can customize these names to align with your organization's naming conventions or specific use cases.
> >
> > * Customers who have deployed 30 or more scale units can use additional Cloud Firewall Gateways for redundancy. For each additional Cloud Firewall Gateway, configure `aspath-prepend-count [3-5]` to prioritize them as standby gateways. An Active/Standby setup is sufficient for most networks.
> >
> > * To get the Virtual WAN BGP Peer IP address, connect with SSH to `` or `` and run the "`show bgp peers`" Clish command:
> >
> > 
>
> * **Step 3 - Connect with SSH to \ (acts as active) to configure Route maps, VTI and BGP**
> > Values in angle brackets (\) are used as an example. You must change them according to your environment settings.
> > 1. Route map setup:
> >
> > `set routemap ex_azure id 100 on `
> > `set routemap ex_azure id 100 allow `
> > `set routemap ex_azure id 100 match as <64513> on`
> >
> > This enables route advertisement from VPN gateway to Virtual WAN.
> > ` set routemap id 100 on`
> > `
> > set routemap id 100 allow`
> > `
> > set routemap id 100 on`
> > `
> > set routemap id 100 allow`
> >
> > This accepts all routes from VPN and imports all advertised routes from VPN gateway.
> > **Note** - Route maps are ordered by ID for a specified Route Map, the match conditions under ID 100 take precedence, followed by ID 110, and so on.
> > 2. BGP configuration:
> >
> > `set bgp external remote-as <64513> on`
> > `set bgp external remote-as <64513> export-routemap preference 10 on`
> > `set bgp external remote-as <64513> import-routemap preference 10 on`
> > `set bgp external remote-as <64513> peer <172.17.0.3> on`
> > `set bgp external remote-as <64513> peer <172.17.0.3> multihop on`
> > `set bgp external remote-as <64513> peer <172.17.0.3> holdtime 30`
> > `set bgp external remote-as <64513> peer <172.17.0.3> keepalive 10`
> > `set bgp external remote-as <64513> peer <172.17.0.3> aspath-prepend-count 1`
> >
> > This tells the VPN gateway to use this gateway as ACTIVE link by setting the prepend of "1".
> >
> > `set bgp external remote-as 65515 peer <10.1.0.68> aspath-prepend-count 1`
> > `set bgp external remote-as 65515 peer <10.1.0.69> aspath-prepend-count 1`
> >
> > This tells Virtual WAN to use this gateway as ACTIVE link to the VPN gateway or any routes advertised by this gateway with prepend of "1".
> >
> > 3. VTI setup:
> >
> > `add vpn tunnel 1 type numbered local <172.17.0.1> remote <172.17.0.3> peer `
> > `set interface vpnt1 state on`
> > `save config`
> >
> > **Note** - Make sure to run "`save config`" to make the changes persistent.
> * **Step 4 - Connect with SSH to \ (acts as standby) to configure Route maps, VTI and BGP**
> > Values in angle brackets (\) are used as an example. You must change them according to your environment settings.
> > 1. Route map setup:
> >
> > `set routemap ex_azure id 100 on `
> > `set routemap ex_azure id 100 allow `
> > `set routemap ex_azure id 100 match as <64513> on`
> >
> > This enables route advertisement from VPN gateway to Virtual WAN.
> >
> > `set routemap id 100 on`
> > `set routemap id 100 allow`
> > `set routemap id 100 on`
> > `set routemap id 100 allow`
> >
> > This accepts all routes from VPN and imports all advertised routes from VPN gateway.
> >
> > **Note** - Route maps are ordered by ID for a specified Route Map, the match conditions under ID 100 take precedence, followed by ID 110, and so on.
> >
> > 2. BGP configuration:
> >
> > `set bgp external remote-as <64513> on`
> > `set bgp external remote-as <64513> export-routemap preference 10 on`
> > `set bgp external remote-as <64513> import-routemap preference 10 on`
> > `set bgp external remote-as <64513> peer <172.17.0.4> on`
> > `set bgp external remote-as <64513> peer <172.17.0.4> multihop on`
> > `set bgp external remote-as <64513> peer <172.17.0.4> holdtime 30`
> > `set bgp external remote-as <64513> peer <172.17.0.4> keepalive 10`
> > `set bgp external remote-as <64513> peer <172.17.0.4> aspath-prepend-count 2`
> >
> > This tells the VPN gateway to use this gateway as STANDBY link by setting the prepend of "2".
> >
> > `set bgp external remote-as 65515 peer <10.1.0.68> aspath-prepend-count 2`
> > `set bgp external remote-as 65515 peer <10.1.0.69> aspath-prepend-count 2`
> >
> > This tells Virtual WAN to use this gateway as STANDBY link to the VPN gateway or any routes advertised by this gateway with prepend of "2".
> >
> > 3. VTI setup:
> >
> > `add vpn tunnel 1 type numbered local <172.17.0.2> remote <172.17.0.4> peer `
> > `set interface vpnt1 state on`
> > `save config`
> >
> > **Note** - Make sure to run "save config" to make the changes persistent.
> * **Step 5 - (Optional) Configure Route maps, VTI and BGP on additional standby members**
> Follow instructions from Step 4, but for each additional Cloud Firewall Gateway, configure `aspath-prepend-count [3-5]` to prioritize them as standby gateways.
> * **Step 6 - Connect with SSH to Branch VPN gateway to configure Route maps, VTI and BGP**
> > Values in angle brackets (\) are used as an example. You must change them according to your environment settings.
> > 1. Export Route map:
> >
> > `set routemap id 100 on`
> > `set routemap id 100 allow`
> > `set routemap id 100 match network <10.20.1.0/24> exact`
> > `set routemap id 100 match protocol static`
> >
> > Import Route map:
> >
> > `set routemap id 100 on`
> > `set routemap id 100 allow`
> >
> > **Note** - Route maps are ordered by ID for a specified Route Map, the match conditions under ID 100 take precedence, followed by ID 110, and so on.
> >
> > 2. BGP configuration:
> >
> > `set as <64513>`
> > `set router-id <172.17.0.3> `
> > `set bgp external remote-as <64512> on`
> > `set bgp external remote-as <64512> export-routemap preference 10 on`
> > `set bgp external remote-as <64512> import-routemap preference 10 on`
> >
> > `set bgp external remote-as <64512> peer <172.17.0.1> on`
> > `set bgp external remote-as <64512> peer <172.17.0.1> multihop on`
> > `set bgp external remote-as <64512> peer <172.17.0.1> holdtime 30`
> > `set bgp external remote-as <64512> peer <172.17.0.1> keepalive 10`
> >
> > `set bgp external remote-as <64512> peer <172.17.0.2> on`
> > `set bgp external remote-as <64512> peer <172.17.0.2> multihop on`
> > `set bgp external remote-as <64512> peer <172.17.0.2> holdtime 30`
> > `set bgp external remote-as <64512> peer <172.17.0.2> keepalive 10`
> >
> > `add vpn tunnel 1 type numbered local <172.17.0.3> remote <172.17.0.1> peer `
> > `set interface vpnt1 state on`
> > `set interface vpnt1 mtu 1500`
> >
> > `add vpn tunnel 2 type numbered local <172.17.0.4> remote <172.17.0.2> peer `
> > `set interface vpnt2 state on`
> > `set interface vpnt2 mtu 1500`
> > `save config`
> >
> > **Note** - Make sure to run "save config" to make the changes persistent.
> * **Step 7 - Configure Site-to-Site VPN in SmartConsole and apply the necessary access control and NAT rules**
> > 1. Open SmartConsole.
> > 2. Create the Branch Office VPN Gateway Object:
> > 1. If the gateway is externally managed, create an Interoperable Device to represent the Branch Office VPN Gateway and skip to step 3 in this section.
> >
> > For that, in the **Object Explorer** , click **New \> More \> Network Object \> More \> Interoperable Device**.
> > 
> >
> > 
> >
> > See the [R82 Site to Site VPN Administration Guide](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SitetoSiteVPN_AdminGuide/Content/Topics-VPNSG/VPN-with-External-Gateways.htm?Highlight=interoperable%20device) for more information.
> > 2. If the gateway is locally managed, repeat the same configuration steps as in the Cloud Firewall for Virtual WAN Gateway objects by making sure the IPSec VPN blade is enabled.
> >
> > 
> > 3. Retrieve interface topology. The Virtual Tunnel Interfaces (VTIs) are displayed here.
> >
> > 
> > 4. Disable anti-spoofing on all interfaces, including the new VTI interfaces.
> >
> > 5. Under **IPSEC VPN** \> **Link Selection** , set **Statically NATed IP** to instance PIP (this is only required if the gateway is installed in public cloud provider).
> >
> > 
> >
> >
> >
> >
> >
> > 3. Configure the NVA instances:
> > 1. Make sure the IPSec VPN blades are enabled:
> >
> > 
> > 2. Select "Get Interfaces". The VTI are displayed here:
> >
> > 
> >
> > **Note** - Make sure VPN gateway names match the name exactly as used in VTI interface creation and SmartConsole. Otherwise, the VTI Connection won't come up correctly.
> >
> > 3. Disable Anti-Spoofing on all interfaces, including the new VTI interfaces.
> >
> > 4. Under **IPSec VPN** \> **Link Selection** , set **Statically NATed IP** to instance PIP.
> >
> > 
> >
> > **Repeat the process for each Cloud Firewall for Virtual WAN NVA instance.**
> > 4. Create an Empty Network Group:
> >
> > 1. In SmartConsole, click **New** \> **Network Group**.
> >
> > 2. Enter a **Name**.
> >
> > 3. Click **OK**. (Leave this Group object empty.)
> >
> > In the example below, we use "empty-group" as a name.
> > 
> >
> > **Note** - This empty network group is used for our encryption domain. We can specify the empty encryption domain in both the gateway topology and VPN community.
> >
> > 5. Create Network Groups for Branch subnets and Virtual WAN Subnets:
> > 1. Define a network group for Azure Virtual WAN subnets (for example, "vwan_subnets_grp").
> > 2. Define a network group for branch office subnets (for example, "branch_subnets_grp").
> > 3. Add the respective known subnets to each group.
> >
> >
> >
> >
> >
> > 6. Set the Security and NAT rules for VPN access:
> > 1. Rule 1 - for Cloud Firewall Gateway and VPN communication.
> > 2. Rule 2 - for access from VPN gateway subnets to VNet-1 subnets.
> > 
> > 3. Create a No NAT rule:
> > 
> >
> > **Note** - A No NAT rule is required to prevent NAT between the branch subnet and Virtual WAN subnet. To simplify management and avoid updating both the Virtual WAN and Branch network groups separately, customers can include all internal subnets into the No NAT rule.
> >
> > For example, configuring 10.0.0.0/8 in both the Original Source and Original Destination fields ensures internal traffic remains un-NATed.
> >
> >
> >
> >
> >
> > 7. Create a VPN Community:
> > 1. Set the Cloud Firewall for Virtual WAN gateways as Center Gateways.
> >
> > 
> > 2. In the Tunnel Management section, enable **Set Permanent Tunnels** .
> >
> > 
> >
> > **Note** - To optimize VPN performance, it is recommended to create "One VPN tunnel per subnet pair".
> >
> > 3. Push the Policy.
> * **Step 8 - Test and Validation**
> > 1. Verify that the VPN is up and running by using the `vpn tu` command.
> >
> > 
> > 2. Verify that the BGP connections are up by using the `show bgp peers` command:
> >
> > 
> > 3. Check learned BGP routes by using the `show bgp peers adj-rib-in` command:
> >
> > 
> > 4. Export BGP routes by using the `show bgp peers adj-rib-out` command:
> >
> > 
> >
> > **BGP Route map examples:**
> >
> > Values in angle brackets (\) are used as an example. You must change them according to your environment settings.
> > 1. This route map example advertises the directly connected network on the interface eth1 with the network of \<10.21.1.0/24\> to Virtual WAN:
> >
> > `set routemap id 100 on`
> > `set routemap id 100 allow`
> > `set routemap id 100 match network <10.21.1.0/24> exact`
> > `set routemap id 100 match protocol direct`
> > 2. This route map example advertises the static route of \<192.168.21.0/24\> to Virtual WAN:
> >
> > `set routemap id 110 on`
> > `set routemap id 110 allow`
> > `set routemap id 110 match network <192.168.21.0/24> exact`
> > `set routemap id 110 match protocol static `
> >
> > **Note** - Route maps are ordered by ID for a specified Route Map, the match conditions under ID 100 take precedence, followed by ID 110, and so on.
> >
> > **Troubleshooting:**
> > * BGP debug file is located at `/var/log/routed_messages`.
### Domain-based VPN {#TARGET_ID_2}
Show / Hide this section
> A domain-based VPN connects on-premises networks to Azure Virtual WAN through IPsec tunnels.
>
> While both domain-based and route-based VPNs offer reliable connectivity, domain-based VPNs use multiple CPU cores for encryption, enabling higher throughput for more demanding network environments.
>
> For detailed information about domain-based VPNs, see the Check Point [Site to Site VPN R82 Administration Guide](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SitetoSiteVPN_AdminGuide/Content/Topics-VPNSG/Domain-Based-VPN.htm?TocPath=Domain-Based%20VPN%7C_____0#Domain-Based_VPN) \> Domain-Based VPN.
>
> **System Components:**
>
> 1. Cloud Firewall for Azure Virtual WAN instances operate as standalone gateways. These gateways cluster through an internal load balancer. The gateways operate independently without state synchronization.
>
> 2. VPN tunnels connect from branch offices or on-premise datacenters to each Cloud Firewall instance.
>
> 3. Multiple Entry Point (MEP) provides high availability for VPN connections. The VPN module installs on a Cloud Firewall Gateway that serves as the entry point to the internal network. If this Cloud Firewall Gateway becomes unavailable, peer Cloud Firewall Gateways cannot access the internal network.
>
> 4. Route Injection Mechanism (RIM) allows Cloud Firewall Gateways to use dynamic routing protocols to propagate the encryption domain of a VPN peer Cloud Firewall Gateway to the internal network. When a VPN tunnel is created, RIM updates the local routing table of the Cloud Firewall Gateway to include the encryption domain of the VPN peer.
>
> 5. BGP monitors link health with keepalive and hold timers to make sure the connection remains active. In a 10/30 configuration, the router sends a keepalive message every 10 seconds. The session terminates if no response is received within the 30-second hold timer. This mechanism provides a reliable way to detect link failures while balancing network overhead.
>
> 6. Active/Standby setup uses BGP AS-prepending to prioritize the active link by increasing the AS path length of the standby link. The longer AS path makes the standby link's routes less preferred. Traffic flows through the active link and switches to the standby link only if the active link fails and the active path becomes unavailable, ensuring seamless failover.
>
> 7. BGP route maps let you control and manipulate routing decisions by matching specific prefixes or AS paths and applying actions like permitting, denying, or changing route attributes. This allows precise control of routing policies and traffic between connected sites by influencing which routes are advertised, accepted, or preferred.
>
> |----------------------------------------------------------------------------------------------------------------------------------------|
> | **Single Region Design**  |
>
>
>
> **Considerations:**
>
> * The public IP addresses for Cloud Firewall instances in Virtual WAN are not preserved. If the managed application is deleted, these IP addresses are lost.
> * For dynamic routing, use a route-based VPN to Cloud Firewall for Azure Virtual WAN.
> * Multi-Entry Point (MEP) supports up to three gateways for redundancy (see the [Site to Site VPN Administration Guide](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SitetoSiteVPN_AdminGuide/Content/Topics-VPNSG/MEP.htm?TocPath=Multiple%20Entry%20Point%20(MEP)%20VPNs%7C_____0#MEP_Selection_Modes_Manually_Set_Priority_List) for more information).
>
> **Lab Network Diagram:**
>
> 
>
> ### Procedure
>
> * **Step 1 - Make sure to have the required permissions and roles**
> > * Read/Write access to SmartConsole or Smart-1 Cloud
> > * Read/Write access to CloudGuard Network Security for Virtual WAN NVA instances
> > * Access to the ?zure Portal
> * **Step 2 - Gather the necessary network information**
> > The values in this table are used as an example (except for the Virtual WAN BGP ASN default value). You must change them according to your environment settings.
> >
> > |------------------------------------------------|----------------------------|-----------------------------------|
> > | VPN Detail | Key | Value |
> > | Virtual WAN Cloud Firewall Gateway: `` | Public IP | \<1.1.1.1\> |
> > | Virtual WAN Cloud Firewall Gateway: `` | Region 1 Encryption Domain | \<10.10.1.0/24\> \<10.10.2.0/24\> |
> > | Virtual WAN Cloud Firewall Gateway: `` | Public IP | \<1.1.1.2\> |
> > | Virtual WAN Cloud Firewall Gateway: `` | Region 1 Encryption Domain | \<10.10.1.0/24\> \<10.10.2.0/24\> |
> > | Branch Gateway: `` | Public IP | \<1.1.1.3\> |
> > | Branch Gateway: `` | Branch Encryption Domain | \<10.20.1.0/24\> |
> > | Virtual WAN BGP Information | vWAN BGP ASN | 65515 (default) |
> > | Virtual WAN BGP Information | vWAN BGP Peer IP 1 | \<10.1.0.68\> |
> > | Virtual WAN BGP Information | vWAN BGP Peer IP 2 | \<10.1.0.69\> |
> >
> > * The default Autonomous System Number (ASN) for Azure Virtual WAN hub is 65515 (this value is fixed and cannot be changed). This ASN is automatically assigned to the virtual hub router and used for BGP peering with on-premises devices and other networks.
> >
> > * Customers who have deployed 30 or more scale units can use additional Cloud Firewall gateways for redundancy. For each additional Cloud Firewall gateway, configure `aspath-prepend-count [3-5]` to prioritize them as standby gateways. An Active/Standby setup is sufficient for most networks.
> > * To get the Virtual WAN BGP Peer IP address, connect with SSH to `` or `` and run the "`show bgp peers`" Clish command:
> >
> > 
>
> * **Step 3 - Connect with SSH to \ (acts as active) to configure route maps and enable kernel routes**
> > 1. Enable kernel routes:
> >
> > `set kernel-routes on`
> > 2. Set up route map:
> >
> > `set routemap ex_azure id 100 on `
> > `set routemap ex_azure id 100 allow `
> > `set routemap ex_azure id 100 network 10.20.1.0/24 exact`
> > `set routemap ex_azure id 100 match protocol kernel`
> > `set routemap ex_azure id 100 action aspath-prepend-count 1`
> >
> > This tells Virtual WAN BGP Endpoints to use this gateway as the ACTIVE link by setting the prepend of "1".
> > **Note** - Match network of 10.20.1.0/24 makes sure only remote encryption domain IP address range is advertised to Virtual WAN.
> > 3. Modify BGP Hold time to Virtual WAN BGP Endpoints (Optional):
> >
> > `set bgp external remote-as 65515 peer 10.1.0.68 holdtime 30`
> > `set bgp external remote-as 65515 peer 10.1.0.68 keepalive 10`
> > `set bgp external remote-as 65515 peer 10.1.0.69 holdtime 30`
> > `set bgp external remote-as 65515 peer 10.1.0.69 keepalive 10`
> >
> > **Note** - Reduce the default keepalive and hold timers from 60/180 to 10/30 to improve VPN failover speed and minimize asymmetrical routing issues. While 60/180 provides greater resilience to temporary disruptions, lowering the timers allows for faster failure detection and recovery, ensuring a more responsive and reliable VPN failover mechanism.
> >
> > **Note** - Make sure to run "`save config`" to make the changes persistent.
> * **Step 4 - Connect with SSH to \ (acts as standby) to configure route maps and enable kernel routes**
> > 1. Enable kernel routes:
> >
> > `set kernel-routes on`
> > 2. Set up route map:
> >
> > `set routemap ex_azure id 100 on `
> > `set routemap ex_azure id 100 allow `
> > `set routemap ex_azure id 100 match network 10.20.1.0/24 exact`
> > `set routemap ex_azure id 100 match protocol kernel`
> > `set routemap ex_azure id 100 action aspath-prepend-count 2`
> >
> > This tells Virtual WAN BGP Endpoints to use this gateway as the STANDBY link by setting the prepend of "2".
> >
> > **Note** - Match network of 10.20.1.0/24 makes sure only remote encryption domain IP address range is advertised to Virtual WAN.
> >
> > 3. Modify BGP Hold time to Virtual WAN BGP Endpoints (Optional):
> >
> > `set bgp external remote-as 65515 peer 10.1.0.68 holdtime 30`
> > `set bgp external remote-as 65515 peer 10.1.0.68 keepalive 10`
> > `set bgp external remote-as 65515 peer 10.1.0.69 holdtime 30`
> > `set bgp external remote-as 65515 peer 10.1.0.69 keepalive 10`
> >
> > **Note** - Reduce the default values of keepalive and hold timers from 60/180 to 10/30 to improve VPN failover speed and minimize asymmetrical routing issues. While 60/180 provides greater resilience to temporary disruptions, lowering the timers allows for faster failure detection and recovery, ensuring a more responsive and reliable VPN failover mechanism.
> >
> > **Note** - Make sure to run "`save config`" to make the changes persistent.
> * **Step 5 - Configure Cloud Firewall and Branch Gateways in SmartConsole**
> > 1. Open SmartConsole.
> >
> > 2. Create the Branch Gateway Encryption Domain.
> >
> > 
> > 3. Create the Virtual WAN Region Encryption Domain.
> >
> > 
> > 4. Create an Empty Network Group:
> >
> > 1. In SmartConsole, click **New** \> **Network Group**.
> >
> > 2. Enter a **Name**.
> >
> > 3. Click **OK**. (Leave this Group object empty.)
> >
> > In the example below, we use "empty-group" as a name.
> > 
> >
> > **Note** - This empty network group is used for our encryption domain for each participating gateway. We can specify the empty encryption domain in both the gateway topology and VPN community.
> > 5. Create the Remote Branch Office VPN Gateway Object:
> > 1. If the gateway is externally managed, create an Interoperable Device to represent the Remote Branch Office VPN Gateway and skip to step 3 in this section.
> >
> > For that, in the **Object Explorer** , click **New \> More \> Network Object \> More \> Interoperable Device**.
> > 
> >
> > 
> >
> > See the [R82 Site to Site VPN Administration Guide](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SitetoSiteVPN_AdminGuide/Content/Topics-VPNSG/VPN-with-External-Gateways.htm?Highlight=interoperable%20device) for more information.
> > 2. If the gateway is locally managed, make sure the IPSec VPN blade is enabled.
> >
> > 
> >
> > 3. Under **IPSEC VPN** \> **Link Selection** , set **Statically NATed IP** to instance PIP (this is only required if the gateway is installed in public cloud provider).
> >
> > 
> >
> > 4. Set the VPN Domain to empty-group.
> >
> > 
> >
> > 5. Click **OK** to save the configuration for the Remote Branch Office VPN Gateway Object.
> >
> >
> >
> >
> >
> > 6. Configure the Cloud Firewall for vWAN NVA instances:
> > 1. Make sure the IPSec VPN blades are enabled:
> >
> > 
> > 2. Under **IPSec VPN** \> **Link Selection** , set **Statically NATed IP** to instance PIP.
> >
> > 
> > 3. Set the VPN Domain to empty-group.
> >
> > 
> >
> > **Repeat the process for each Cloud Firewall for Virtual WAN NVA instance.**
> * **Step 6 - Set up access control rules and configure the VPN Community in SmartConsole**
> > 1. Open SmartConsole.
> >
> > 2. Enable the **RIM_inject_peer_interfaces** flag in Global Properties.
> > 
> >
> > 
> > 3. Create Network Groups for Branch subnets and Virtual WAN Subnets:
> > 1. Define a network group for Azure Virtual WAN subnets (for example, "vwan_subnets_grp").
> > 2. Define a network group for branch office subnets (for example, "branch_subnets_grp").
> > 3. Add the respective known subnets to each group.
> > 4. Set the Security and NAT rules for VPN access:
> > 1. Rule 1 - for Cloud Firewall Gateway and VPN communication.
> > 2. Rule 2 - for access from VPN gateway subnets to VNet-1 subnets.
> > 
> > 3. Create a No NAT rule:
> > 
> >
> > **Note** - A No NAT rule is required to prevent NAT between the branch subnet and Virtual WAN subnet. To simplify management and avoid updating both the Virtual WAN and Branch network groups separately, customers can include all internal subnets into the No NAT rule.
> >
> > For example, configuring 10.0.0.0/8 in both the Original Source and Original Destination fields ensures internal traffic remains not NATed.
> > 5. Create a VPN Community:
> > 1. Create a Star VPN Community
> >
> > * Set the Cloud Firewall for Virtual WAN gateways as Center Gateways.
> >
> > * Add the VPN Domain for Virtual WAN gateways.
> >
> > * Set the Branch VPN gateway as a Satellite Gateway.
> >
> > * Add the VPN Domain for the Branch Gateway.
> >
> > 
> > 2. Configure tunnels:
> >
> > * On the Tunnel Management tab, enable **Set Permanent Tunnels**.
> >
> > * In the **Set Permanent Tunnels** section, select **On all tunnels in the community**.
> >
> > * In the **VPN Tunnel Sharing** section, select **One VPN tunnel per subnet pair**.
> >
> > 
> > * Enable Route Injection Mechanism (RIM) for Center and Satellite Gateways.
> >
> > 
> > 3. Configure Multiple Entry Points (MEP):
> >
> > * On the **MEP** tab, select **Enable center gateways as MEP**.
> >
> > 
> > * Select **Manually set priority list** and click **Set**.
> >
> > 
> >
> > **Note** - For the active Cloud Firewall Gateway, set BGP prepending to 1. For the standby Cloud Firewall Gateway, set prepending to 2. The MEP priority list must be manually defined to align with the BGP prepending values of 1 and 2 (see the [Site to Site VPN Administration Guide](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SitetoSiteVPN_AdminGuide/Content/Topics-VPNSG/MEP.htm?TocPath=Multiple%20Entry%20Point%20(MEP)%20VPNs%7C_____0#MEP_Selection_Modes_Manually_Set_Priority_List) for more information).
> > 4. Push the policy.
>
> * **Step 7 - Test and Validation**
> > 1. Verify that the VPN is up and running by using the `vpn tu` command.
> >
> > 
> > 2. Verify that the BGP connections to Virtual WAN BGP Endpoints are up by using the `show bgp peers` command:
> >
> > 
> > 3. Check routes from the active CGNS for vWAN gateway by using the `show route` command:
> >
> > 
> > 4. Export BGP routes by using the `show bgp peers adj-rib-out` command:
> >
> > 
> >
> > **Note** - Not all kernel routes are advertised because we use route map commands to make sure only branch encryption domain subnets are advertised to Virtual WAN BGP Endpoints.
> >
> > **Troubleshooting:**
> > * BGP debug file is located at `/var/log/routed_messages`.
---
# Agent Instructions
This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.
## Navigating This Knowledge Base
- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content