Central management and certificate based VPNs

[velo]

I have a Star IPSEC VPN setup with all gateways managed centrally. Recently, I encountered a problem when the management server was offline for a few hours. During that time, all of the VPNs dropped when they re-keyed, even though the certificates still had years left before expiration. This behavior was unexpected and quite concerning, as it seems to present a single point of failure.

Does anyone know why this happened? I couldn't find any information about this in the documentation.

My understanding was that central management would only be an issue if a VPN certificate expired, as we wouldn't be able to generate a new certificate with the management server down.

I'm going to take a guess and assume that maybe when the VPN re-keys, it checks with the CA to see if the certificate is still valid. Is there any way around this? It's pretty bad if the management server is so critical to VPN re-keying.

[PhoneBoy · Accepted solution]

VPN certificates are validated against the CA on rekey, whether it be the internal CA or an external one (depending on configuration).
Extended outages of management when ICA is used for VPN certificates will cause VPN issues like you experienced.

Having said that, this usually doesn’t happen for about 24 hours (not just a few, as you experienced).
The CRL should be cached, in fact, and you may want to check this sk: https://support.checkpoint.com/results/sk/sk116340

You can disable CRL checking, of course, but checking the CRL is an important security feature that should not be disabled.
See: https://community.checkpoint.com/t5/General-Topics/Failure-to-fetch-updates-from-CheckPoint-servers/...

[velo]

Thank you for the response. I had a suspicion it might be something like that.

Where do I need to check the settings listed in sk116340? I can't see that section in Smart Console.

Thank you

[PhoneBoy]

In the object list, you find it under Servers > Trusted CA > internal_ca
This was taken from R82, but it should be the same in previous releases. 
I've submitted feedback on the SK to ensure instructions for finding in R8x are included.

[velo]

Thanks for that, I found it now and it's 24 hours. Appreciate the info.

It explains things nicely except the management server was down for less than 24 hours, it might have even been only a few hours before the issues started. Do you know if these cache changes will apply to SMB Quantum Gateways also? That is the difference, they were Quantum Gateways (1500s) The central gateway was a normal Checkpoint 6200.

Thank you

[PhoneBoy]

As far as I know, SMB gateways should also cache the CRL.

[velo]

I've looked at this SK article and see it shows how to check the last and next CRL update.

https://support.checkpoint.com/results/sk/sk108632

My output shows that the CRL cache is 7 days.

This update: Mon Sep 2 19:10:04 2024 Local Time
Next update: Mon Sep 9 19:10:04 2024 Local Time

But when I follow your SK article above, my internal_ca cache is set to 24 hours. 

These two don't tie up. Any idea why this is the case?

Thanks

[PhoneBoy]

Offhand, I do not.
Recommend engaging with TAC here: https://help.checkpoint.com