VPN S2S Between Check Points

[Smorales]

Hi everyone,

I want to create a VPN S2S between two check point gateways, the first one is On-prem and the second one is a Cluster HA in AWS, we already did a VPN community between the Cluster in AWS and a third party firewall, the vpn is working well.

When we tried to create an star community between the 2 check point gateways, the VPN couldn't couldn't start up, and in logs we saw that there was an authentication error with the certificate and that vpn community take down the other community between my cluster and a third party firewall.

Well giving more details about the enviroment:

I have an MDS that manages a VSX cluster, In the MDS domain that manages the VirtualSystem that makes the VPN connection, it also manages the Cluster in AWS, both cluster and Virtual System are managed by the same Domain in my MDS.

When I created the VPN community I follow the next admin guide: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_SitetoSiteVPN_AdminGuide/Con.... (Configuring a Star or Meshed Community Between Internally Managed Security Gateways)

Is an Star Community  with central gateway the Cluster and Satallite Gateway the VS on-prem, I share with you an example of the configurations.

I think this issue is more related to certificate because my on-prem Virtual System has a certificate with RSA Key of 2048 bits length and the Cluster in AWS has a certificate with RSA key with 1024 bits.

Do you think the certificate is the issue? 

Have you ever had a similar problem?

[the_rock]

Set tunnel as permanent and enc domains as empty groups.

Andy

[Smorales]

This configuration you are saying is for the VPN between both check point firewalls? 

[the_rock]

It can be, yes.

[Don_Paterson]

The certificate could be the issue. 

Can you share a screenshot of the log?

Are there overlapping subnets in the domains of the 3rd party and Virtual System?

Is the working VPN using shared secret or certificate based authentication?

[Smorales]

1. Yes, I share with you the log.

2. I say yes, and that's what I was reviewing yesterday before writing the post.
Both the CheckPoint cluster object in AWS and the PaloAlto interoperable object have their own defined VPN domains.
For the CheckPoint to CheckPoint community, we made the AWS CheckPoint central with the same VPN domain it has with the Palo Alto community. For the on-prem CheckPoint domain, an already established domain is used in the same way, however, that firewall has dozens of communities with third-party gateways and that same domain is used in all communities.

3. Since it is between CheckPoint and CheckPoint, the VPN would be certificate-based, as both firewalls are being managed by the same console.

[Don_Paterson]

Thanks. The log points to the problem being the authentication and possibly the certificates. 

Check Point gateways managed by the same SMS will indeed be forced to use certificate based authentication for IKE. 

I was interested in the AWS to 3rd party authentication because that tunnel was affected by the new setup. 

I was also interested in the domains and wanting the know that they were unique to each gateway. Meaning that there were no overlaps (same networks/subnets in the two gateway's domains. 

There seem to be two problems here. The authentication failure and a previously good VPN solution experiencing a problem. 

It might be better to get a new Service Request open with Check Point TAC, and then they could efficiently offer a solution after gathering all the information.

With a cpinfo they would see versions and full configuration and be able to properly analyse it. 

VSX being involved should not make a difference but it is not the standard gateway solution so that is something else that needs to be considered. 

[Smorales · Accepted solution]

Hello everyone,

We have found the problem and the solution to it.

Let me explain: we reviewed the logs in detail and realized that the AWS cluster was attempting to reach Security Management with its private IP address, which is why the cluster was unable to reach Security Management.
To resolve this, we proceeded to use the option within Security Management called “Management behind NAT” based on the following sk: https://support.checkpoint.com/results/sk/sk66381

Once a static NAT with a public IP was assigned and the corresponding gateway was assigned, we enabled the control connections checkbox to expose the management and control ports. We enabled two firewall rules where the source is the NATed IP of the security management and the public VIP of the AWS cluster (two host-type objects) and in services like FW1, CPD, and other services. This is simply to specify the connection and send everything else to the cleanup rule. This rule was added to each policy package in the AWS cluster and our Virtual System, preferably at the top or above the policy package.

With these two configurations, the VPN was successfully set up.

Thank you all for your comments.

Best regards!

[the_rock]

Great job!

[Don_Paterson]

Well done.

If you want some background and extra info:

1.

R82 has enhanced the Management behind NAT configuration options (see link below and screenshots attached):

https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Cont... 

2.

Apply for Security Gateway Control Connections

That does not really expose the management server and ports, but I understand what you mean.

Below is the official description, but a good way to understand that option better is a specific scenario.

In the scenario the management server is positioned directly behind one of the managed gateways (or clusters) and uses that gateway to reach the rest of the managed gateways, but the management server is NATed behind the local gateway.

All of the managed gateways 'learn' about the real and NAT IP addresses of the management server (as a result of the policy installations).

The local gateway actually applies the NAT on the management traffic (control connections (policy install and log and status sending etc.)), as long as that option is checked.

The local gateway does not NAT management traffic that is directed to itself (for example, the local gateway getting a policy installation from the management server or sending logs and status messages back to the management server), assuming it is on the same network (probably there to secure the management server).

So the option is a way of educating the gateways about the IP addresses of the management server and then they can use that for internal communications/control connections.

"

• This option performs NAT on VPN control connections to and from this object. This makes it possible to install a policy or collect logs across a NAT gateway. This object must be either a Security Management server or a Log Server.

"