cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Highlighted
Nickel

Loss of functional parity

Why does it seems that every new CheckPoint release is missing some major potion of the functionality that was present in previous versions?

We are running an R77.30 cluster for our Internet facing firewall. On that cluster we are running most of the Threat Prevention Suite including HTTPS inspection, Threat Extraction and Threat Emulation. We have been "in the process" of upgrading the cluster since September.

Every time we settle on a target version, we get just about up to implementing it, only to discover that the target version is missing some functionality that we really need.

We were quite close to taking the cluster live on R80.20 back in February, but ran into some networking problems the night of go-live and reverted back to R77.30. It turns out that was a good thing, as we informed a few days later that the SNI hot fix, which I had already requested, was not available for R80.20 and there was no plan to provide it. We really need the SNI hotfix. We had to turn off Probe Bypass because it does not support SNI sites at all, even if the site does not actually use or need SNI. Without Probe Bypass, HTTPS Inspection is not as nicely implemented, and we suffer a slow roil of frustrated users and automated processes whose first connection to a site fails, since the HTTPS inspection engine must inspect the first connection in a 24 hour period to tell if it should inspect or bypass inspection. If the site is on the bypass list, the first connection fails as it had to be inspected in order to tell.

The word in February was that there was no plan to provide the SNI hot fix for R80.20, even though it had been out for some time for R80.10. We were told to either use R80.10 or wait for R80.30, which would be out really soon now. R80.30 would have the SNI hot fix baked in.

So, for various reasons, it turned out the next time we could attempt to implement a cluster upgrade would be the end of May. My boss told me to plan for R80.10 for that date, so we could get the SNI hot fix. In the meantime, R80.30 finally was released to GA.

The new features list for R80.30 is impressive, and it turns out we really need one of those features: R80.30 finally supports the full gamut of encryption protocols for TLS 1.2. We have been seeing a fair number of sites are configured to only allow these new R80.30 supported encryption protocols. I don't know if the sites are misconfigured, or if they know something that I don't, but I do know that we have had to write a number of HTTPS Inspection Bypass rules because these protocols have not been supported for HTTPS Inspection until now.

So crazy me, I read through all the Release Notes and Limitations and a bunch of other R80.30 docs and then convinced my boss that we should move everything to R80.30. I mean, we still had two weeks left until the scheduled upgrade date: Plenty of time to re-image the new servers and use the fail over management system to upgrade to R80.30 management as well.

So, I was pretty aghast when I found out yesterday that the Mobile Access Portal hot fix, sk113410, is not available for R80.30. The Mobile Access Portal is the front end to the SSL Network Extender, which we use for external vendor and employee access to our internal network. Over half of those users are using browsers other than Internet Explorer. That's a real problem, because without the sk113410 patch, the Mobile Access Portal only supports IE on Windows. There is no mention of this lack of an sk113410 patch in the R80.30 Limitations document. The SK article for sk113410 was updated yesterday, after my call on the subject to CheckPoint TAC, stating that there would be no hot fix for R80.30 until Q3 or Q4 2019.

Look, I understand the software development cycle and the need to fork the code somewhere in order to start on the new version. But when you have added functionality in widely used hot fixes already available for prior releases, it seems to me you should either plan to incorporate the hot fixes into the forked code base, as they did with the SNI hot fix for R80.30, or develop a version of the hot fix for the new version before general release.

I am so frustrated with CheckPoint right now.... I had to go back to my boss and explain that we would not be able to go to R80.30 after all. So, now were are back to R80.10 for our end of the month upgrade. I sure look stupid. My boss' comment was: "Why do they keep doing this? I don't remember ever having similar issues with Cisco or Palo Alto firewalls at previous jobs."

Why does does CheckPoint keep releasing new versions without functional parity with prior releases?

 

 

8 Replies
Highlighted
Employee+
Employee+

Re: Loss of functional parity

1. We appreciate the honest dialog even though its not easy to read

2. I will try to give direct answer to release content (not ignoring all the rest of bad experience you had)

3. EVERY forward release support all official content up to certain date, of the previous release with one exception (see #5). So if last week we took off r80.40 from r80.30, everything from that date is included in the “basic” of r80.40. We then add additional content that is ready for main train. 

4. MABDA was “side fix” - not included in jumbo or GA and not as part of r80.20. When we closed the content for r80.30, it wasnt yet ready for maintrain and therefore wasnt included in r80.30. 

We will have it in r80.40 and in parallel work to include it “side fix” of r80.30 too 

Release notes will include feedback on formal content and new things added and not list all the side fixes we have. Users know when they are on side fixes as the version is special and standard install on top of it will be prevented. 

5. Last - sometime we do reduce content due to tradeoff but that happen when we do major component rewrite. So initial r80 wasnt feature compatible to r77 and r80.20 ga do not include VPN LS due to the major integration of scalable platforms. These cases are handled very carefully, well documents and we try to prevent user error by pre upgrade validation 

 

I appreciate the open dialog 

Dorit 

 

Highlighted
Pearl

Re: Loss of functional parity

@Dorit_Dor , perhaps it will benefit everyone if the validation of functionality will be either included in  CPUSE verifier or provided as a separate tool.

Frankly, hunting down SKs describing functionality limitations when planning non-major version upgrades feels like forensic discovery.

Analysis of existing active (configured) features and description of limitations pertinent to each environment could be presented in the report.

Every "not yet supported" item could then have a "subscribe to notification of status change" checkbox.

Once users subscribe to those, they will receive the status changes notifications as soon as Check Point releases them and the updated report will be generated.

Once all the critical requirements are addressed, upgrades could be scheduled and undertaken.

This will save the tremendous amount of time for your clients, engineers, TAC and R&D by providing metrics for the features in demand, issues that impede rapid transition to the new GA releases and help with focusing development in a much more efficient manner.

Regards,

Vladimir

 

Highlighted
Employee+
Employee+

Re: Loss of functional parity

Dear @Dale_Lobb ,

I’m a manager responsible for development of MABDA functionality. We value feedback from our customer and in response to many requests, we have changed release schedule for MABDA hotfix on top of R80.30. While public release is planned for July, we can provide you custom build in the 2nd half of June. The next major release R80.40 will have MABDA functionality baked in.

Please contact me directly for further communication.

0 Kudos
Highlighted
Employee+
Employee+

Re: Loss of functional parity

Hello,

I'm glad to inform you that we have found an opportunity to prepare out-of-schedule release of MABDA hotfix on top of R80.30 Security Gateway. Starting from today it is available for download. Please refer sk113410 for more information:

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Highlighted

Re: Loss of functional parity

Yes - now we finally have MTA 27 and MABDA HFs available for R80.30.

Highlighted

Re: Loss of functional parity

Just a word of warning: Both MTA 27 and MABDA HFs install if downloaded from the cloud. Currently, the download from the SKs for both fixes misses the metadata file and can not be installed. I have given this as feedback to the SKs so this will hopefully soon be corrected😊

0 Kudos
Highlighted
Pearl

Re: Loss of functional parity

Thank you for getting it to us earlier!

0 Kudos
Highlighted
Nickel

Re: Loss of functional parity

Thank you.

0 Kudos