R82 for Quantum Spark is a Mess

[sx8n20394]

I have been incredibly disappointed in r82 and the 2500 appliances. We have had so many issues that I almost cannot take it anymore. I have opened more TAC cases in the past couples weeks then I have in the past 10 years of using the Quantum Spark line.

Top Issues (All running R82.00.10 Build 998001562)

1. Regular WAN Failover (no SD WAN blade enabled) and WAN Failover with SD WAN enabled don't fail over internet connection properly. It will randomly just tear down both WAN connections and cause my customers to go down. When it did fail over properly (one time), nothing on the network could communicate out. It also didn't fail back over to the primary without rebooting the firewall. The logs said that both WAN connections failed probing 20/30 packets and that was why they both tore down at the same time. I don't see how that is possible. I have never ran into that in a decade of using Checkpoints along with random Fortigates, WatchGuards, etc.

2. SecureXL dropping traffic for no reason. We were forced to make a ton of exemptions in SecureXL Advanced Settings to get through a week for one customer. Eventually we just factory reset the firewall. It has been fine for now...

3. Network speeds dropping for no reason. We replaced an 8 year old Barracuda with a new 2570 and all the customer does is complain about network speed now. I have no idea what to even do in this situation considering the new 2570 has 4x the throughput of the original Barracuda firewall.

4. Random Database Corruption. Had a brand new 2560 lose the ability to apply policies, add new network objects, essentially do anything. Had to factory reset.

5. SSL Inspection not identifying devices properly. We set it to just inspection computers (laptops, desktops) and it still scans mobile devices. The mobile devices are being properly identified in the GUI as iPhones, Android, etc.

There have been many other issues but those are the main ones. Checkpoint needs to get their act together because my setups are not very complex and I should not have to pull my hair out trying to get basic functionality to work. I have opened many TAC cases and really never got anywhere with any of them. Two resulted in factory resets, the other is a work in progress with trying to make the basic WAN failover work without taking down the network for 10 minutes.

I am wondering if anyone is having the same amount of issues we are.

[EDIT]

I do want to add that Checkpoint has been extremely responsive regarding all of the issues we have been having. According to the Level 3 TAC Engineer I have been working with, R&D have identified the causes of some of these issues and are working diligently to get them resolved.

[israelfds95]

I truly hope TAC and R&D can help bring clarity and solid resolutions to what you’re seeing. If you can share more details, it may help the community (and TAC) correlate patterns — for example: exact R82.00.xx build,centralized vs local management, WAN monitoring/probe settings, and SecureXL status.

I was genuinely hoping the new 2500 models and R82.00.xx would be a clear step forward in overall maturity and day-to-day operational stability. The SMB segment deserves the same level of reliability and consistency we typically expect from enterprise Gaia-based platforms.

From an implementation standpoint, stability must come before feature expansion. Advanced capabilities are valuable, but predictability under normal production conditions is fundamental.

In scenarios where an appliance unexpectedly reboots, or drops traffic in ways that are not aligned with expected configuration or inspection logic, or behaves inconsistently in basic networking flows, the impact goes far beyond technical inconvenience, it directly affects business continuity and customer trust.

I believe the platform has strong potential, but long-term credibility in the SMB space will depend on prioritizing robustness and stability above rapid feature growth.

I’ll be deploying multiple projects this year using the new models and R82.00.xx, and I’ll share my observations and updates as I gain more field experience.

[sx8n20394]

All devices are r82.00.10 Build 998001562. Locally managed and connected to Infinity Cloud Services for logging and configuration backup.

Probing settings are set high right now because I have no choice or else the connections just drop every hour or so. In some cases it doesn't even matter. The strange thing is that on two separate firewalls, the probing fails (lets say 24/30 packets) on both WAN connections. I highly doubt both WAN connections are failing probing at the same time with the same amount of packets when they use different ISP routers.

I can deal with most issues but the one thing I need to work flawlessly is the WAN remaining connects and failing over properly.

[israelfds95]

Did you try using the recommended Firmware R82.00.05 Build 998000913? Or did you go directly to the Latest Firmware R82.00.10 Build 998001562?

[sx8n20394]

Level 3 TAC told me to go to r82.00.10 Build 998001562 so I put all 4 devices on it. At the time, 3 of the devices were not deployed yet.

[israelfds95]

I understand, I have a project with more than 30 SMB 2550 to run, I wanted to install the Latest Firmware R82.00.10 Build 998001562, now with your report, I will try to start with the R82.00.05 Build 998000913. I hope it works properly and remains stable in the environments.

[Amir_Ayalon · Accepted solution]

Hi

Thanks for the feedback, we appreciate it and taking it very seriously.
Technically, we would be happy to look over the issues and assist (R&D), so please contact us directly.

Nevertheless, we have thousands of 2500 firewalls deployed and we do not see unusual support ticket count or telemetry, on the contrary, feedback so far is very good.

As you are aware, we had an hang issue over heavy load, but this impact only Pro appliances running R82 and not the 2500 series. (Fix firmware was published)
And we have the CRL issue which is a MT issue (SK with the solution is available)
As for the other issues you describe - i don't want to get into too much technical details because we need to look into TAC SR's but some seems like configuration issues (like WAN probing, or SSL & Device recognition) , so again, i suggest you drop us a mail so R&D can look into it,

amiray@checkpoint.com

ohadp@checkpoint.com

Thanks

[ohadp]

Hi sx8n20394

I’m sorry to hear about your experience. I take this seriously and would like to personally review your case.

Please contact me directly with your SR number and details of the issue, and I will make sure it is handled properly.

ohadp@checkpoint.com 

Ohad

[henfii]

Hi,

I have several Spark 2500 firewalls deployed locally and the issues go back to the first version R82.00.00. I also agree that I have opened more tickets recently than in recent years. We prefer Check Point as MSSP for our SMB customers, but I have been really concerned recently about offering more Spark 2500s to customers due to issues that have occurred on many GWs that our management has already noticed and the issue of changing vendors has already been raised by them - I believe that we will avoid this.

So far, we've managed to keep our customers tolerant, but we also have cases where there is anger on the customer's part.

It looks like the bugs are gradually being fixed with new firmwares, but there are firewalls where I am still afraid to do anything and I am waiting to see if something else breaks again with the new firmware and if the upgrade will really go correctly (critical environment).

1. I had a problem with the cluster breaking up at random intervals, which happened from R82.00.00 to every newer version (this was probably solved in build R82.00.10 1559), but the problem with the VPN still persists, which usually works for 5-7 days and when loading the VPN client, the loading ends at Downloading Topology 52%. In that case, only a restart of both cluster nodes helps, it is not enough to restart only the active one, you need to restart the standby on which it behaves the same. This has been happening since the first deployed version R82.00.05... and I am honestly afraid to update higher than 1559 to a newer build. However, a few days ago another problem appeared (Cluster status change), Reason: Incorrect interface configuration, Reason: Interface is down (Cluster Control Protocol packets are not received which flaps every day several dozen times. - maybe it's related to connecting the second cable to SYNC to the first one which we did recently but I haven't solved it yet... the recommendation for those VPNs from TAC is still to update to the provided build 1629 as "more stable", but there was no technical window yet and we'll see what it will do with SYNC BOND between firewalls...

2. On another firewall again problems with the client VPN, which always worked for only a few days and then the error message "Site not responding, You may be in a hotspot environment" appeared. Added to this was the fact that behind the company's firewall some URL pages stopped loading, which probably fell into some allowed URL category and generally probably a crashing URL/APP Control blade. Added to this were web server error messages (according to TAC it was a corrupted database) in the graphical interface. It looks like the Build 1629 delivered by TAC support has solved it for now, as well as the VPNs. (I hope, it's been working for more than 2 weeks now 🙂 ).

3. On another firewall that was recently delivered to a customer for 2 locations, I'm missing application and traffic data in the Monitoring, Reports section on both - it's empty, even though the upr/app, fwl, etc. functions are enabled (so far on R82.00.05 Build 913, which is recommended, we don't know if we should install GA).

4. on another firewall VPN client, which did not want to work with automatic domain topology and I had to define the domain manually (it worked normally on the machine for 3 days, then after dialing I simply could not get anywhere and I had to manually define the VPN topology, even though they were LAN subnets. On build 1562 it did not work from the beginning after replacing the firewall at the customer, they connected the original one back, we downgraded to 1559 where it supposedly worked, we connected at the customer, it worked there for 3 days and again the same problem, TAC temporarily solved it by manually setting the manual domain topology as a workaround). Yesterday I upgraded it on the given GW to build 1629, which I received in another ticket and I will do it in the next few days, when the technical window with automatic topology will be tested again.

I still have a few tickets open, but we didn't have a clear solution anywhere and everything revolved around sending cpinfo, backups, remote sessions, dr. sparks, logs, then trying this firmware, etc. and sending cpinfo again. There was no such thing as "we know about this problem and this is the fix" and with these tickets I sometimes felt like I was the first to report the problem...

So I believe that each subsequent firmware will only be more and more stable and we won't be afraid to connect or upgrade the given firewalls.

---

As for the Spark 15x5 Pro... it was a disaster. But we already know about that and I'm glad that we solved it anyway, even if it sometimes meant longer downtime, traveling to the locations and clean install of the older FW from USB and restore config or with the help of a really really helpful TAC who tried to help me as much as he could with new firmware or workaround commands on 15x5 + R82.00.10

[israelfds95]

Your input is extremely important, especially given the breadth of field experience you’re bringing, and it connects directly with what has been discussed so far.

I’ll be deploying multiple projects involving a significant number of SMB appliances from this new line running R82.00.xx, and naturally, I’m concerned about potentially encountering similar issues to those experienced in earlier builds.

I believe this open discussion can provide valuable visibility into the current state of the solution, as well as highlight critical areas for improvement.

It may also be beneficial to proactively reach out through the email contacts @Amir_Ayalon @ohadp  that demonstrated strong interest in reviewing these cases in more detail.

[Deki]

This is concerning to hear as we run about 100 R81.10 SMB devices in our deployment. It's always been a hassle since they are nowhere close to as reliable as GAIA platforms but it was manageable. Hopefully they manage to work out the bugs on the 25XXs prior to the 15XXs going EOL. 

[Steffen_Appel]

The 15x0 have EOL in 2030, the 15x5 have no EOL so far.

[Oliver_Fink]

But there is end of support for R81.10.X on 15x5 in July 2026. After that only R82.00.X will be supported. (EoS for R81.10.X for 15x0 is January 2030.) Origin: Support Life Cycle Policy, Software

That is a complete mess in a mixed 15x5 and 15x0 installation I have at a customer. And I do not understand why it is not possible for Check Point to support R81.10.X for the same time frame on 15x5.

[Amir_Ayalon]

Hi Oliver,

The upgrade path for the 15x5 series to R82.xx.xx is designed to ensure users can access the new features and capabilities we’ll be releasing over the coming years. Because the 15x0 hardware has more limited resources, it isn't equipped to run R82 effectively and will remain on the R81 branch instead.

Since the R82 code base is the foundation for our future development, most new enhancements simply won't be compatible with the older R81 branch. Developing for both isn't just a matter of resources; in many cases, it’s technically impossible. That said, if you prefer to keep your 15x5 on R81.xx.xx, you certainly can. While you won't get the latest features, we will continue to provide full support through bug fixes and security updates.

[Steffen_Appel]

Sounds good, but as long as the lifecycle shows, that the support on the 15x5 ends in 07/26 the TAC will probably ask to upgrade for any problem you might get.

[ohadp]

Hi henfii,

This seems like very important and meaningful information that we would like to review.

Could you please send me an email at ohadp@checkpoint.com so we can discuss your issues and review them together in a remote session?

It would be very helpful.

Thanks,
Ohad

[Greg_Harbers]

Hi,

We are now 6 weeks from your orginal posting. Where are things at for you? have the various builds addressed the issues you have experienced to the level that you are now comfortable with tthe 2500 platform or are you still having problems?

Thanks

Greg

[Amir_Ayalon]

Hi Greg

all issues were resolved long time ago, and a new R82.00.10 was published.

https://community.checkpoint.com/t5/Spark-Firewall-SMB/Quantum-Spark-R82-00-10-has-been-released/m-p...

If you still have any concern, please let us know.

Thanks

[Greg_Harbers]

Hi Amir,

As communicated to you via email, around 36 hrs ago we upgraded the first 2 of around 60 gateways that will need to be upgraded to R82 with the upcoming end of support date for R81.10.17 on 1555,1595,1800 etc appliances. Both systems were 1800 series devices. Less than 18 hours after upgrading one of them we experienced our first unexpected outage. We received alerts to say it was not responding to our montoring system, I was able to logon to the console, was viewing the messages file and then it auto-rebooted itself.
Correct me if I am wrong, but my understanding is that as a result all logs are gone (not that there was much in there anyway) so opening a TAC case will be unlikely to yeild much as we dont have anything to show them other than it rebooted.

As there is close to 400 users that go through this gateway, this has a significant impact on the customer's business and we can't afford to have random outages occuring, therefore should this happen again we will be reverting that gateway to R81.10.17 and put on hold any further upgrades until we have some surety that this is a stable release.

[Daniel_Toader]

hi, same problem with 1900, a i revert all 54 gateways with cluster at fw1_vt_dep_R81_10_17_996004721

likewise, after a certain number of days they froze

[ohadp]

Hi @Greg_Harbers 

We suspect a new freeze issue affecting 1600+ devices. We are currently investigating, and a new image will be released once a fix is ready.

In the meantime, if you experience freezes after upgrading to R82.00.10 (build 2133, Official GA), I recommend reverting to R81.10.17.

Please also share with me (or via the Support Center) the cpinfo and any debug data you’ve collected. I can provide additional deep debug steps tailored to your specific issue if needed.

Ohad
ohadp@checkpoint.com

[perfect4situa]

I fully understand the challenges Check Point is facing, and I truly respect the effort of everyone involved. That said, I would like to share my experience, which unfortunately mirrors many of the difficulties already reported by others.

Over the past months I have faced several serious issues with Quantum Spark (locally managed) devices, including:

1. the certificate expiration handling bug mentioned by Amir_Ayalon,
2. problems activating Cluster on Spark 2570 locally managed,
3. issues configuring VPN Client with Full Tunnel on Spark 2570 locally managed,
4. device freezes on 15x5 models, later acknowledged as a known issue, but which caused significant service disruptions and frustration across multiple remote sites.
   Now, with the upcoming EOL of R81.10.17—a release that itself has not always been reliable—I see similar anomalies still occurring, which is very concerning

My biggest concern is the long‑term unpredictability of these devices: issues that appear after months and require on‑site intervention, leading to major downtime for entire companies. My perception is that Gaia Embedded behaves like a converted version of Gaia OS with patches, and even Support often seems unfamiliar with its intrinsic behavior, which differs greatly from standard Gaia OS and appears far less predictable.

I strongly believe these issues must be addressed during development with much deeper testing. Customers must not act as a development environment. Quantum Spark devices offer good performance, but performance is meaningless without stability and predictability. I sincerely hope Check Point will invest heavily in making Spark platforms as solid and reliable as Gaia OS—otherwise, their value proposition is seriously compromised.

Thank you for the hard work, and for listening.

[Oliver_Fink]

I second that. One of our Spark customers is moving away from Spark to Meraki. From my perspective, Meraki is an technically inferior solution for the customer's needs. But the operational costs are so much less that technical aspects do not play a role anymore.

I sometimes doubt, that developers at Check Point know, that we are not all simply technical nerds that have fun playing with new features and equipment. The equipment has to do daily work you can rely on and to earn money for the customers and us. Each time we have to interfere with the equipment, they and us are earning less. And we have to interfere very much too often.

[israelfds95]

Honestly, unfortunately, the Quantum Spark line is disappointing. It presents issues that should not happen at a professional level. I cannot recommend the Quantum Spark line, because these problems have existed for several years—it’s not something limited to the current generation or recent firmware versions. It appears to be a chronic issue with the platform and its Gaia-embedded operating system.

They are not reliable and exhibit unacceptable problems, such as freezes or loss of access that only recovers after a reboot. Unfortunately, because of this, customers often end up replacing the solution with competitors.

It’s frustrating to defend a solution that does not meet expectations for reliability and quality. This should be a fundamental premise. While the Enterprise line has years of proven history and reliability, the Quantum Spark line has negatively impacted the perception of Check Point Software Technologies compared to competitors and ultimately affects the overall image of the solution.