Migrating from Check Point 3600T to Quantum Spark 1600,Need Help with VPN User Certificate Migration

[NJTsunss]

I’m currently using a Check Point 3600T running Gaia R80.30. The main functions are:

• Filtering LAN user traffic

• External NAT

• Remote Access VPN for around 100 users

All remote users use the Endpoint Security VPN client (version E82.40) and authenticate using user certificates. The certificates are generated via a self-signed Internal CA on the firewall. I have an LDAP connection to Active Directory, and I generate a certificate per AD user directly from the Check Point. Users enroll using an enrollment key through the Endpoint Security client, and the certificate is automatically installed on their laptops.

I’m now planning to migrate to a Check Point Quantum Spark 1600 (SMB appliance) running R81.10.10.

My question:

Is it possible to migrate the VPN user setup to this new SMB appliance without requiring any changes on the user side? Ideally, I want users to continue using the same VPN client and existing certificates as if nothing changed.

Migrating access/NAT rules manually is not a problem for me. My main concern is preserving the certificate-based VPN user setup.

On the new Spark appliance, I can only see options under:

• Trusted CAs

• Installed Certificates

• Internal Certificates

I can’t find any clear option to generate user certificates per AD user as I did on the 3600T. Am I missing something? Is there a workaround or supported method for this on SMB appliances?

If certificate-based auth isn't possible:

If I have to switch to username/password authentication, can I configure auto-reconnect without prompting for credentials after every reboot? With certificates, the connection auto-restores on boot, but with password auth, users are asked to re-enter their password each time.

Any advice or guidance would be appreciated especially from those who’ve worked with Quantum Spark appliances in similar setups.

Thanks in advance!

[PhoneBoy]

If your goal is for "nothing to change" as far as your end users are concerned then you need to do the following:

• Migrate your 3600 management to a Smart-1 appliance, VM, or to a Smart-1 Cloud instance: https://support.checkpoint.com/results/sk/sk179444 (note this requires either an appliance purchase or a software license)
• Use this management instead of the local web UI on the 1600 to manage the policy 

With this configuration, you should be able to maintain the existing certificates and, more importantly, the Certificate Authority.
However, this still requires you to add the fingerprint for the new gateway to the register on client machines so no prompts are given.
Otherwise, there is no way to migrate the configuration between the two appliances in a way that users will not notice as:

• There is no way to migrate an ICA between systems beyond using the migration tools
• Local management for SMB appliances doesn't allow for using certificate-based auth

For password-based auth, our VPN clients do not cache the password.
This is by design.

[NJTsunss]

I have license service named Smart-1 Cloud to manage 5 spark gateways for 1 year , including smart event blade. would this be enough?

[PhoneBoy]

Importing the migrate output into Smart-1 Cloud would only be possible with a new tenant, as far as I know.
Which means you might need a different license.

[NJTsunss]

Sorry I'm Replying bit late, but you mentioned that "Local management for SMB appliances doesn't allow for using certificate-based auth". Is this written anywhere in Official Checkpoint Documentation? I would appreciate if you would be able to give me a link.

[Tom_Hinoue · Accepted solution]

See here:

Certificate authentication for Remote Access works only with an external CA on Quantum Spark / SMB locally managed appliances
https://support.checkpoint.com/results/sk/sk110534

On locally managed SMBs, the internal VPN cert could not be used when using cert-based auth.
Only using External CAs are supported.

[NJTsunss]

So it's still possible to authenticate users by Certificate with Locally Managed 1600 Right? 

[PhoneBoy]

Yes, but you must do it using an external Certificate Authority, as described in the SK.

[NJTsunss]

Yes i understand it but can i perhaps use My C3600T as external CA? Also what about The Clients who use User Certificates will they be able to authenticate to the 1600 VPN Without changing anything on their side?

[PhoneBoy]

The only way you can "use your 3600 as the external CA" is that becomes the manager for the 1600.
Either that or it's whatever management you export your 3600 configuration to as I described previously.
If you've configured things correctly, the existing certificates should work as-is in this configuration.

Note that this requires a license which I believe is included with current gateways.
Gateways only include a management license for up to two gateways explicitly to support a "Full HA" configuration.
If your plan is to migrate management to Smart-1, it needs to be to a completely new tenant so it inherits the same ICA and thus existing certificates will work.

In every other scenario, you will need to change something on the clients.
Hope this is clear.

[NJTsunss]

Sorry but I don't get it why can't 3600 be used as external CA for 1600 while managed locally. can't i export 3600 internal CA and import to 1600 trusted CA list?
Would not that count Using 3600 internal CA as external CA?

if not 3600 and I'm using external CA. what should be used for that

[PhoneBoy]

The ICA is only exportable as part of a migration/upgrade.
It is not something you can export/import independently, nor is it something that can be copied between a locally managed Gaia appliance and a locally managed Embedded Gaia appliance.

As I understand it, Windows has mechanisms to be a Certificate Authority.

[NJTsunss]

I think Its possible to migrate with the service license I mentioned, because I have launched my Smart 1 Cloud which has 1 Year duration and in Settings Tab I can see Option Of Migrate, It tells me to choose either manual Migrate or Simplified Migrate.

Perhaps I can try The migrating?

[NJTsunss]

Also Do you perhaps have any recommendations for exporting only the database (policies, certificates, objects, etc.) to Smart-1 Cloud.

My current device is a 3600T, running R80.30 Gaia 3.10 take 47, in standalone mode (gateway + management on the same box). The target is Smart-1 Cloud, which runs R82.

While I test and migrate configurations, the 3600T must continue functioning as it is — I’m not planning to activate the new 1600 appliance until I'm confident that everything is working properly in the cloud.

     My questions are:

1. Is it possible to export only the database (without affecting the gateway functionality) from this standalone R80.30 setup, and then import it into Smart-1 Cloud?

2. I read that direct migration from standalone R80.30 to Smart-1 Cloud is not supported. Some older posts suggested using a temporary management server as an intermediate step. Is this still the case?

   
   If so, would the following plan work?:

   1. Deploy a temporary R80.30 management server with a 15-day trial license.
   2. Export the database from the standalone 3600T and import it into this temporary management server.
   3. Upgrade the temporary server to R82.
   4. Perform the migration to Smart-1 Cloud from this upgraded R82 server.
   
   Additional Notes:
   1. My current 3600T is somewhat unstable, so I'd prefer not to make any changes to it (like firmware upgrades or enabling additional components).
   2. The goal is a clean Smart-1 Cloud migration without disrupting the current firewall operation during testing.

[PhoneBoy]

Using the migration tools to make a copy of the necessary data from the existing gateway will require an outage as part of the process.
Note that the export/import also includes licenses, so you will need to apply those AFTER import into your new (temporary) management.

According to the docs, your management need to be on R81.10 or higher to migrate to Smart-1 Cloud.
As R82 is a two-step upgrade from R80.30, you're probably better off going to R81.20 instead.
Follow the advanced migration steps.

[NJTsunss]

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

Will this cause any issue with my migration to temporary server, Because currently My 3600T firmware is R80.30 3.10.
Will I have to upgrade My 3600T firmware first to R81.20 Or perhaps I will have no issue without upgrading it and doing straight up migration to Temporary management server?

It would way be better If I don't have to upgrade my Firmware of 3600T

[PhoneBoy]

That SK refers to using Management HA to effectively "clone" the configuration to a different system.
That's not the Advanced Migration process, which is what I'm talking about. 
It will not require you to upgrade your 3600 at all.