Checkpoint to Azure Route based - guide

Ryan_Ryan · ‎2019-08-12

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

PhoneBoy · ‎2019-08-13

Thanks for sharing this

miguel · ‎2019-11-14

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 · ‎2019-11-15

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.

xiro · ‎2020-08-05

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 · ‎2020-08-05

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

xiro · ‎2020-08-06

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 · ‎2020-08-07

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