High End Check Point appliances, digging further

In my previous post I have asked you about origin of Check Point 61K and 41K chassis. Before continuing this discussion please let me explain why I am digging into this.

The main reason is that Check Point does not provide enough information about the hardware specs of the appliances. Customers apparently should be happy just with security power indicator. Basically Check Point tells us: trust our sizing tool, we will present you with the right box for your throughput and particular combination of your security features.

This does not work 100%, there are always issues with border customer cases, wrongly assessed requirements and missed functionality.

Treating appliances as black boxes does not help to built the trust. How do we know if the box is powerful as announced? With high-end boxes there are even more bottleneck that with regular appliances. Thus more questions.

The second reason is about my personal preferences. As an engineer I like taking things apart to see what is inside. Design and capabilities: these are the points I want to be sure about.

If you seem this too much, it is okay, you can stop reading here and get back to your own toys. If you are with me, I want to share some of the findings.

------- read below this line if you are still interested -------

In the comments of the previous post someone has put a link to ASIS, a company with less than 200 employees, according to its LinkedIn profile. The company has two addresses in Israel and USA. US address apparently belongs to a small sales office.

According to my anonymous reader,  this company is producing the chassis for Check Point. Indeed, their Perform 140 and Perform 60 chassis look very similar to 61K and 41K, without SSM and SGM blades.

Now, what about the blades?

I did not find anything that would look like SGM or SSM on Asis web site.

So far I am assuming Check Point is using Advantech MIC-5333 or MIC-5332 ATCA modules as SGM blades.

Unfortunately, I did not found the Switch modules (SSM) on Advantech site. Advantech only lists a single Switch Module for ATCA, ATCA-9112, which looks a bit different than the switch blades used on 61K or 41K.

Strangely, on marketing photos of Advantech ATCAs that I have already cited in the previous post, switch modules look exactly as Check Point ones, except for the colour, although it is listed as ATCA-9112. Could be that these marketing photos were done with older modification of the blade. So far I continue searching for the definitive proof.

If you have any further information to share, please do so. On my side, I will keep you posted about news for the matter.

Who is making Check Point High End chassis?

The full name of Check Point includes Software Technologies in the title. It hints that Check Point does not produce its own appliances. And who does for that matter?

One question is bothering me for years now: who is making Check Point 61K and 41K chassis? I have never got a straight answer on it from CP itself, not even a hint.

But just for sake of argument, take a look onto Advantech Advanced TCA boxes:

Do they look almost like 61000 and 41000 from Check Point to you?

Granted, it is not 100% match. The smaller chassis even have 41K composition up side down. Could it be that Advantech is producing custom HW for Check Point? Or could it be that Check Point uses just some of the components such as frames and fan blocks, but the blades are done somewhere else?

I wish I know the answer to this.

What do you think? What do you know?

Renaming global objects cause CMA migration to fail

I have recently discovered rather unfortunate situation with Multi-Domain Security Management servers. If you have ever renamed any of the global objects in the global policies, you cannot migrate CMAs anymore.

This sounds strange, but it is the fact. With R77.x cma_migrate script will fail on the target machine if at least one of the global objects was ever renamed.

Check Point has a rather vague SK article about it, and the only proposed solution is to request a hotfix. Mind this article is only referring to R77.10 version, although the issue is present on R77.20 and potentially on R77.30.

It seems cma_migrate is running re-upgrade verifications and fails if gdb_rename table is not empty.

I can only guess if it was done intentionally or not, but there is a history of other issues with renaming global objects on MDSM.

For example, with R75.40 it was impossible to rename a global object, unless a particular system variable was changed (SK82380). One more know issue was about upgrading R76 MDS to R77.10 
(SK98793).

Considering all above, the only recommendation is: do not rename global objects to avoid any of the described issues.

Check Point release map for R7x

In case you ever wanted to have a summary of Check Point recent releases, dependencies, brief "what's new" info and further links, Check Point release map document is what you are looking for. On its 8 pages you will have it all, including links for more details, upgrade maps and backward compatibility maps' links.

Of course, you need a User Center account to download this doc. 

Check Point support plans - quick guide

One of the most challenging things about Check Point is not about technical issues. It is about understanding support processes, getting the right attention and choosing the right support program for one's cause.

I have compiled a short guide to help you in understanding and navigating the support plans and SLAs. Unfortunately this guide is cannot be put into a blog post. Nevertheless you are welcome to read it on my google drive. Here it is.

If any question, comment or correction, do not hesitate to comment down below.

Indeni calls for technical authors with expertise in Check Point, F5 and PAN

Indeni never stops to amaze me, guys.

They always do something nobody though about. First, in-depth preemptive monitoring of your critical security and networking infrastructure. I was covering this in some of my previous posts, if you remember.

Now it is something else, simple and yet amazing. Here we go:

Indeni will pay you for technical articles about Check Point, F5 and Palo Alto.

Yes that's right, you can write and article and get paid up to $200 per piece. That is no joke, just go by this link and see for yourself.

I wonder if I should just repost most of my blog there. Okay, that part was a joke :-)

Now seriously, if you have something to tell the community, today you also have an opportunity to make some money out of it.

Anyhow, if you are just curious about the company itself and about what they are up to, feel free to sign up for updates and news any time by this link.

And good luck with your new technical writing careers.

Curious story of VSX Management bundle

Once upon a time there was something called VSX Management Bundle for multi-domain management servers.

Licenses with SKU like CPPR-VSX-CMA-CX were allowing people to manage X Virtual System on any kind of Provider-1. The beauty of these license was all about flexibility. It only defines how many VSs one could manage. It does not limit you to particular number of Management Security Domains (CMAs in old terms) and/or number of security gateways per domain, as long as you only manage Virtual Systems and not physical firewalls.

Even more interesting, this bundle was able to extend the original amount of CMAs in the container with Provider-1 NGX licenses.

Let be me more specific. Say, you have MDS with a container for 10 CMAs. Normally, with physical GWs you would not be able run more than 10 CMAs. But after adding CPPR-VSX-CMA-C25 licenses to MDS one could spin out up to 25 CMAs for VSX management. It was also possible to manage multiple VSs from the same CMA. The only thing that mattered was the total amount of managed Virtual Systems and nothing else.

This is all history now. If you look into Software Blades price list, there is still something there called VSX Domain Blade: CPSB-DMNVSX. It allows you to run a CMA that could manage a single Virtual System.

At first glance, this sounds quite similar to the old NGX bundle model. Now you just need to purchase a bunch of VSX blades to run as many VSs as you want.

Well, not exactly. The main limitation for the new VSX blade is that it allows your Domain Management Server to manage just a single Virtual System. Just one. And it is not additive. You could not add two of those blades to the same CMA to manage a couple of VSs.

So if you want two or more VSs in the same domain, You have to jump to 10 GWs domain (CPSB-DMN1000). Why 10? Because as Check Point counts as GWs physical nodes, with 2 Virtual Systems in a cluster your count spikes to 4 GWs to manage.

CPSB-DMN1000 is 5 times more expensive than CPSB-DMNVSX.

I do miss NGX VSX management bundle. It is a great blow that flexible and inexpensive bundles are no longer available.