Important Notice: Incorrect Default Firmware Version on Gateways Running R82.00.xx

[Noa_Alon]

Hi,
We would like to inform about an issue affecting some gateways running R82.00.xx, where the configured default firmware image may be invalid. 

This configuration may cause the gateway to enter Maintenance Mode if it is reverted to factory default settings.

If this occurs, the gateway can only be recovered by performing a Clean Install.

Important - If your gateway is affected, do not revert it to factory defaults until the default firmware image has been updated according to the instructions below.

Please follow the steps below, to avoid any potential service outage:

1) Identify the affected GWs:

• Using Spark Management
• Go to Dashboards → DR Spark, click Gateways with critical failed tests

• In the search bar, filter by: (name:"Default Image Build")
• The results will display the gateways that are affected and potentially at risk.
• Using  WebUI,
• Go to Device → System Operation → Revert to Factory Defaults section:

• If the default image is lower than R82.00.10 B998001654, the gateway is affected and should be updated. 
• Using CLI,
• Run “show diag” command and search for the default image:

• If the default image is lower than R82.00.10 B998001654, the gateway is affected and should be updated. 

2) Verify the current firmware version:

• For each affected GW, make sure the currently running image is R82.00.10 B998001654 or higher.

• If the GW is running an older version, please upgrade it to R82.00.10 B998001654 or higher.

• R82.00.10 official SK: SK184357

3) Update the default image:

• Run the following command via Shell: “update default-image from current-image preserve-settings yes|no”
• Important note - running “update default-image from current-image” command requires a reboot of the system, and therefore an outage window.

4) Verify the default image:

• Make sure the default image version matches the current running image.
• In WebUI, go to Device → System Operation → Revert to Factory Defaults section:

• In CLI, run “show diag” command

• Alternatively, check the DR Spark Dashboard after 24 hours, as the information should be updated within 24 hours.

Please make sure this is addressed for all affected GWs to eliminate the risk of the device entering Maintenance Mode following a factory reset.

See below the relevant SK for cases where the GW has already entered Maintenance Mode:

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

LMK if you have any questions,

Noa Alon,

Spark Firewall (SMB) , Project Manager

[mwakenell]

Noa and all,

In the instructions above, you should let people know that the command in step #3 does take the appliance down for a reboot and should be done in a maintenance window.

[perfect4situa]

Does this solution apply also to non 2500 gateways?

In sk184357 - Spark Firewall R82.00.10 the command “update default-image from current-image” is not reported as solution for Appliances: 1535 / 1555 / 1575 / 1595 / 1575R / 1595R / 1600 / 1800 / 1900 / 2000.

[Noa_Alon]

In R82.00.11, this solution also applies to 1535, 1555, 1575, 1595, 1575R, 1595R, 1600, 1800, 1900, and 2000 appliances. The command is supported on these appliances.

In R82.00.10, this command is not supported. However, the default image for these appliance models is usually valid and does not include this issue.

[perfect4situa]

Hi Noa,

I tested the command in a lab environment using a Quantum Spark 1535 running R82.00.10 Build 2325, and I can confirm that it worked correctly. After execution, the firewall's default image was successfully updated to the current firmware version. 

There is one point I would like to highlight, though: executing only "update default-image from current-image" is not sufficient, as the command requires the additional parameter: "update default-image from current-image preserve-settings yes|no".

During testing, the command was accepted and completed successfully once the preserve-settings parameter was specified.

What is not entirely clear to me is the exact behavior of the preserve-settings option. Is it comparable to a snapshot mechanism, meaning that the resulting default image will retain all device configuration and settings, making it suitable for a full restore scenario? Or does it only preserve a specific subset of settings?

I reviewed the documentation, but I could not find details describing precisely which settings are preserved and which are not:

https://sc1.checkpoint.com/documents/Appliances/Quantum_Spark_R82.00.X/CLI/EN/Content/Topics/update-...

Could you please clarify the intended behavior of the preserve-settings parameter and what data is actually retained when it is set to yes?

One additional question: since the command worked correctly on a Spark 1535, which is not explicitly mentioned in the documentation, what should I conclude from this? Is the list of supported models incomplete, or is the command actually intended to be supported on all Quantum Spark platforms running the appropriate firmware version? Could you please clarify this point?

Thank you

[Alex-]

I've noticed that too while working on a few systems, and my understanding is that after the reboot required to change the default option, you get asked this question to see if you want to keep the system as-is with the parameters or not, since you might come from R81.10.17 for instance, or start from a blank slate.

I haven't tried an FCD from a system where the default was set to R82.00.10, but it would be strange to have the factory reset keep all settings, if you would need to move it between projects, recover from lost credentials or other situations which would require FCD.

[perfect4situa]

Hi Alex,

From what I understand, a factory reset is different from a revert to a previous image and also documentation it's not clear because the documentation show 3 cases but GUI only show two (Restore and Revert vs Default Settings, Factory Defaults and Revert to Previous Image) (Backup, Restore, Upgrade, and Other System Operations).

I'm not familiar enough with the implementation details to be certain, but it sounds similar to how Linux kernel upgrades work: after an update, the previous kernel remains available and can be selected at boot time as a rollback option if issues occur. Another comparable example is the dual-boot design used by many network devices, where two firmware images are maintained and the device can switch back to the previous one if needed.

That's why I find the "preserve data" parameter particularly interesting. To me, it suggests more of an image rollback process than a true factory reset.

It would be useful to get official confirmation to make sure we're interpreting the behavior correctly...

[BAlexiev]

If you select to install a custom default image, you can also preserve settings, policy, SIC, or
the license as part of the default image.

If you configure the value of "preserve-settings" to "no", you can only preserve the SIC
and license.

From the Spark Centrally Managed Admin Guide, section Custom Default Image
R82.00.X Spark Firewall Appliances Centrally Managed Administration Guide

There is a pointer to the document you cited, where it explicitly states you are asked:

Save settings as part of the image: yes

Save license as part of the image: yes

Save SIC as part of the image: yes

However, this information is incorrect for the current recommended R82.00.10 version. If you select "no", the response is "No settings will be saved as part of the image". If you select "yes", all cited settings above are saved and the only question is whether you want to continue, no further options.

Thank you for pointing out the additional parameter!

@Noa_Alon As the CLI command itself does not mention it, it would be nice to update the initial post and also the command in the clish. An update to the documentation to reflect the current behaviour (at least in R82.00.10) would also be nice.

> update default-image from current-image
Press ENTER to update default image from currently running image

[perfect4situa]

Thanks for the clarification. This could be a real game changer in firmware upgrade management and in the investigation of version-related anomalies.

I believe these concepts should be reflected more clearly in the official documentation, as they can significantly improve administrators' ability to perform rollbacks, plan upgrade paths, and troubleshoot issues more effectively. Clearer guidance would help avoid confusion and reduce the time spent investigating gaps in the documentation.

In addition, it would be beneficial to explicitly clarify whether devices outside the 2500 series are also affected by the default image behavior when the default image is set to R82 (affected builds). If this is indeed the case, the documentation should clearly state that the related command and verification procedures apply to those platforms as well. Such clarification would remove any ambiguity and help administrators correctly assess upgrade status and version discrepancies across the entire Spark product line.

Thanks again for shedding light on this important detail.

[Noa_Alon]

Hi,

As mentioned, this issue with an invalid default image is also relevant to the 1535, 1555, 1575, 1595, 1575R, 1595R, 1600, 1800, 1900, and 2000 appliances. However, the likelihood of encountering it is lower because the default image shipped from the production line is typically R81.10.x (without this issue) or R82.00.x (with the relevant fix).

Regarding the update default-image command, I have updated the full command in the initial post.

Also, please note that for these appliance models (1535, 1555, 1575, 1595, 1575R, 1595R, 1600, 1800, 1900, and 2000), the command is supported only in R82.00.11. It is not supported in R82.00.10.

We will update the documentation accordingly.

Thanks,

[perfect4situa]

Hi Noa,

Thank you very much for updating the post. I think this information will be extremely useful for the community.

One comment from my side: I am also applying the update default image command on the 1535, 1555, 1575, 1595, 1575R, 1595R, 1600, 1800, 1900, and 2000 models. In my opinion, it does not make much sense to keep an R81 default image, especially since some of these devices had already been upgraded to R82 with USB install procedure and therefore already had a newer default image (without hotfix).

Does this match what you have seen as well, or was it just a special case that I was able to successfully use the command on devices running R82.00.10?

Thanks again for the update!