VSX provisioning tool

VSX is great, especially in combination with MDSM. Managing your virtual FWs directly form SmartDashboard is very handy.

The only caveat is that SmartDashboard does not allow you bulk changes on virtual systems.

Imagine you have 100 static routes to add. Doing in in the GUI, one by one, is a bit of a pain. What if there was an instrument that would allow the same, but faster and in one shot? 

Since this year, the solution does exist. It is called VSX provisioning tool. It is essentially an additional CPMI client that allows changing, adding and removing interfaces, static routes and Virtual Systems with VSX.

It needs to be placed on a Linux/Windows machine which has CP software installed (management or module), or even on a Windows machine with Check Point SmartConsole. It connects to the management server in the same way as SmartDashboard, over the same TCP port, and using the same username/pwd and permissions.

It has a replication of the logic of all the stuff SmartDashboard does when you edit/add/del a VS object. This logic is quite complex, which unfortunately means that you cannot, even if you try really hard, to accomplish the same thing with DBEdit.

Nowadays, if you are migrating from physical environment, Check Point or not, there is an easy and effective way to build up your VSX system.

The tool is available for Linux, SPLAT/Gaia and Windows. Both tool and its documentation are accessible through SK100645 at Check Point support portal.

I thank David Bar and Maor Elharar for their hard work to build the tool and assistance in correcting my mistakes in this post.

Special ATC discount for readers of this blog

Hi all!

I am glad to announce my ATC provides special discounts for readers of this blog for all courses available in 2015.

We provide 10% for the readers this year off the price list, for all standard and custom courses. If you are going to purchase multiple courses, you will get 15% discount on the second course. Courses will be delivered in our class in Crissier, Switzerland.

To see the schedule, go to our Web page and choose "Our courses" tab. To see details about the course, click to the course name link.

To register, use "Open" link for the desired course and fill the registration form. Alternatively, you can send us a message through the general enquiry form.

After registering, please add a comment to this post with your name and the course registration date.

For any further question or concern, please do not hesitate to contact me here in the blog or at LinkedIn.

Overriding default logging settings of FWs

In a distributed security systems, where remote FW modules can reach the central SMS both vian Internet and over private MPLS networks, central logging may become a challenge. With SMS behind NAT, FW will try to send logs to the external NAT-ed MGMT IP address. If Internet is not available, logging fails.

It may be necessary to allow logging both via Internet and MPLS, depending on availability. In this case, some manual changes are required.

Configuration steps

To override automatic log assignment, one has to perform several action both on Management server and on the remote FW.

On FW module

Log into expert shell on the FW module. Locate $FWDIR/conf/masters file and create a reserve copy of it as masters.old.
 Open file for editing with vi editor tool. Under [Log] section put both internal and NAT-ed IP addresses of MGMT server instead of the object name, as show in the following example (marked bold):

[Policy]
mgmt object name
[Log]
MGMT internal IP
MGMT NAT_ed IP
[Alert]
mgmt object name

Save and close the file.

On Management

Make sure MGMT DB is not locked by an administrative session. Open GUIDBEdit tool and log in to the Management station.

In the object tree, go to Network Objects / network_objects. In the Object Name window find your FW object to change. Use Ctlf-F3 to search, if required. Enter the FW object by double-clicking on it.
In the Fields window search for define_logging_servers field and change its value from True to False. Save database and exit GUIDBEdit tool.
Open SmartDashboard. Locate FW object and go to Logs tab. Make sure FW now uses local log server definitions.

Install policy on the FW.

Finding early symptoms of future issues with secutiy and network systems

One the most challenging tasks with security systems' monitoring is about health control. How do you know if the system is still okay before it fails? What things to look for? Free disk space? CPU usage? Disk operations statistics? Licensing? Number of RX/TX errors on its production interfaces? License troubles? Connectivity issues? This list can be endless.

I have seen a lot of home made solutions, some of them rather brilliant, all of them not covering 100% of potential scenarios though. Luckily for all of us, there is a unique solution available on the market today just for that.

That is Indeni. And it works not only with Check Point, but with other recognised security and network vendors too.

If you are interested to know more, click on the Indeni banner on the right ->
and sign up for free information updates.

I promise, you will not be disappointed.

Hardware diagnostics ordeal with 21400 appliances

Through a long and painful support process with one of my customers we have had to run hardware diagnostic tool on 21400 appliances with optical 10GB NICs.

It is supposed to be an easy tool to use. There is SK97251 describing the usage, and even the Administration guide for the tool.

But guess what?

First, the built-in R77.10 diagnostics did not work. When loading, it was crashing with kernel panic message. So we have resorted to the USB-based tool, as described in the SK article above.

The main point of the exercise was to check if any of the optical interfaces has a problem. We have spent 2 hours trying to make those tests.

The main problem is that the tool does not seem to know anything about these 10GB ports, and not so much about regular Ethernet ones either.

One is supposed to plug a loopback adapter to the tested port. As the tool is using non-standard interface names, it is blinking the port to test before proceeding. It seems the tool is calling interfaces almost randomly, not in accord with standard Gaia interface names.

Interface eth1-01 became eth0, eth1-02 - eth2. Port eth1 was not ever blinking, same for eth4 and many other interfaces on the way. Finally, eth1-08 became eth20. The funniest part is, if you are unable to identify an interface and were not fast enough to skip its verification, the whole test fails.

Obviously, no optical ports were ever blinking during the procedure.

I suspect our problems are actually described in the quoted article as

• On 21000 Appliances with SAM card, testing of the SAM card is not supported.

It is not really clear to me if these 10GB cards are in fact SAM or not. In the catalog they are marked as "acceleration ready", whatever it means.

I am pretty sure that Check Point support engineers were never running HW diag tool on 21400 with optical cards. I suspect QA never did either. I really wish they did. That would save me yet another Saturday spent in a datacenter. 

10GB bonded interfaces with jumbo frames, some notes.

Today, with new Check Point appliances, one can design a decent DC firewall. With multiple 10GB interfaces and bonds, one can fit Nexus network core throughput easily.

There is one caveat though. There are multiple known issues with 10GB interfaces on Check Point appliances, especially concerning bonding.

Firstly, there is an issue with LACP if jumbo frames are in use, described in sk86980. I have to say the solution is incomplete. For example, i mentions only three particular software versions, and mine was not listed there. 

Secondly, there is a stability issue with jumbo frames, mentioned in sk99113. 

Luckily, driver update from the second SK fixes LACP with jumbo frames too.

Amount of different versions that need patching (from R75.40 till R77.10, including quite recent R75.47) for the matter clearly shows that Check Point developers were not too concerned about jumbo frames for a long time. It looks like high end DC testing scenarios were not part of the regular QA test cycles. 

I can only hope this will change in the future.

Extending logging partition on your management station

One of the major challenges when managing Check Point security systems is about log storage. If you are not careful and/or proactive, you can run out space eventually.

It does not matter, how much free space you plan for your logging partition, one day it may not be enough. If this day comes, what are you going to do?

Of course, you can always delete some old logs or just get a bigger box. If latter, then you have to run through a long migration procedure.

What about adding a new storage? There is a way to change Gaia partitioning with LVM management tool, as described in SK95566.

There is even an article about extending logging partition to a new disk drive. Take a look on SK94671. It describes VMware case, but can be in general applicable to any additional HD.