How Customers Use Check Point Firewalls Around the Globe

In order to conduct the in-depth analysis of configuration and stats on network devices we collect very large amounts of data. For our customers, this data is very useful in benchmarking their network versus other networks around the world. We call this service indeni Insight.

Below is an aggregation of some of the data we’ve collected through this service. We are providing it to help the wider community consider how their network behaves as well as their future plans.

If you are interested in benchmarking your own network within an hour’s work, try indeni today. Once the system is set up reach out to and we’ll do everything else.

NAT connections (fwx_alloc) table limit approaching or reached


This is a real life sample alert from indeni to identify Check Point Firewalls issues.


There are 9210 NAT connections stored in the fwx_alloc kernel table while the limit is 10000. When the limit is reached, new connections may fail.

Manual Remediation Steps:

In many cases, a sudden spike in connections has been attributed to a worm or misbehaving application. If you have ruled this out, consider the solutions suggested in SK32224. Note that a higher limit may result in more memory being used, so it is recommended that changes are made gradually.

How does this alert work?

indeni constantly monitors the usage of hundreds of kernel tables. Different kernel tables are associated with different SK articles and best practices. When a kernel table nears its limit, the specific SK articles and best practices are included in an alert.

Check Point Firewall Clusters Healthy Checklist

Each and every organization we work with goes through the trouble of setting up a cluster of firewalls in every single critical location in the network. The cluster is there to ensure that there is no single point of failure. It normally works very well – fail overs are smooth and traffic proceeds uninterrupted. However, sometimes, a fail over doesn’t go smoothly. If the fail over is performed intentionally during a maintenance window then it’s usually easy to revert. But what if the fail over occurs spontaneously during peak-time due to an issue such as a power outage in your primary data center?

Knowing that a bad cluster fail over during peak time is one of the most stressful situations you can be in, we took the time to prepare the check list below. Hopefully, it will help you to ensure future fail overs are smooth, even during peak times.

  • Routing table differences – happens a lot less now that routing tables are controlled via the SmartDashboard, but one of the top causes of fail over issues we’ve seen.
  • CoreXL, SecureXL, kernel parameter differences – check that the configurations of CoreXL, SecureXL, fwkern.conf and any other .conf or .def file you may have manually changed are the same across cluster members.
  • Lack of GARP support – happens more often that you’d think. If your outage only lasts 30 seconds (or so), this is probably your issue. The network equipment around your firewalls isn’t listening to the gratuitous ARPs sent out by the newly active cluster member. You may want to enable VMAC by following SK50840.
  • Poor sync performance – if your sync network is slow or congested, which is especially common in DC-to-DC sync networks, your cluster members may have trouble keeping up. This gets worse the more features/blades you enable. We recommend disabling sync on short-lived connections, like HTTP. Follow sk23695.
  • Wrong configuration of topology – take a close look at the results of “cphaprob -a if” on all cluster members and make sure they are the same. Don’t forget to make sure the same *cast (multicast/broadcast) is used.
  • Clock mismatch – make sure the clocks are the same on all cluster members. We highly recommend using NTP.
  • Hardware, software, license mismatch – you’d think this never happens, but it does. Don’t overlook this check – make sure the appliances are of the same model, the software (including hot fixes and HFA) is the same and the licenses installed are the same.

You can you can use indeni to identify all of the above issues and hundreds more. For us, it’s all about avoiding outages by pin-pointing issues before they turn critical. It takes less than an hour to install (download now) and we’ll be happy to help you do it (contact our support).

Want to see what indeni can help you uncover in your Check Point firewalls?


If you want to learn more about how indeni can help your network management workflow and achieve high availability, just fill out the form below.

[ninja_form id=56]

How to Install a Check Point on a Blue Coat X-Series Chassis using an Installation Package (CBI) on a VAP Group

After discussing the creation of VAP groups and Circuits on Blue Coat’s X-Series under XOS in my previous posts, we can now install the application from a CBI.

The following steps are required for a Check Point installation. For this post I chose a standalone R67 VSX security gateway as an example.

Before installing the Check Point CBI, you should:





    1. Run the show-application command to view the available CBI files:
    2. Run the following command to start the installation of the application: application <application name from the selection above> vap-group <VAP_group_name> install
    3. The installation wizard prompts you to input the following information (Choose ‘y’ or ‘n’).
    4. Do you accept the license agreement?(Choose ‘y’ or ‘n’)
    5. Enter the interface name from which you want to manage the VSX system. Please make sure the corresponding circuit has a valid increment-per-vap IP address assigned to it.
    6. Enter the Secure Internal Communication (SIC) key below.
    7. Enter local license information (Local license info is the license for the module, by clicking on ‘n’ a trial license will be applied)? (Choose ‘y’ or ‘n’)
    8. Install Performance Pack?(Choose ‘y’ or ‘n’)
    9. Install Dynamic Routing? (Choose ‘y’ or ‘n’)
    10. Enable High Availability/State Synchronization? (Choose ‘y’ or ‘n’, for HA you will answer ‘y’ and be prompted to enter the synchronization circuit name.)
    11. The installation process of VSX will begin:
    12. When the installation is finished, run the following command: reload vap-group <vap group name>
    13. Additional VSX configuration can be done using Check Point SmartDashboard with the Management IPs assigned to the VAP.
    14. To check the status of the applications running on VAP groups, the following command needs to be run: show application vap-group <VAP group name>
    15. The output of this command includes the status of the VAPs (Initializing, Up, Down, etc.):

And that’s it! In my next post, I will cover additional configuration of VSX using Check Point SmartDashboard.