Thursday, June 25, 2015

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.

Thursday, June 18, 2015

Categories for Check Point URL filtering

If you are planning to start working with Application Control and URL Filtering functionality on Check Point firewalls, one of the main challenges is architect the organisational policy. You need to know what are the categories you can use and understand what they mean.

In other words, you need the list of categories and explanation for it. Surprisingly, on the product page for URL filtering there is no such link. No worries, it is still available here.

Wednesday, June 17, 2015

First quarter results: Check Point growth is still slow

Cleveland Research has released financial analysis for the main security vendors, following reported Q1 results.

There is also prognosis for the rest of 2015, see in the table below.

Revs ($000s)
Palo Alto*
*PANW report one month off calendar Q

As you can see, Check Point market share remains the largest among the FW vendors, with the slowest growth.

Interestingly, Check Point maintains the highest gross and operating margins (87.7% and 58.7% respectively). In comparison, Fortinet's margings are 70.7% and 16.4%, Juniper's are 61.3% and 21.9%. Gross margin for FireEye is 62.7%, operation margin is unknown.

Some could say, Check Point "high price, low cost" policy works out for its margins just fine but does not help its market to grow faster.

Tuesday, June 16, 2015

Latest Chrome versions breaks SNX, workaround available

Google has dropped support for Netscape Plug-in API in the latest versions of Crome browser. In case you are using Java-based SNX as part of your SSL VPN, and Chrome is the default browser, SNX will no longer work for you.

As a workaround, you have to re-enable NPAPI in the browser. More details are available in SK106021.

It is unclear if Check Point has any plans to change SNX to resolve this issue completely in the future releases.