Checkpoint 730 Firmware

[Jenn Smotherman]

imtrynig to make a firmware upgrade for one 1430 appliance, this is what happens. my customer make a mistake and did a factory default, so all the firmware upgrades were lost, now it has the r77.20.31, and the most recent version is r77.20.86, a big jump. when ai tried to make a manual upgrade to the last version the cp1430 didnt responds, the que questions is this, do i have to make a gradual upgrade? in that case how do i know which versions should i install, in the system operation dashboard i dont see the option for the appliance to upgrade itself.

How did you try and perform the upgrade just via the web UI?

If you upgrade via USB as an example that version will become the new default if you factory reset in future.

Note R77.20.87 should be the latest available for this model.

I've had many customers getting confused about this. Many customers are updating their GAiA Embedded Appliances in intervals and many of them are thinking they are applying the most current release but in reality they are applying a out-of-date revision of the R77.20.87 firmware.

The real issue here is to keep the configuration - but as the customer did a reset to factory firmware, all config is lost already. I would use the USB procedure to upgrade active and backup 1430 images to R77.20.87 JHF having build number 990173020.

I am in planning of checkpoint cluster (HA) firmware upgrade procedure. We are running version R80.10 and planning to go on R80.30 code version. as this the first time in am doing a firmware upgrade on cluster i need more clarification on what method i should go for. Guide says there are 4 methods for the upgrade:

I am definitely going to have maintenance window for this work. I am more confused between connectivity upgrade and Minimal effort upgrade. Connectivity upgrade lets us upgrade without any Network disruptions and Minimal effort upgrade allows the most simplest way to upgrade which via upgrading each security gateway individually.

I know, it is totally up to me what method i want to go for, but i really need your recommendations on which path i should go for, in case you guys might have experienced easy going way from above methods.

Has there been any custom modifications to an files on the appliances you have? --> i did not get this part, but i am concerned about how checkpoints apply initial policy after the upgrade. can you please throw some light here?

Here is my suggestion as a guide:

Pre-Req:

Manager must be running R80.30 or Above with latest GA release, ideally manager should be running R80.40 or R81

Manager should have access to the internet.

Ensure you have a local resource to support the activity.

Any customised files should be copied offline and modifications restore on newly built gateway if required (Optional)

- Create snapshot of all appliances and store image offline

- save GAIA configuration and save offline

- Using ISOMorphic tool create a USB image.

- Detach the existing gateway license via SmartUpdate and export this offline, then delete it.

- Do a clean installation of the standby 4600 (assumed you have 4600 and not 4400, but I don't believe the image file would change) appliance and put the GAIA configuration back on.

- Install latest CPUSE agent

- upload and install latest GA Jumbo release for R80.40 (Take_118)

- Re-Sic/Push Policy.

- If manager has access to the internet and your running R80.40 or above the license should get installed to the gateway via the manager automatically, if not then of course add the license back in and then push to the Gateway.

- Check HA stat using 'cphaprob state', it should be Active/Ready I believe.

- via clish enter:

Also - in case you have more then one cluster, I suggest you consider using CDT. It's a central deployment tool that requires short learning curve but in case you will need to upgrade several clusters it worth it.

Hi. Not sure if this is the correct place for this so please forgive me if it isn't. Our Quantum Spark 1575 firmware just upgraded to version R81.10.08 (996001683) this morning. Unfortunately, it has rendered our IKEv2 VPN connections to our remote clients unusable as well as some web sites. The web sites come & go but the VPN's are down for the count. Have never experienced an update like this that caused this kind of problem but trust there is an answer here as to what process is best to use to correct it. I have disabled both the firewall as well as the application & url filtering to no avail. The VPN's were working as of the end of my day yesterday at 5pm. Unfortunately, I have never been able to perform a backup using SCP due to the 1575 not accepting the complex password for our server even though it is strictly alpha-numeric characters.... it's just 16 characters long.

After a lengthy session with TAC, it was determined that it the Spark was not preventing outgoing VPN connections. The VPN we use is not the typical L2TP but we use IKEv2 which does not use the in-built VPN functionality offered by the Spark. Upon installing WireGuard & setting up a connection, the VPN was established quickly. Unfortunately, there is something within the Windows 11 VPN settings that does not agree with the latest update on the Spark & is difficult to explain how 3 workstations IKEv2 VPN connection failed to connect. I can live with it, it is Windoze we're talking about & not unusual to have something break after an update occurred somewhere.

On another note, we did attempt to perform a rollback which was listed in the Spark as September of last year but it did not rollback as expected. Nothing is broken & everyone is a happy camper now. Appreciate all the input from the group here.

I believe it was already on a flavor of R81. The last update I did for it was somewhere around a month ago. At the moment, I don't recall any longer as I have never had an issue with the past 3 upgrades I manuall performed.

Since we updated this past week to R81.10.08_996001608, we were unable to connect to Checkpoint services. Our Harmony endpoints lost connection and we could not log in to portal.checkpoint.com. All other internet access seemed completely normal. Debugging web page access we saw that some checkpoint sites were reachable and others timed out. We thought it was the internet provider and performed all kinds of tests. Also, we were not able to connect to FW using watchtower. Opened a service request with Checkpoint and they told us "it is your internet provider, not our problem".

Our connection to internet is fiber PPoE with Telefonica. Only particular about this connection (bad but it has been there for a long time) is that first ip address in traceroute, the fiber default router, is 192.168.x.x. I do not know if this is related to the problem or not. But definitely the firewall was blocking or not routing https responses.

I have not had any issues with R81.10.08 996001608 and know of no customer that had - so better escalate this with TAC and if needed, also talk to your local CP SE. Can not be that it does work with 996000575 but not with 996001608 !

Hi. Thanks for response, but we tried everything for days. We had to revert.

No other changes other than the FW version. In my opinion, there is some additional filtering in 996001608 which, in our scenario, blocks some https responses, including blocking watchtower connections. It might be, or not, related to the ISP using some private addresses in their routing.

I am sorry not to have the time or resources to deal with TAC and will stay with 996000575 for longer, until hopefully the problem pops up elsewhere.

Is your appliance locally managed?

If so, I assume there is a possibility that it can be caused by the Smart Accel feature added since R81.10.05.

I think we saw some issues when the CP1500 WAN internet connection is PPPoE and in combination with Smart Accel, where some services like iCloud is affected and cannot login. We currently have a case open to TAC for this issue, pending their updates.

Hi Boris,

Then I assume the culprit is not Smart Accel then... but did you by any chance disable SecureXL as well?

Though SecureXL for PPPoE is supported in Gaia Embedded (apart from maintrain Gaia), it caused many issues in the past for us.

If SecureXL nor PPPoE (MTU) settings does not resolve your case, then I think your issue needs to be investigated by TAC, as I haven't experienced any issues so far with CP services with PPPoE in R81.10.07/R81.10.08.

The case is that we work normally in current version and have problems when updating firmware. So there is definitely a change in behaviour of the new version, which is most probably related to our specific environment.

You can disable SecureXL from WEBUI in Device-> Advanced settings by changing the parameter "Acceleration Settings - Acceleration state enabled" to "false"

Note: SecureXL is preferred enabled at all times

Also I was wondering if the same issue occurs on R81.10.05 and R81.10.07 which was released before R81.10.08 to understand if the issue lies only in the latest R81.10.08 or not, which is also worth testing before opening a ticket to TAC

3a8082e126