Site to Site Route Based VPN in Checkpoint

[CSR]

Hi,

I understand in Checkpoint we can configure the Site to Site VPN using policy based and its recommended as well for Checkpoint. But many of other vendors works with Site to Site Route based VPN.... Is there any (simple) way, we can configure the Route based Site to Site VPN with Checkpoint. Please share the steps/ relevant docs.

Thanks,

CSR

[Timothy_Hall]

The official Check Point documentation does a pretty good job of guiding you through route-based VPN planning and setup using VPN Tunnel Interfaces (VTIs):

https://sc1.checkpoint.com/documents/R80.40/WebAdminGuides/EN/CP_R80.40_SitetoSiteVPN_AdminGuide/Top... 

[CSR]

Yes, i already went through this doc but its so complex configuration. I tried it but didn't work... I was looking for some simple steps which can be used to configure it.

Thanks

[sreekanthvijay]

Hi ,

I could not open the link , could you please share the correct one 

[PhoneBoy]

I fixed the link in Tim's post.

[PhoneBoy]

Saying you tried the documentation and it didn’t work doesn’t help us help you.
What precise steps did you take?
What is the precise setup in question?
What version/JHF of the gateways and management?
Screenshots will probably help also.

[Vincent_Bacher]

You want to configure route based VPN just because other vendors are usually configured using that? 

From my perspective that makes no sense.

Yes, there are use cases vor route based but i never had the need.

[CSR]

What you are saying is absolutely right... I never required this configuration as Policy based VPN works absolutely fine on Checkpoint regardless of other side configuration method...

Actually I'm doing a POC for a customer and they want to evaluate Policy based VPN as well... That's why I reached out to this portal....

Thanks

[CSR]

I tried these steps on R81 with latest hotfixes and Smart Cloud management R81 version.

Sure will try again and share the screenshots...

I was wondering if it can be configured simple way like we confgure policy based VPNs. 

Thanks

[David_Herselman]

Perhaps someone could proof read the documentation, the very first two commands are both out dated and make references to the wrong IPs in the diagram.

Diagram:

Herewith some speed notes on creating route based IPSec tunnels between two ClusterXL gateways. What we also see often is that the management server will be internal to one ClusterXL whilst then being external to another. Remember to set a NAT address for the management server, so that implied rules are created to get the CRL requests through to the management server from the remote gateway. You may also need to temporarily create a local host entry for 'management-server' to map to the public IP, so that it can retrieve the CRL list as part of the first connection. Once the VPN tunnels are up you can change the remote gateway to use your AD DNS servers for resolution.

IPSec VTI between gateways:

Create mesh community 'Routed VPN' and add clustered gateways, set one tunnel per gateway pair and permanent. Gateways may need to resolve public NAT IP of management server to retrieve the certificate revocation list (CRL) and may otherwise log 'invalid certificate' erros.

Carve up a /29 subnet for the VTIs (route based IPSec): 10.150.166.24/29

jb1-cluster 10.150.166.25      10.150.166.30 db1-cluster
jb1-fw01    10.150.166.26      10.150.166.29 db1-fw01
jb1-fw02    10.150.166.27      10.150.166.28 db1-fw02

jb1-fw01:

clish
add vpn tunnel 1 type numbered local 10.150.166.26 remote 10.150.166.30 peer db1-cluster
set interface vpnt1 state on
set interface vpnt1 mtu 1500

jb1-fw02:

clish
add vpn tunnel 1 type numbered local 10.150.166.27 remote 10.150.166.30 peer db1-cluster
set interface vpnt1 state on
set interface vpnt1 mtu 1500

db1-fw01:

clish
add vpn tunnel 1 type numbered local 10.150.166.29 remote 10.150.166.25 peer jb1-cluster
set interface vpnt1 state on
set interface vpnt1 mtu 1500

db1-fw02:

clish
add vpn tunnel 1 type numbered local 10.150.166.28 remote 10.150.166.25 peer jb1-cluster
set interface vpnt1 state on
set interface vpnt1 mtu 1500

Update security policy:

Update network interfaces on the ClusterXL objects, so that you can set the VIP floating IP on the vpnt1 interfaces, this would be set as 10.150.166.25 for 'jb1-cluster' and 10.150.166.30 for 'db1-cluster'. Remember to install policy...

You should now be able to ping the remote cluster IP on each of the gateways, for example in expert mode:

[Expert@jb1-fw01:0]# ifconfig vpnt1
vpnt1 Link encap:IPIP Tunnel HWaddr
inet addr:10.150.166.26 P-t-P:10.150.166.30 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

[Expert@jb1-fw01:0]# ping 10.150.166.30
PING 10.150.166.30 (10.150.166.30) 56(84) bytes of data.
64 bytes from 10.150.166.30: icmp_seq=1 ttl=64 time=12.7 ms
64 bytes from 10.150.166.30: icmp_seq=2 ttl=64 time=11.0 ms
^C
--- 10.150.166.30 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 11.073/11.917/12.761/0.844 ms

Now enable dynamic routing over the VTIs:

jb1-fw01 & jb1-fw02:

set router-id 196.1.1.6        # external VIP
set ospf interface vpnt1 area backbone on
set ospf interface vpnt1 hello-interval 1
set ospf interface vpnt1 dead-interval 10
set ospf interface vpnt1 cost 10
set ospf interface vpnt1 priority 1
set ospf interface vpnt1 authtype cryptographic key 1 algorithm md5 key 1 secret xxxxxxxxxxxxxxxx
set ospf instance default area backbone range 10.150.166.25/32 restrict on
set inbound-route-filter ospf2 instance default restrict-all-ipv4
set inbound-route-filter ospf2 instance default route 10.0.0.0/8 between 8 and 31 on
set inbound-route-filter ospf2 instance default route 172.16.0.0/12 between 12 and 31 on
set inbound-route-filter ospf2 instance default route 192.168.0.0/16 between 16 and 31 on
set route-redistribution to ospf2 instance default from interface all on
set route-redistribution to ospf2 instance default from static-route all-ipv4-routes on

db1-fw01 & db1-fw02:

set router-id 41.1.1.26        # external VIP
set ospf interface vpnt1 area backbone on
set ospf interface vpnt1 hello-interval 1
set ospf interface vpnt1 dead-interval 10
set ospf interface vpnt1 cost 10
set ospf interface vpnt1 priority 1
set ospf interface vpnt1 authtype cryptographic key 1 algorithm md5 key 1 secret xxxxxxxxxxxxxxxx
set ospf instance default area backbone range 10.150.166.30/32 restrict on
set inbound-route-filter ospf2 instance default restrict-all-ipv4
set inbound-route-filter ospf2 instance default route 10.0.0.0/8 between 8 and 31 on
set inbound-route-filter ospf2 instance default route 172.16.0.0/12 between 12 and 31 on
set inbound-route-filter ospf2 instance default route 192.168.0.0/16 between 16 and 31 on
set route-redistribution to ospf2 instance default from interface all on
set route-redistribution to ospf2 instance default from static-route all-ipv4-routes on

CRL retrieval:

Enable NAT on management server to construct implied rules and switch all gateways to use external IPs
May be needed temporarily to cache the CRL:
add host name checkpoint-management ipv4-address 196.1.1.4  (or whatever IP is natted to the management-server)
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Debug IPSec:

1st session:
vpn debug trunc
vpn debug on TDERROR_ALL_ALL=5
fwaccel off
fw monitor -e "accept;" -o /var/log/fw_mon_traffic.cap

end:
<ctrl>-c
fwaccel on
vpn debug off
vpn debug ikeoff

2nd session:
fw ctl debug 0
fw ctl debug -buf 32000
fw ctl debug -m fw + conn drop vm crypt
fw ctl debug -m VPN all
fw ctl kdebug -T -f > /var/log/kernel_debug.txt

end:
<ctrl>-c
fw ctl debug 0

archive:
cd /;
tar -czf /root/sk63560.tgz /var/log/fw_mon_traffic.cap /var/log/kernel_debug.txt $FWDIR/log/ike.elg* $FWDIR/log/ikev2.xml* $FWDIR/log/vpnd.elg*;
rm -f /var/log/fw_mon_traffic.cap /var/log/kernel_debug.txt;

View $FWDIR/log/ike.elg* (IKEv1) or $FWDIR/log/ikev2.xml* (IKEv2) using IKEView utility to debug in seconds what's going on, then find the actual reason in the logs. IKEView may complain about an invalid certificate, although we're using the built-in SIC certs, due to a new remotely managed gateway perhaps not having the ability to resolve the management server name to the required IP, hence not being able to retrieve the CRL and cache it. Bit of a chicken and egg story...

[PhoneBoy]

@Uri_Lewitus for the documentation update 🙂

[PankajTiwari1]

do i need to add routing for vti ipsec tunnel?

[PhoneBoy]

When using a route-asked VPN, traffic that goes through the VPN must have a route through the VTI interface (either statically defined or through dynamic routing protocols).

[PankajTiwari1]

thanks. it worked.

But why I can't see logs on vti tunnel interface. the policy have been created without the vpn community added. vpn column set to any. tunnel is working fine.

[PhoneBoy]

Not clear what the question is.
What precisely do you expect to see?
What do you see instead?
Screenshots (with sensitive details redacted) would be helpful.

[PankajTiwari1]

Can I create multiple tunnel with one VTI interface?

[PankajTiwari1]

Like I have configured VTI 15 on smb gateway and same  VTI 15 on other two gateways.  It will work or not?

[PhoneBoy]

As far as I know you can.

[Sergei_Shir]

The instructions in the Site to Site VPN Admin Guide were updated - the modified books will be uploaded soon

Meanwhile, see the attached file with the "Route Based VPN" chapter

Note that configuration of VTI interfaces must be done only in the Gaia Portal or Gaia Clish.

[Eugen_Karyakin]

Can I create and use VTIs more than 99? How many VTIs I can use? I created 255 VTIs and imported them into the topology in SmartConsole for the purpose of testing. Will VTI work with numbers over 99?

[starmen2000]

I wanted to know the answer to this question because on another (3.Party) site Tunnel ID is 1008, and  However, in the admin guide, it states that Tunnel IDs must be identical and must be between 1 and 99. 

[the_rock]

I had that problem once with customer whose partner was using PAN on the other end and they simply got rid of their runnel ID and that fixed the issue. Honestly, I have no clue where that setting even is on CP side and how to modify it, never seen it myself. UNLESS, its referring to VTI tunnel id maybe, then that has to be it...

Andy

[the_rock]

I learnt something new today. Though I must have set up probably dozens of these tunnels before, I honestly NEVER paid much attention to that setting, but thats probably cause I never done one to Palo Alto, always to Azure and AWS.

But, shows max valud can be up to 32768 for tunnel ID

Andy

 

[Udara_Wijetunge]

Hi all,

Can we create route based VPN tunnels in a VS (virtual system) in VSLS set up? 

I'm trying to build a route-based IPSec L2L tunnel for a VS (in VSLS set up running R80.40) to Azure VPN gateway and use BGP route advertisements. Is this achievable? I've seen in documentation that VTI is not supported in VSX environment. Is it still not supported? 

Is there any other way to build a route based VPN with BGP advertisements?

Appreciate your comments and findings.

[Timothy_Hall]

VTIs are not supported with VSX in R80.40, but support for this was introduced in R81.  See this very informative SK: sk79700: VSX supported features