Site-to-Site BGP VPN to Azure on Check Point VSX (R81.20) – step-by-step guidance needed

[Tub92]

Hello everyone,

I’m looking for help configuring a Site-to-Site IPsec VPN with BGP between an on-prem environment and an Azure VPN Gateway, using Check Point VSX running R81.20.

🔹 General scenario

Firewall: Check Point VSX – R81.20

Environment: two separate VSX deployments

• Primary site
• Disaster Recovery site

Azure side: Azure VPN Gateway with BGP enabled

VPN type: S2S IPsec + BGP

🔹 VSX details

Each VSX hosts multiple Virtual Systems

The new VPN must be configured inside an existing VS context

In the same VS, there is already another working BGP S2S VPN

That existing BGP VPN was:

• originally created on a non-VSX firewall
• later migrated via CLI, without a full SmartConsole-based configuration

Therefore, I have no direct experience configuring a full BGP VPN natively inside VSX from scratch.

🔹 Objective

Create a new S2S BGP VPN to Azure

Configure it on both Primary and DR VSX sites

Ensure that all traffic prefers the Primary site

DR site must be used only in case of failure

I need guidance on:

• Proper IPsec + BGP configuration on VSX
• Route redistribution and traffic preference
• Avoiding unwanted active/active routing

🔹 Specific questions

I’m looking for a step-by-step guide covering:

IPsec S2S VPN configuration on VSX (SmartConsole and/or CLI)

BGP configuration inside a Virtual System:

• AS numbers
• Correct interfaces (VTI / interface-based VPN)

Best practices for:

• Route redistribution (static ↔ BGP)
• Primary site preference (BGP metrics, AS-PATH, MED, Local Preference, etc.)

Proper handling of:

• Dual tunnels (Primary + DR)
• Clean failover without asymmetric routing

Any VSX-specific limitations or considerations in R81.20

Any real-world examples, official documentation references, or design recommendations would be greatly appreciated.

Thank you in advance!

[the_rock]

Let me look for it, Im sure I have something. 

[the_rock]

@Tub92 

See if this helps. Btw, I do have bunch of screenshots and doc for P81 BGP setup, but cant send it, as it has client confidential info (sorry), but happy to answer any questions you may have.

https://community.checkpoint.com/t5/Security-Gateways/Route-based-VPN-tunnel-to-Azure/m-p/206179/emc...

[Chris_Atkinson]

Note the ask is for VSX which differs in configuring the VTI portion etc, for example:

https://community.checkpoint.com/t5/Security-Gateways/VPN-SITE-TO-SITE-CHECKPOINT-VSX-ROUTE-BASED/td... 

[Tub92]

Thank you for your responses.

I can confirm that I cannot follow the first configuration approach, as it needs to be performed within a VSX environment. I have reviewed the documentation related to the vsx_provisioning_tool, but I still have a few concerns.

On the management server, I have both VSX environments connected (production and DR). However, the VS IDs are different between the two environments. For this reason, I am hesitant to use the provisioning tool, as I am concerned it might apply unintended configurations to different VS instances.

Is it possible to perform this configuration directly from the CLI on each individual gateway? This approach would allow me to be as precise and controlled as possible.

[Chris_Atkinson]

The naming convention used in the example is likely throwing you off, refer to the admin guide e.g.

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_CLI_ReferenceGuide/Topics-CLIG/VSX...

[the_rock]

Never really tried it from cli, but Im sure it is possible. You would just need to run add vpn tunnel commands.

[Tub92]

I also believe that it should be sufficient to run the add vpn tunnel commands on each node and then save the configuration. I will try to proceed this way.

In your opinion, is it also necessary to retrieve the interfaces without topology from SmartConsole, or is this not required in this scenario?

[the_rock]

Personally, I always do that. Its good practise, just to be 100% sure there are no issues/misconfigs.

[the_rock]

@Tub92 Personally and again, this is just my own opinion, does not matter its something everyone should be doing, but I ALWAYS found best setting for topology is define network by routes option, as if network changes, its auto updated, just make sure you have correct routing and I also assign needed security zone as well. 

[the_rock]

Example from my lab. For VTI, PLEASE make sure that interoperable object name matches with what you put in interface settings, otherwise, even if one letter is missed or its upper instead of lower case, it will never work. By default, anti spoofing is always disabled on those interfaces, which is totally fine.

 

[the_rock]

I logged into one client's clustered master fw and below is what config for VTI would look like in clish. I also attached web UI config as well:

show interface vpnt9
state on
mac-addr Not configured
type vpnt
link-state not available
mtu 1500
auto-negotiation off
speed N/A
ipv6-autoconfig Not configured
monitor-mode Not configured
duplex N/A
link-speed Not configured
comments onprem-sase trunnel
vpn-tunnel-id 9
vpn-peer Vancouver-pop-1
vpn-local-address 169.254.255.11
vpn-remote-address 169.254.255.9
ipv4-address Not Configured
ipv6-address Not Configured
ipv6-local-link-address Not Configured

Statistics:
TX bytes:183 packets:3 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:0 packets:0 errors:0 dropped:0 overruns:0 frame:0

SD-WAN: Not Configured

Here is the key. Say remote side (Azure) is 169.254.1.50

one fw can be 169.254.1.51

2nd 169.254.1.52 and VIP can be .53, as long as its NOT used on remote side, super important.

HTH