Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Smorales
Participant

VPN S2S Between Check Points

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?

 

0 Kudos
6 Replies
the_rock
Legend
Legend

Set tunnel as permanent and enc domains as empty groups.

Andy

0 Kudos
Smorales
Participant

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

0 Kudos
the_rock
Legend
Legend

It can be, yes.

0 Kudos
Don_Paterson
Advisor
Advisor

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?

 

0 Kudos
Smorales
Participant

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.

0 Kudos
Don_Paterson
Advisor
Advisor

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. 

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.