Has anyone else had issues getting Checkpoint support to acknowledge an issue as one that needs to go to development or at the very least, referred to whoever maintains the documentation and SK articles?
I have three open cases, well I guess two now, as one was closed this morning, where I have found what I consider to be either bugs in the software, or erroneous documentation. But CheckPoint support seems to be totally focused on finding work-arounds to the issue rather than gathering data and fixing the problem.
Case #1: SK81740 purports to be a method for receiving e-mail notifications when ClusterXL fails over to another node. Except it isn't. The method described in the article sends notifications when a cluster member's ClusterXL status goes up or down, which does not necessarily (and actually, rarely) coincides with fail over. I've pointed out in the ticket a number of times that either the SK is wrong and needs to be updated, or if the SK actually reflects what is supposed to happen, then the software was implemented incorrectly. But Support is totally focused on providing a work around, not fixing the problem. They've pointed out SK65923 a number of times, which is a method for providing log events to an SNMP management system, from which you could have the SNMP system issue an alert. Before I go to that level of complexity, I'll write a simple bash script using "cphaprob state" and have it send an e-mail...
Case #2: Changes made to the HTTPS inspection policy are saved automatically without prompting if you close the R77.30 SmartDashboard using the windows close widget (the X in the upper right hand corner), while the HTTPS policy is displayed. As near as I can tell, all other screens issue a prompt to ask if you want to save your changes in this scenario, even if the changes were made to the HTTPS inspection policy but one is currently on another SmarttDashboard screen. Recently, a newby firewall admin accidentally left a default any-any-internet-inspect rule at the top of the HTTPS policy because he thought that closing the window would be good enough to erase his experimentation as he is learning the SmartDashboard. When the rule finally got pushed out with some other changes a couple of hours later, it resulted in an major issue for a great many users and applications. But Support seems to think that this is a desirable feature, as R80 and above gives one the ability to discard all changes as a failsafe. The work-around here seems to be: upgrade to R80 or above.
Case #3: Apparently there a nebulous set of circumstances (policy rules) that can cause a gateway to perform pre-probe bypass inspection, even if probe bypass is turned on. We have discovered one of these scenarios as we are having occasional issues with HTTPS inspection returning a firewall signed temporary certificate to a client, even though the Tracker Logs show HTTPS Bypass as the result of inspection for the session. Support has shown where if we use the built-in applications for the HTTPS inspection bypass rule, rather than a custom application object built from the certificate subjects expected, then probe bypass works as documented. However, I told them that we have had issues using the built-in objects, as they don't always work to prevent HTTPS inspection or allow access in the Application and URL filtering policy. My guess is that they aren't always up to date as the internet services are constantly changing. However, since customer have no visibility into how the built-in apps actually work and what they are looking for, we have chosen to use custom built applications, especially in the case where the built-in app has failed at least once before. After pointing this out to Support in the case, I was told that if we choose not to use the built-in apps, we will have to live with the situation as it now exists.
Why isn't Support looking to actually fix these issues?
