R82: Site to site VPN authentication issue when using certificates

[patones1]

Hello,

When testing the R82 version for VPN site to site between two different Check Point sites (Externally Managed VPN Gateway), I found an authentication issue when using certificates exchange as authentication method. The traffic was rejected. There was no issue when using pre-shared secret .

Then I updated Gaia in both SMSs with the "Jumbo Hotfix take 44". I thought that it was going to solve the issue. But result was the same: "Authentication failed".

I rebuilt all again in my LAB, reinstalling and configuring everything from scratch ......  with the same results.

Finally I did the same with the R81.20 version (just in case...). Everything was working OK when using the R81.20 

So i think there is a really issue when using certificates to authenticate the site to site VPN between two different sites (domains)

If somebody could confirm that it is not an isolated issue but a general one ?

Thanks for your feedback

Best regards

Miguel

 

[genisis__]

Have you raised a case with TAC?  If it is an issue with R82 then will need to be engaged.

[patones1]

It is not a production case. I was just testing in my LAB.
That's why I am using this way to inform people about this issue. Somebody should test it to confirm

[the_rock]

Hey Miguel,

I know this is smb related post,but see if it helps. Its clear based on the message it does not like something about the cert.

https://community.checkpoint.com/t5/Security-Gateways/HowTo-Set-Up-Certificate-Based-VPNs-with-Check...

[patones1]

I have been using certificates for VPN authentication since R80 version. I have always worked using the same method. Even with the R77.30, the method is quite the same (with some differences in language and interfaces.)

This time, to be sure my platform was working OK, I made the test  using certificates with the R81.20 version. A successful test.

Unless the way of exchanging certificates has changed since R82 version, there is a problem when exchanging certificates for creating new VPN tunnels.

It is hard to believe nobody has already test it.

[the_rock]

I really cant confirm that, sorry...lets see if anyone else might know.

[patones1]

Just to show how simple is the authentication by certificates. It should work this way, and it is not working in R82 version:

• First, you save your certificate. You are going to share this certificate with the distant site:

•  Then, you use the certificate shared by the distant site, to create a new "Trusted CA" ( as "External Check Point CA")

 By clicking on "Get" on the "External Check Point CA" tab, you will select the distant site certificate that have been shared by your partner. 

And that's it. Don't forget to uncheck "Use only share Secret for all External members" in the community and if there is already a tunnel built on the community (same tunnel), use vpn tu in order to delete the previous tunnels (IPsec + IKE SAs)

For me it is a mystery that authentication by sharing certificates is not working anymore since the R82 version.

I haven't tested what happen when a tunnel is already built with certificates before upgrading from R81.20 to R82. 

Best regards

Miguel

 

[the_rock]

Let me see if I can test this in the lab. I had this working before and when I upgraded to R82, it still worked fine.

[Alex-]

Is your CRL reachable/resolvable? Have you tried turning it off to see if it makes a difference?

[patones1]

I am not sure it is about a CRL issue. But I will test it next week. This week I am too busy
Thank you Alex

[RS_Daniel]

Hello,

I must say i have not tried with R82, but the steps i usually follow are quit different.

1. Importa external CA and create a Trusted CA object.
2. Go to local gateway object > IPsec VPN > Certificates repository. Click add and generate a CSR selecting the Trusted CA created on step 1. 
3. Send CSR to the peer to get it signed.
4. Import the signed certificate into IPsec certificates repository.
5. Go to external peer gateway object > IPsec VPN > Matching Criteria, select the external CA created on step 1. Fill up the match conditions, i usually use DN.
6. Push policy.

Hope this helps.

Regards

[Feridun_ÖZTOK]

Hey, Same thing 😞

[RS_Daniel]

Hello,

The first log with error regarding CRL makes me think it is going in the rigth direction. On the trusted CA object go to OPSEC PKI tab and uncheck both options under Rretrieve CRL From section. Does it change anything?  You can check sk109139 for reference, it is the same logic but in the sk the certificates are signed by internal CA (management server) instead of the external CA, it should work no matter wich option you use.

Regards

[patones1 · Accepted solution]

Hello RS_Daniel

I found a way to disabling CRL checking from Timothy Hall in another issue: 

https://community.checkpoint.com/t5/SMB-Gateways-Spark/Disabling-CRL-checking-for-centrally-managed-...

I entered the command in both gateways,

And now it works. So it was an issue of the receiving side not being able to retrieve the CRL on the R82 version.

Until Check Point resolves the issue on the R82 version, the only way to make work the VPN tunnel with 2 Check Point CAs (SMSs), is disabling CRL checking by using the command above.

I hope this will help

Cheers

Miguel

 

[the_rock]

Excellent Miguel, thanks for letting us know.

[patones1]

Hello RS_Daniel,

That is for a third part CA. 
My VPN tunnel is between to gateways managed by their own Check Point CA  each one (managed by their own SMS). 
The way of exchanging certificates is strait (no need to go to the repository)

It is about the R82 version issue rather than a configuration or procedure issue. 

I tried disabling CRL checking. One log was like this: "Auth exchange: Could not retrieve CRL.CN=sg1 VPN Certificate,O=sms1..b6gyro"...... without success

Best regards

Miguel

[Feridun_ÖZTOK]

I thought it was just me who couldn't do it 🙂 I have two R82 gateways with separate managements on the office and DataCenter sides. I'm having the same problem.

[ShemHunter]

Hi All!

My client had a problem with certificates somehow. And we had a problem - the DN value was set. After we set it to Default, the problem was resolved. Maybe this will help you too.