Smart-1 High-Availability Clarifications

[FXE]

Hi All,

I would like to clarify what data are being synchronized between the two Smart-1 running in HA? If the site-to-site VPN certificates are not being synchronized, how can I synchronize it then to the secondary Smart-1?

I am worried that my site-to-site VPN certificate will not be able to synchronize to the secondary Smart-1 and when a failover happens in the Smart-1, my VPN breaks.

Thank you

[_Val_]

Hi @FXE, 

all management database: objects, policies, and packages, is synced to the secondary management server. After pushing the secondary SMS to an active role, it will be able to maintain all management functions fully.

However, it is the Primary Management ICA that signs VPN certificates. That means that CRL distribution point is still on the primary SMS. CLR is cashed on your GWs for 24 hours after being retrieved. That means you have a reasonably long time for your VPN runners to continue working before you fully restore your primary management, and it assumes the active role again. 

If your primary management server is irretrievably lost, you can promote the secondary server to become primary. You will need to push policies to all VPN GWs after this step, to make sure the CRL DP change is known to the GWs.

[FXE]

Hi @_Val_ , will this be the same if the CRL check is disabled? The thing is that, my site-to-site VPN authentication is using corporate certificate instead of pre-shared-key, will my VPN tunnel go down when failover happens to my secondary smart-1?

Are there any ways to have the VPN certificates to be in both smart-1?

Thanks

[Chris_Atkinson]

Further information is available per:

sk100731: VPNs go down within 24 hours after primary Security Management server goes down

sk21156: Disabling CRL checking when authenticating with certificates

[FXE]

Hi @Chris_Atkinson , thanks for your inputs. Will there be a way on how to have the VPN certificate being used to be in both primary and secondary smart-1 so that when failover occurs, my gateways can still fetch the certificates from the secondary smart-1? Thank you

[PhoneBoy]

To be clear: the certificates are actually on the secondary management.
Otherwise, you would not be able to promote the secondary to primary and “take over” this function in the event of a failure.

The problem is that the CRL points to the primary management IP only.
Anything that checks the CRL won’t know about the secondary management IP.
The only way to change that on remote gateways is a policy push.
VPN Peers not managed by your Check Point management may also need to reconfigure the CA used for authentication, which will need a different CRL URL. 

Perhaps you can work around this with NAT, but haven’t tried this myself.