Checkpoint to Azure Route based - guide

[Ryan_Ryan]

I had a bit of struggle to get this working initially, as Azure don't provide configs for Checkpoint and they operate a bit different to AWS route based VPN's. Sk101275 will give you about 20% of what you need, so I am writing this up in case it helps others.

Steps for Checkpoint cluster to Azure Route based vpn (based on R80.20)

In this config all traffic from Azure will be tunnelled to the Checkpoint.
The Checkpoint can be participating in other Policy Based / Domain based VPN's without impacting them

Azure Side

configure for "forced tunnelling mode"
Download the generic (IOS based) config

Checkpoint side

Open smartConsole

• Create a new interoperable device, choose a unique name and give it the Public IP of Azure. (eg. AZUREIP, 52.1.1.1)
• On topology tab, set manually defined topology, create a new simple group, with NO OBJECTS in it (ie an empty group)

Open the centre gateway, Click network management, Select VPN Domain, now you have two options:

• if you have no other VPN's and don't expect to ever need a policy based VPN, then add grp.empty as your encryption domain
• If you have existing policy based VPN's then open the current encryption domain group, inside that group add a new network object: network address: 0.0.0.0, net mask: 0.0.0.0
  
  

Under VPN communities, create new star VPN, name it, add your local gateway as the Center gateway, and the new interoperable device as the satellite gateway (eg AZUREIP)

Encryption tab:
Method- Prefer Ikev2, support Ikev1
Encryption suite - Custom

• Phase 1: AES-256, SHA256, Group2
• Phase 2: AES-256, SHA256
  (everything else unticked)

Tunnel management: Select One VPN tunnel per gateway pair

VPN Routing: select "To center, through center, Internet and other VPN targets"

Shared Secret: Add peer name (eg AZUREIP) and the PSK provided in config file

Advanced Tab -

• Phase 1: 480
• Phase 2: 3600

Create VPN tunnel interfaces (VTI)

SSH to your gateways and enter clish

(Find the "int tunnel 11 ip address" it is a 169.254 address with a /30 mask in the Azure provided config)

The IP address listed (eg 169.254.0.1) will be your VIP, we need to extend that mask to /29 which gives more usable addresses

eg:
169.254.0.1 = VIP
169.254.0.2 = FW A
169.254.0.3 = FW B

(peer name must be exactly the same as interoperable device name in GUI, remote IP is the public IP of the interoperable device)

A: add vpn tunnel 11 type numbered local 169.254.0.2 remote 52.1.1.1 peer AZUREIP
A: set interface vpnt11 mtu 1350
A: save config

B: add vpn tunnel 11 type numbered local 169.254.0.3 remote 52.1.1.1 peer AZUREIP
B: set interface vpnt11 mtu 1350
B: save config

Add statics routes for your Azure CIDR via the new VPN interface
eg:

A: set static-route 192.168.55.0/24 nexthop gateway logical vpnt11 on
A: save config

B: set static-route 192.168.55.0/24 nexthop gateway logical vpnt11 on
B: save config

Get topology and assign VIP

Ensure that you have enabled the IPsec VPN blade on your gateway.
Open your gateway or cluster object, and choose "Network Management"
Choose "Get Interfaces without toplogy" - but sure not to select WITH!

Locate new vpn interface, add virtual IP (our local 169.254 address eg 169.254.0.1/29)
Under topology, select "leads to, override, specific" create a new group, add your Azure CIDR, your 169.254.x.x/29 subnet and your Azure Interoperable device to this group)
Enable antispoofing as desired

In checkpoint global properties, select VPN, advanced, at the bottom tick "enable VPN directional match)

Firewall Rules

Create firewall rules as required
In VPN column right click and add "Directional match condition" for each rule add three match conditions as follows:
Internal clear => AZURE-VPN-COMMUNITY
AZURE-VPN-COMMUNITY => AZURE-VPN-COMMUNITY
AZURE-VPN-COMMUNITY=> Internal_clear

Install policy

[miguel]

Thanks for putting this out there, however there's a catch with this that you would only come across when trying to do BGP peering across this IPsec VTI.

Don't follow this guidance:

(peer name must be exactly the same as interoperable device name in GUI, remote IP is the public IP of the interoperable device)

A: add vpn tunnel 11 type numbered local 169.254.0.2 remote 52.1.1.1 peer AZUREIP

remote 52.1.1.1 is wrong

It should be the BGP peer that you want to establish neighborship with on the other side of the tunnel (a Private IP (BGP Peer) given to you within the GatewaySubnet). If you use the public IP you can't establish BGP Peering. You'll get this error in routed.log 

bgp_check_invalid_nexthop(7086): 10.0.1.254 (External AS 65515) Route 10.0 rtn_gateway[0] Nexthop 0.0.0.0 is unspecified

If your Vnet CIDR is 10.0.0.0/16 and your GatewaySubnet is 10.0.1.0/24, and you aren't doing Active-Active VPN tunnels/BGP peering with Azure, then they'll give you 10.0.1.254 to peer with, and your config should be:

A: add vpn tunnel 11 type numbered local 169.254.0.2 remote 10.0.1.254 peer AZUREIP

If you are doing Active-Active, they'll give you 10.0.1.4 and 10.0.1.5 (in this example).

Also, under the Interoperable Gateway object > Topology tab > add the internal IP (BGP Peer IP) in there: 10.0.1.254/32 (or in Active-Active, both .4 and .5)

[mdjmcnally]

Interesting that you are using numbered VTI with Azure as always had to use UnNumbered and then use the External Interface as the Proxy IP for the VTI interface to do route based VPN.

All I bother with for Azure is the External IP and is it Static or Dynamic and that tells me which settings to use.

Has Azure changed to use Numbered VTI now as previously always had to use UnNumbered for Azure and Numbered for AWS.

[CheckPointerXL]

Hello, which Is the functional difference between numbered and unnumbered? Why some Cloud provider needs unnumbered?

[xiro]

Hi Ryan,

many thanks for the guide.

I just have one question - is there a need to specify the local encryption domain with 0.0.0.0/0 explicitly, or is our currently defined group with all relevant local subnets also fine?

Thanks!

[PhoneBoy]

If you're using route-based VPNs, you generally explicitly set the encryption domain to be 0.0.0.0/0.

[xiro]

But we have also multiple policy-based VPNs (15) and need to change one of them now to route based (Azure - Microsoft Support recommendation).
I'm not sure what the side effects for the other VPNs would be, if we change the enc domain.

I know that we had some pain to get everything working there properly, because of tunnel-to-tunnel communication, some issues with routing to the tunnels and issues with unencrypted communication to the remote site, where we had to edit the crypt.def exclusions.

Now it's running properly, but it's a fragile construct - if the 0.0.0.0/0 is not mandatory, we would prefer not to use it.

But if it is mandatory, then we'll have to schedule a maintenance window at night and try to change this and resolve the possible unwanted side-effects.

[PhoneBoy]

If you're doing route-based VPNs and domain-based VPNs, see: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Matlu]

Hello,

If you have several domain-based VPNs, and you need to create a new route-based VPN (either using static routes or BGP)

How to work the local encryption domain (From the Check Point point of view)

In the "VPN DOMAIN" of my Cluster, I would just have to add a new network object "calling" the 0.0.0.0.0/0, I would understand that this way, it would work fine?

Is this correct?

[the_rock]

I know this is an old post, but I just wanted to share my experience...followed CP guide for route based vpn, sk for cp to azure vpn config, tried permanent tunnel, no luck...oddly enough, when you disable option for permanent tunnel, CP side shows tunnel as up, but on azure side, its very intermittent. If you enable permanent tunnel setting, tunnel never comes up no matter what you do...we followed VTI settings to exactly what guide advised, but no luck. Any ideas? WE would like to make this work as permanent tunnel if at all possible.

[hemh]

Hi Ryan, I am also in the situation where I must make communicate an Azure non-checkpoint environment with our on prem main checkpoint cluster gateway. We are on a 80.40 environment

So I followed your guide and I never succeeded in making it work. The IPSec VPN works, but no way to bring BGP up.

About this portion:

"Locate new vpn interface, add virtual IP (our local 169.254 address eg 169.254.0.1/29)
Under topology, select "leads to, override, specific" create a new group, add your Azure CIDR, your 169.254.x.x/29 subnet and your Azure Interoperable device to this group)
Enable antispoofing as desired"

When configuring VPNT1 cluster interface, there no other option than /32. Then as soon as I modified according to guide, BGP peering came UP, but as soon as I pushed the Policy, the tunnel came DOWN because the interoperable object is declared to be on the VTI, so all IPSec traffic coming from Azure public IP was drop due to antispoofing on external interfaces. So on external interfaces I configured to not perform antispoofing on Azure public IP, the the tunnel came back UP. Also I had to desacivate antispoofing on VTI interface, because you cannot define a specific group for VTI traffic and in the same time exclude a network from antispoofing, it is one or the other but not both in the same time. So it work when deactivating antispoofing but is not very safe. I never succedded when configuring Azure connexions to point to on prem CKP cluster VTI Vip(169.254.0.1 in your guide). When I configure Azure connexion to point to active on prem cluster member(169.254.0.2 in your guide), sometimes I can have BGP peering working but it is unstable.

Other point, I did not activate 'enable VPN directional match' option in gloabal properties, I managed to making Azure vpn community comunicate with our meshed communities by playing with custom encryption domain in the 'Gateway' tab, and in my meshed community, I applied a custom encryption domain group containing my main gateway encryption domain + Azure encryption domain, so other gateway nows that Azure is behind my main gateway, and traffic from Azure community to meshed community is not dropped anymore with the log 'encryption failure'

I really don't understand why I cannot have a steady BGP peering on the cluster. I can ping Azure BGP ip flawlessly, if I telnet it on port 179, I get a connexion closed by remote host so it means the port is reachable. I got a standalone lab gateway and really the peering is steady since many days. It is really with a cluster that things going bad.

[the_rock]

We always followed below and never had an issue.

https://support.checkpoint.com/results/sk/sk100726

I could send you good doc my colleague put together for this, but it had client info, so would need to redact that first.

Andy

[Matlu]

Hey, my friend.

Do you have this manual available?

For building the right way for this type of VPN?

I have some pending implementations to do and I would like to take a look at your manual.

Cheers.

[the_rock]

I have real good steps my colleague and I wrote down when doing this for the customer back in 2021. It literally has everything you need to do on Azure and CP side. I can email it to you directly tomorrow.

In the meantime, check out below post where I gave some steps to Aaron.

Andy

https://community.checkpoint.com/t5/Security-Gateways/Route-based-VPN-failover-issue/m-p/155553#M265...

[the_rock]

Hey bro,

Emailed you some steps we compiled together, so you have an idea.

Andy

[jperks]

Would be super appreciated if you would be willing to send me your compiled steps. Thanks in advance. --Josh

[the_rock]

Email me directly and I can.

[the_rock]

I am sending this, rough steps, cant send you actual doc, sorry : - (

Andy

***************************************

VPN CONFIG EXAMPLE:

Steps to build the route based VPN tunnel

Azure portal:

 Create new VNG

SK Basic (100 Mbps Limit)

Route Based

No BGP/Active to Active (because basic SK)

New Resource Group

New VNET

               10.0.0.0/16

New Public IP

               VIP = x.x.x.x

            New Local Network Gateway (This is a reference object for the Checkpoint Cluster/Lab Checkpoint)
DEVCheckpoint

IP address: x.x.x.x

Address space: 172.16.10.0/24, x.x.x.x/x, 192.168.10.0/24 (Must include internal/local subnets and the external WAN facing subnets)

 Click , click Add Connection

Type: Site to Site

PSK Pleasework1!

IKEv2

 
Click the connection

Download Config (Cisco > IOS > IKEv2)

Verify Default Settings/VTI IPs

IKE aes-cbc-256, sha1, DH 2, SA lifetime 3600S

IPSec esp-aes 256, esp-sha256-hmac, SA lifetime 3600s, SA lifetime 102400000 KB

Configure an APIPA (169.254.x.x) address that does NOT overlap with any

!   other address on this device. This is not visible from the Azure gateway.

Local on Checkpoint Side VTI IP 169.254.0.1/32

Remote (Azure) 169.254.0.2/32

 If there is another tunnel use DIFFERENT IPs that DO NOT OVERLAP WITH PREVIOUS RouteBASED TUNNEL

-------

Access to Lab Checkpoint

SmartConsole x.x.x.x

 SmartConsole Settings

Global Properties > VPN > Advanced > Enable VPN Directional Match

Add Interoperable Object for Azure GW with configured VIP

"AzureLabGW"
Topology > VPN Domain > Add an Empty Group

Publish & Install

 Go to Gaia WebUi (172.16.10.189:4434)

Network Interface

Add VPN-Tunnel

vpnt1

Peer Name should be EXACT SAME AS INTEROPERABLE DEVICE NAME

Local IP 169.254.0.5 (Not used anywhere else)

Remote IP 169.254.0.6 (Not used anywhere else)

 Add Static Route

Local IP/Subnet of Azure GW (Virtual Network = 10.0.0.0/16)

Gateway (IP) of Remote IP from VTI configured previously (169.254.0.6)

 Go back to SmartConsole

Open Gateway Object/Cluster

Network Management > Topology > Get Interfaces WITHOUT Topology

Make sure VTI interface shows up, may need to set up vip obj for vpnt tunnel in cluster (make sure no overlap)

Install Policy

 Create a new VPN Community (Star Topology)

Ensure both gateways use an EMPTY group for domain

Encryption (IKEv2 Only)

               AES256, SHA1, Group2

               AES 256, SHA256

Tunnel Management

               Set perm tunnels on all tunnels in the community

               One tunnel per gateway pair

VPN Routing

               To center only

SharedSecret

               Pleasework1!

Advanced

               IKE Phase 1 480 Min

               IPSec Phase 2 27000 seconds

               Disable NAT inside VPN Community

Policies

Source & Destination

- Local Subnets included in the Local Gateway Object Config/Applicable Subnets

- Remote (AzureNetwork 10.0.0.0/16)

- RServ (Radius Server used for testing)

VPN > Directional Match

               Internal to Community

               Community to Internal

               Community to Community

Publish & Install

GUIDBEdit DPD Enabled (Tunnel Test Settings)

 Reset Connection on Azure Side

               MAY NOT BE NEEDED REFRESH AND CHECK IF CONNECTED

              Test

Create VM          LabUbuntu

VIP x.x.x.x

Private IP 10.0.0.4

Enable Rule to allow Pings & SSH traffic in

********************************************

[the_rock]

@jperks ...hope that helps a bit?

[the_rock]

@Ryan_Ryan As most folks on here know, you are welcome to message me directly with any questions you have. I always try my best to respond to every email I get.

Cheers mate and have a nice weekend...woohoo, weekend 🙂

 Best,

Andy