VPN SITE TO SITE CHECKPOINT VSX ROUTE BASED

[aMatthew]

Hello everyone,
I will preface that I have been working with checkpoint technology for a short time and your input is valuable to me.

I need to set up a site to site VPN with Cisco secure access.

In the guide that was shared with us, it talks about creating VTI and policy based routing on Gaia portal.

Unfortunately, we do not have access to Gaia portal as our gateways are VSX. So the whole thing is to be done through CLI.

Referring to the guide (screenshots attached), could you kindly refer me what commands need to be run? I would be really happy if you could give me an example of the commands maybe using the IPs in the guide.

Thank you for your support.

[Duane_Toler]

You need vsx_provisioning_tool for VTIs on VSX:

vsx_provisioning_tool -L -o add interface vd VS1 vpn_tunnel numbered peer SmartConsole_interoperable_peer local 169.254.68.238 remote 169.254.68.237 tunnel_id 99

Replace VS1 with the name of your firewall Virtual System.

Replace "SmartConsole_interoperable_peer" with the name of the Interoperable Device in SmartConsole for this VPN peer.

This will create vpnt99  for your VS.  After this, you should be using Route Based VPN with empty group objects as the VPN domain for the remote peer and your VS.  You can override VPN domain for the peers within the VPN Community, rather than modifying the main VPN domain on the VS object.

You will also need to add static routes across the VTI for whatever remote end host they gave you.   You add static routes in SmartConsole for the firewall VS.  These are in the VS properties -> select Network Management on the left, and you'll see the where to add static routes.  Use the remote peer IP in the VTI as the next-hop gateway for the route (169.254.68.237 in this case).

You can replace those 169.254.x.y IPs in the VTI command above, but be sure you ONLY use IPs in the 169.254.x.y range!  Don't try to use any 10.x or 192.168.x.x addresses; these are unnecessary.  A VTI is a virtual point-to-point interface; the IPs really don't matter, and they don't even have to be remotely similar.  For a point-to-point interface, no matter what packet you "write" to that pseudo-wire, it will be sent.  So use the APIPA address space; that's what it's for, link-local addressing.

FYI: If you have Multi-Domain management, then you first need to switch to the Target domain where the VS is created before running the above command:

mdsenv TARGET_DOMAIN

[aMatthew]

Hi Duane,

Thank you first of all for your valuable help.
I ran the command as you indicated, however I got this as a response:

Version R81_10_jumbo_hf_main, build xxxxxxx
Session not established
Failed to connect with server 127.0.0.1

what is the reason for this error?

[Duane_Toler]

Did you run this on the gateway or the management server?

[aMatthew]

on the security gateway

[Duane_Toler]

The VSX provisioning tool is only run on the Management server.  If you have a Multi-Domain management, then you need to run it in the context of the domain where the VS lives.

[Matlu]

Hi, @Duane_Toler
This post is very helpful 🙂
Just to be more sure, this configuration is almost the same if I am going to work with BGP on my VPN, right?
One doubt I have is when creating the VTI from my MDS.
If I have already created the VTI from the MDS, is it necessary to ‘pull’ the topology from the SmartConsole, especially from the VS that is doing the VPN, or is this not done?
Thanks 🙂

[Duane_Toler]

No, VSX provisioning tool does all of that onto the VS directly  (as if you were doing it in SmartConsole).

For creating a VTI, disable anti-spoofing on the new VTI interfaces, but for any other interior interfaces where you have downstream BGP peerings, set those interfaces to "Defined by routes".

When creating a VPN community, you will want to use route-based VPN anyway, so use VPN domains per-community on both VPN peers for the Star VPN, and use empty groups (to trigger the VTI).  

Of course, your VPN Encryption should be using IKEv2, and Tunnel Management "one subnet per gateway pair" [IKEv2 Universal Tunnels).

In Gaia CLISH, on EACH VSX gateway where the VS is hosted, you'll need to configure the same router ID for all instances of this VS on all gateways, and copy/paste the BGP configuration in CLISH again on EACH gateway hosting this VS and in VS-context:

ssh vsx-gw1
clish
set virtual-system 5
set router-id 192.0.2.255
set as 65530
set bgp external remote-as 1234 on
set bgp external remote-as 1234 peer 192.0.2.1 on
save config

Repeat that exactly, on vsx-gw2, and vsx-gw3, etc.

Install policy, wait for VPN to come up.  Then SSH to the VSX gateway where the VS is ACTIVE, run:

clish
set virtual-system 5   #or whatever
show bgp peers

Only the ACTIVE VS (on whichever gateway) will show the BGP peering; all others will show Idle.  Don't be fooled, and don't troubleshoot the wrong thing.

Hope this helps!

[Matlu]

Hi, @Duane_Toler 
I understand that once I use the provisioning tool from the MDS, I will automatically see the VTI interface in the VS topology (SmartConsole)?
The use of the tool is done from the CMA that has 'hosted' the VSX boxes, or I do it from the CMA that has the VS as such?
Thanks 🫂

[Duane_Toler]

You run the VSX provisioning tool from the MDS context where the VS lives.  Or, you can specify the domain server of the VS with "-s <dms IP>"  [DMS is the new name for CMA].

vsx_provisioning_tool -s 192.0.2.10 -u adminuser -p adminpass -o show vd name FOO-VS

Or (preferably), put your VSX commands in a script file with transactions.  This is from one of my own scripts, fyi:

transaction begin
add interface vd FOO-VS vpn_tunnel numbered peer PEER_GW local 169.254.100.1 remote 169.254.100.2 tunnel_id 1025
add route vd FOO-VS destination 203.0.113.0/24 next_hop 169.254.100.2
transaction end

Save the transaction script (such as "vsx_script.vsx")

Run it with:

vsx_provisioning_tool -s DMS_IP -u adminuser -p adminpass -f vsx_script.vsx

You'll need a route to your BGP peer across the VTI, because VTI is a point-to-point link type with no broadcast (remember your OSFP link types, right?).  Since the peer is 1 hop away, you can use eBGP without multi-hop.

Good luck!

(be sure to give kudo to helpful posts!)