Who rated this post

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