IPsec VPN between Checkpoint and Remote Server

[Saranya_0305]

Dear Mates,

I am having Cluster setup running in R81.10 and Management Server in R81.20.

My firewalls having two ISPs(external interfaces) which are in ISP redundancy mode. 

Now I want to create a IPsec VPN tunnel between Firewall and third party Remote server directly,  it it possible?

If it is possible then how can I use my two ISPs?

- Do I need to make two different IPsec tunnels? If yes, will they  work redundancy mode automatically or we need to manually?

- Can we do FQDN and map those two ISPs to that FQDN and create IPsec tunnel?

Can anyone please suggest me?

Regards,

Saranya

[the_rock]

I believe it would have to be manual option, unless you have routes with different priorities, so if main one fails, then other one will take over. Here is my reasoning for it...if you think about it logically, say you have VPN with Cisco or Fortinet or PAN, whatever really. IF main link fails, well, there is no way other side would "know" about new ISP link, so tunnel would never re-establish.

Hope that helps.

Andy

[Saranya_0305]

Can we map two different vendor ISPs IP to single FQDN and make VPN tunnel?

Regards,

Saranya

[the_rock]

Im fairly sure you can, you just need 2 A records pointing to same fqdn. I know we did this for a customer while back for remote access.

Andy

[Saranya_0305]

Thanks @the_rock , Can you please share any related SK or document?

Regards,

Saranya

[the_rock]

I know there were 2, one I can easily find, but will check the 2nd one later and update you.

Andy

[the_rock · Accepted solution]

There you go.

Andy

https://support.checkpoint.com/results/sk/sk103440
https://support.checkpoint.com/results/sk/sk131612

[Duane_Toler · Accepted solution]

@the_rock gave info on how you can do this with the Endpoint VPN client, but for site-to-site VPNs with 3rd party gateways, this can't be done with pre-shared keys.  If the remote end is willing to do either:

• Use a certificate issued by your management internal_ca, or
• Use VTI with IKEv2 and universal tunnels  (likely the better choice)

With certificate, the remote end can allow your side to appear as a "dynamic IP" VPN peer and allow authentication to rely on the certificate. However, now that we have VTIs and universal tunnels, certificates will be less preferred and instead you should use the VTIs.

The remote end will build 2 VPN gateways for each of your ISP-provided IPs (or the cluster VIP for each, if you have ISP Redundancy on a cluster).  The encryption domains for both you and them will be empty group objects (or, however the remote device does this).  You'll then create a VTI on your firewall gateway in CLISH, as will the remote peer.  The IPs on the VTIs are irrelevant; VTIs are just point-to-point links and any packet you send to that VTI device will be encrypted and sent to the specified remote peer (specified in the VTI configuration).

You can use static routing with either primary/secondary priority, or just let it be equal-cost; doesn't matter either way.  This is how you do an AWS VPNgw redundant VPN, too.

The remote peer does the same thing, only in reverse, with a VTI on their side.  They will add static route for your VPN networks across the VTI.  Configure the VPN community tunnel management as "one tunnel per gateway pair" and you're done.

[the_rock]

I got this document from someone in community while ago, not sure it may help in this case, but here it is anyway 😊

Andy