Firewall replacement - consequences for VPN clients and how to handle it

[andre_paulsen]

Firewall replacement - consequences for VPN clients and how to handle it  

We're going to replace our todays firewall and as I've understood you cannot create the new VPN client (Mobile VPN) until the new firewall object has been created and is up and running. We've done this on another location with mixed experience. Users were not prompted for new certificate not even after site has been deleted/re-created in the VPN client. The only solution we found for that site was to uninstall/re-install the VPN client.

Now we're going to replace the firewalls on a bigger site with hundreds of VPN clients connected. I would not like to re-install those clients as users are often on business trips and do not have local admin rights.

Any ideas on how to proceed with this the least painful way?

[XBensemhoun]

Hi Andre,

What do you mean exactly by "VPN Mobile"? RemoteAccess VPN client (also known as VPN Standalone client)? And what is the version?

And when you say firewall replacement: do you mean that you just change the hardware of an actual firewall without changing @IP addresses nor active blades?

[andre_paulsen]

Hi, and thanks for your reply. Sorry for being unclear about that, but yes it's the Remote Access VPN client where we choose ''Mobile VPN'' out of the three options (Endpoint Security, Mobile VPN, Secure Remote). We have different kinds of versions.

Yes, we are going to replace an Open Server with an Appliance where we keep the same external IP-address and all active blade. 

As far as I've understood the VPN client cannot be prepeared ahead of the firewall change and when the new firewall is up and running I'm afraid that we need to uninstall/re-install the VPN-client for our users.

[XBensemhoun]

I can see two things:

 - if you have no reason to delete the corresponding object in the Dahsboard (and I think you should not delete it): the certificate initialized at the creation step of this object in the dashboard will be kept and applied for the new physical hardware (just after the first policy installation).

 - you will not have to change anything on the trac.config file deployed on users' PC because you maintain the @IP or the hostname and you'll inherit of the 'old' certificate

[andre_paulsen]

Hi,

With replace, I mean replace one Open server with two appliances in cluster. This means that the object must be re-created. Sorry to be unclear about this to.

Thanks for your reply so far!

[XBensemhoun]

OK, so: yes off course you will have to delete the old object and create a cluster object including each of needed appliances. By that: you'll have to redo SIC.

And, a new certificate will be generated and pushed at the first policy installation on each gateways' cluster.

But you can create on your own and then import it. By that, you will be able to find its fingerprint and updating the trac.config of your clients before you're cutover.

You'll find it the IPSec VPN section of the cluster object, such as:

and you'll have to place it in the internal_ca_fingerprint field of the trac.config file:

[andre_paulsen]

Thanks for your reply, Xavier.

My main consern regarding this solution is editing the trac.config and if this is officially supported by checkpoint? Also what other lines in the trac.config must be added or inherited from the old trac.config. In addition we most likely have dozens of different versions of the VPN client.

I understand your solution would be to push the updated trac.config file to our clients with the help of GPO or similar?

[PhoneBoy]

In general, yes, you can edit trac.config.

There are several SKs that discuss doing exactly that.

That's not to say EVERY change to trac.config is supported of course