Join @indeni Tweet Sweep at CPX 2017

 Tweeting for prizes for CPX? Yes, please!

indeni is thrilled to participate in our fifth consecutive year at Check Point Experience (CPX). As one of the major firewalls indeni covers, we love connecting with the Check Point community year after year. In order to connect with each of you, we are kicking off the @indeni Tweet Sweep to open up the conversation even before CPX! Tweet at @indeni your answers to the weekly questions posted on our Guide to CPX and collect your prizes at our CPX booth!

@indeni Tweet Sweep of the Week:

What was your favorite CPX + indeni memory

from CPX 2016 in Chicago?

How can you participate?

Did you say prizes?!

  • 1 tweet = 1 indeni sticker
  • 3 tweets = 1 indeni T-shirt
  • 10 tweets = WIN A DRONE!
           (While supplies last)

How do I get my prizes?

  • Stop by our booth at CPX
  • Show us your tweets
  • Claim your prizes!!

Q: I am having trouble thinking of good tweets…

A: No Problem! Here are some ideas for this weeks Tweet Sweep:

  • @indeni I realized what it means to be truly proactive. Preloaded knowledge running around the clock versus a red light/green light. Thanks
  • @indeni I spoke with indeni’s CEO/founder, @yonadavl, about indeni’s knowledge around VPN Tunnels & expired contracts. Exciting work!
  • @indeni I took a selfie with the indeni team!
  • @indeni  who knew indeni could alert me to expiring licenses, learned that in their demo at CPX
  • @indeni  in a sea of blue smiley faces lies a change in how security and operational teams look at their environment.
  • I saw a great live demo at the @indeni  booth…the smiley face t-shirt was a great bonus, too!
    (Feel free to share a photo of you wearing your T-Shirt!)
  • @indeni the Nerf Guns still crack me up
  • Got drinks with @indeni  after day 2. The team is very knowledgeable and dedicated to their smiley face shirts!
  • @indeni  made the expo floor fun and stimulating. I am looking forward to seeing what they do this year!
  • @indeni  I spotted the indeni team at a Happy Hour by their Smiley Face T-Shirts. Great talking to a fun group of people!

In conclusion

CPX is 6 weeks away but the fun can start now! Check back for next week’s tweet of the week.

Good Luck!

Check out our Check Point solutions here.

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.

Announcing indeni 5.4: New rule engine, Check Point 61000/41000 support

Welcome 5.4!

In this release we’ve included phase one of our infrastructure operations platform, added new content and as well as Check Point 41k/61k support. In addition, specific feature requests and bugfixes were included. Please reach out to our support team to get the updated release.

IMPORTANT NOTE TO ALL USERS: Starting with 5.4, the licensing mechanism is attached to the indeni instance’s unique identifier (uid) and not the IP address. This allows customers to not only change the IP of their indeni instance, but also set up cold active/standby high-availability in case the primary indeni instance is down or is cut off from the network. To set up cold active/standby, please reach out to our support team.

New content: Continue reading

How to Configure a VPN for DAIP Gateway Connected to Internet Using USB 3G-Modem


This document describes the specific configuration of Check Point appliances as a DAIP gateway (with Dynamically Assigned IP Address). It connects to the Internet using a USB 3G modem. As Check Point 2012 appliances do not support USB modems, an additional router will be used which supports USB 3G modems converting them to RJ-45.

Specific to this configuration is an additional Hide NAT which prevents the connection from the Check Point Smart Center to the private IP address of the DAIP gateway in order to send the configuration and initiate a VPN connection.

This document is based on Check Point appliance 2200, TP-LINK TL-MR 3040 which supports various 3G and 4G modems and USB 3G-modem Teleofis RX301 R4. Other modems and routers could be freely used.


As a central gateway we use a virtual machine with the Check Point version R77.30. Its name is «DK-CPSG». The external interface is connected to the Internet and has a public IP address. There are also two internal interfaces to a management network ( and a test segment (

Continue reading

Using cURL to Monitor Check Point VSX Firewalls

“If you are bad at IT, you’re going to be really bad at virtualization.”
Steve Chambers

Foreword by indeni:

Though scalable and functional, virtualization hasn’t yet stood the test of time and innately results in decreased visibility until fully socialized within the marketplace – the catch twenty-two of technology adoption. Even the best of IT professionals are going to struggle with the implications of this market shift.

Continue reading

Check Point Firewall Guide Performance Optimization: The Dual Default Gateway Problem

Is your Check Point Firewall connected to your core internal router on a dedicated VLAN/segment with no other systems present? In other words, is your firewall connected to your core internal router with a transit network used solely to forward traffic between the firewall and core router like this:


Figure 3-4: A Private Firewall- Core Transit Network

Or do you have something like this:


Figure 3‑5: Non-private Transit Network between Firewall and Core Route

Continue reading

Best Book Firewall Performance and Optimization

indeni, cisco

UPDATE: The book is no longer offered by indeni. Please go to to purchase the book. Below is the original blog post as it appeared. You may also want to take a look at what indeni does for Check Point firewalls.

Our goal at indeni, since inception, was to share as much knowledge as we can with users around the world. Today we’re excited to announce that Timothy C. Hall’s most recent book, “Max Power: Check Point Firewall Performance Optimization”, is now being made available for free to certain Check Point users, at our cost!

Note: this offer is valid through Nov 15th, 2015 only.

The book, published last April, will help you get the maximum performance from your Check Point Firewall! This book takes you through discovery, analysis, and remediation of common performance issues on Check Point firewalls.

Continue reading

How to Export Check Point Log Files into a Readable Format Without Using Smartview Tracker

Data connections and led lights in an industrial building grain visable in areas and colours removed from certain images to enhance them., Low aperture used to create a shallow DOF on on connections or lights
Exporting Check Point Log Files without Using Smartview Tracker.

Need to Export Check Point Logs Files Without Using Smartview Tracker? No Problem.

It may come as a surprise to you that some Check Point Firewalls store log files in a binary format, especially if you’re used to analyzing the logs with Smartview Tracker or if you simply have the logs forwarded to an Opsec server. This poses a unique challenge for environments that don’t want to invest in an additional logging server but want to be able to review the logs in a readable text format.

If you have the option and the license I highly recommend using Smartview Tracker. It’s a terrific application with the built in functionality to search through multiple log files, analyze traffic and create custom filters. Below is a screenshot of the application in Demo Mode, as you can see there’s an assortment of information available at your fingertips.

If however Smartview Tracker isn’t available because of your setup or simply because of your preference and a logging server is not an option, Check Point natively supports the binary to text conversion with its fwm logexport command. The fwm logexport command converts the binary formatted log into a readable ASCII format.

Continue reading

How to Setup Authentication for Admins – WebUI / SSH/ SmartDashboard – Check Point GAIA

GAIA WebUI and SSH introduction

When you login to a Check Point firewall or device over either web or SSH, you are authenticated in the same way. The different authentication methods are

1.    Local user account
2.    External authentication server for a local account
3.    External authentication for a non-local account

Adding a local user in GAIA  – Using WebUI

This is the simplest way and often the easiest method of adding a user and authenticating. Begin by logging into the WebUI. The standard is HTTPS over port 443

Go to User Management > Users and click “Add” to set up a new user:

In the next window you can select options for the user.

Login Name: This is the username used when logging in
Password: Password
Real name: To identify users easier
Home directory: Home directory, this will be /home/<USERNAME> as default
Shell: This is the standard shell when you login. Default shell is clish. If you change it to /bin/bash remember that the user will be able to run commands with root privileges if he has UID = 0
UID:  The default is 0, which means that you will have the same permissions as root if you get into the /bin/bash shell. However in order to get into that shell you must either have that set as your standard shell, or know the expert password.

You can also select if the user can login to either Web or SSH or both, as well as assign one or more Roles. The Roles determine what permissions you have to run commands and modify configuration.

Adding a local user in GAIA  – Using clish

clish is the default shell when connecting to the Check Point device over SSH. clish works in a very similar way as when modifying configurations in a switch or router.

Adding user

# add user <USERNAME> uid <UID> homedir <HOME_DIRECTORY> # set user <USERNAME> password # add rba user <USERNAME> roles <ROLE> # save config

Deleting user

# delete user <USERNAME>

So using local users is easy, but let’s see what the pros and cons are :

Advantage:            Easy to setup
Disadvantages:     Static passwords on each device means a lot of work to change them all if you have many devices
There is no password expiration set as default
If a user quits it’s a lot of work to find everywhere where the user has accounts and delete them
If a new user joins the team it’s a hassle to create accounts for him on all devices

These disadvantages often lead to teams managing the devices to use the admin account for everything, and share the password, since it is easier. This is of course bad for several reasons.
Sharing the account means that you cannot determine who did what from the logs. A shared password is more work to change, as everyone needs to be informed, and often means that it will be changed less frequently, if at all.
According to PCI-DSS 8.5.8 it is stated:
8.5.8 Do not use group, shared, or generic accounts and passwords, or other authentication methods.

Password policy for local accounts

Here you can setup the password policy for local users


Roles are permissions sets that you can assign to a user.
You configure it here:

Each Role has two types of permissions.
Commands = Commands that can be executed in CLI
Features = Part of the configuration. If a user does not have the NTP feature then the user will not see the NTP part in WebUI and cannot change it in CLI either.

There are three pre-defined Roles, adminRole, cloningAdminRole and monitorRole with different permission sets.

Authentication servers

Configure if you want to use an external authentication server, either for non-local users, or local users who authenticate remotely


RADIUS Servers: Here you can define your RADIUS servers, which IP, port and timeout as well as shared secret.
Network Access Server (NAS):  The IP that should be recorded in the RADIUS Access Request as the IP of the gateway. If nothing is selected here it will use the source IP address of the packet.
Sometimes when packets go via NAT the source IP of the packet can change. Then it can be good to have the true source IP recorded inside the RADIUS Access Request.
RADIUS Users Default Shell: This is the default shell for non-local users.
Super User UID: This is the UID for non-local users when entering expert mode. This should be 0 in most cases.  The only other option is 96, which is the UID of the “_nonlocl” built in user. If 96 is selected the user will not be able to run any commands from expert.
If you are unable to select 0, then check sk98958 or sk97206.


For TACACS+ the settings are the same. You need to set a priority, server IP, shared key and timeout.
Don’t forget to change the User UID to 0 if you want to be able to use expert mode properly.
Also different from RADIUS is that you need to enable TACACS+ with the checknox “Enable TACACS+ authentication”

Adding a local user that will authenticate to an external authentication server

Add a local user as described earlier in this guide. Remember that the password you set on the user will still work even when using external authentication. So if someone would input the local password it would fail the external authentication, but still be allowed in on the local password.
We could set the local user to some random password, or we could unset it completely.
To set a blank password, login via cli and do

# dbset passwd:<username>:passwd "*" && dbset save

This will set the password hash to a * and nothing can be hashed to only *.
After adding a user, and setting the password to random or nothing at all, we need to configure which remote authentication server we will use.

In this example I will show how to do this from the WebUI, but it can also be done from clish.

1.    Open the WebUI and go to User management -> Authentication Servers
Here we can add either a RADIUS or a TACACS+ authentication server.
In this example we will add RADIUS servers.

2.    Click “Add”
Chose the Priority (the first host should have 0, the next one 1 etc)
Input the IP address in the Host field.
Select UDP port or accept the standard 1812
Input the shared secret that the authentication server will use.
You can increase the timeout if you are working on a slow connection.
You should have at least two external authentication servers for redundancy.
The Check Point device will try the one with the lowest priority, wait for the timeout, and then try the next.

3.    Choose whether or not you need to change the “Network access Server (NAS)” as described earlier in this guide.
Make sure that the default shell is as you want it to be, as well as keeping the Super User UID to 0.

4.    Click Apply

5.    Add the user on your external authentication server and make sure the firewall is open.
You need to open port 1812 from the Check Point device towards the RADIUS Servers.
Remember that the RADIUS Authentication request could be NATed behind the cluster IP of the Check Point Gateway.
This means that in your RADIUS server you need to put in the Cluster IP.
It also means that if one of the nodes in a cluster is down, it will not sync with the active one, and as such RADIUS will not work.
If the “down” node sends an Authentication request to the RADIUS server, which is NATed behind the cluster IP, the reply packet will be send to the active node.
Since the node who sent the request is down, the connection would not have been synced to the active node, and the active node will drop the packet with reason “no such connection”
The solution is not to hide NAT RADIUS requests, which I will explain below

6.    If you are going to use RADIUS over VPN you need to read sk31692 because RADIUS packets are in the implied rules, as such they are excluded from all VPN tunnels per default. The SK describes how to edit the implied rules file on the management server to solve this.

7.    Now you should be able to authenticate.
Troubleshooting can be done via packet capture and view the packets in tcpdump, and also check /var/log/messages

Advantage:       This method is good because you can now control users from a central place. This means that you only need to change your
password in one place, and if a user quits you can remove his account in the central authentication server.
Disadvantage:  Even if you remove the user from the central authentication server the user will still be in the user list. Also, if a new user joins
your team, you need to add this user to all devices.

That brings us to the next solution, using non-local users

Adding a non-local user that will authenticate with an external authentication server

Check Point also has support for something called non-local users. This means that no local user is added on the device, so the user list will only who the default users.

For this method we not only have to authenticate the user, we also need to tell the device what permissions he needs. To be able to do this in a simple way we will assign the user to a Role. You can use the built in Roles, or create new ones.

In order for the RADIUS server to send not only the OK or Not OK, but also which groups the user belongs to we will need to use something called VSA (Vendor Specific Attributes)

This is the standard way of letting the RADIUS server include additional attributes to return to the Check Point device along with the authentication reply.

Go to sk72940 to get information on how to put the dictionary needed onto the RADIUS server.
You then need to configure the RADIUS server to send these attributes when a user authenticates.
The procedure is different depending on RADIUS server, but for RSA Authentication Manager 8 it looks like this:

So here the adminRole was selected.
We have also selected the user to be allowed to go into expert mode with UID 0, which is root permissions.
If you do not have SuperUser access set to 1, you will be user “_nonlocl” when going into expert, and that means you will not be able to run most commands.

Now you should be able to login with a user that is not in the Users list at the Check Point device.

Authentication for SmartDashboard

For SmartDashboard we have a few other authentication methods.

To choose one for a user, go to “Users and Administrators -> Administrators” and double click a user

Here you can select
Undefined = No authentication mode set. User cannot login
SecurID = Proprietary login method from the company RSA
Check Point Password = A static password set in this window
OS Password = The same password as a WebUI/SSH user with the same username
RADIUS = Authenticating via RADIUS
TACACS = Authenticating via TACACS

RADIUS authentication for SmartDashboard

When doing RADIUS authentication for SmartDashboard we cannot use non-local users, so we need to create each user manually.

First let’s define our RADIUS servers.

1.    Open SmartDashboard
2.   Create a host object for all RADIUS servers
3.   Go to “Servers and OPSEC”

4.    Right click on “RADIUS” and select “New RADIUS..”
5.    Fill in the information
Select a name
Select the host object you created earlier
Change the Service to NEW-RADIUS
Input the shared secret
Do the same for all RADIUS servers.

6.    Now right click “RADIUS Group” and select “New RADIUS Group..”

7.    Put in all RADIUS servers in here and click OK

Now we can enable RADIUS authentication on a user.

1.    Open up a user as described earlier in this guide
2.    Go to “Authentication” and select “RADIUS”
3.    Where it says “Select a RADIUS Server or Group of Server” select the RADIUS group you created earlier
4.    Press OK on the window and next let’s install database
5.    Go to File -> Policy -> Install database

Now it should work to login using RADIUS for SmartDashboard

Some additional settings can be found at ‘SmartDashboard > Global Properties > SmartDashboard Customization > Configure > FireWall-1 > Authentication > RADIUS’

For example timeout.
radius_user_timeout Timeout interval for the user to respond to a RADIUS challenge (in seconds)
radius_retrant_num Maximum number of connection attempts to the RADIUS server
radius_send_framed  Send the framed host (source IP of the connection) to the RADIUS server
radius_connect_timeout Timeout interval until next attempt to connect to the RADIUS server (in seconds)
radius_retrant_timeout Timeout interval for each RADIUS server connection attempt (in seconds)
radius_ignore  When handling RADIUS authentication, FireWall-1 verifies that the RADIUS attributes are RFC compliant. If your system uses non-standard RADIUS attributes, you can force FireWall-1 to ignore these attributes

TACACS+ authentication for SmartDashboard

First we need to define the TACACS+ servers.
1.    Open SmartDashboard
2.    Create a host object for each of the TACACS+ servers
3.    Go to “Servers and OPSEC”
4.    Right click the “Servers” folder and select New -> TACAS..

5.    Fill in the information
Host: Select the host object
Type: Select TACACS+
Secret key: Put in the pre shared key
Service:  Already filled in as TACACS

Now we can enable TACACS+ authentication on a user

1.    Open up a user as described earlier in this guide.
2.    Go to “Authentication” and select “TACACS”
3.    Where it says “Select a TACACS Server” select the TACACS server you created earlier.
4.    Press OK on the window and next let’s install database.
5.    Go to File -> Policy -> Install database.


Common issues and solutions

To stop RADIUS requests to being hide NATed behind the cluster IP:
1.    Find the table.def file (sk98339)
In most cases found here: $FWDIR/lib/table.def
2.   Edit the file and find the line that says:
no_hide_services_ports =
Example syntax
no_hide_services_ports = { <4500,17>, <500, 17>, <259, 17>, <1701, 17>, <5500, 17>, <68,17>, <67,17>};
each entry has portnr, then number 17 for UDP or number 6 for TCP
3.    Add (without quotes) “, <1812,17>” to the end of the line, before the finishing “};”
4.    Push policy to all gateway clusters.

To allow radius passwords with more than 16 characters – see this link sk13740
It explains that if you need to have more than 16 characters in the passwords for RADIUS you can change the protocol on the RADIUS object from the standard “RADIUS ver 1.0 Compatible” to “RADIUS ver 2.0 Compatible”


Johnathan Browall Nordström is the Team Lead of Network & Security at Betsson Group. He has been working with Check Point firewalls for more than four years. If you want to contribute as well, click here.

Ready to get started? Request your free trial of indeni for Check Point.

How To Set Up Certificate Based VPNs with Check Point Appliances: CPFW Config Guide

indeni, cisco

Securing virtual private networks (VPNs) in enterprise Site-to-Site environments is an important task for keeping the trusted network and data protected. Also it’s critical to avoid any loss of data sovereignty.

When it comes to VPN security many security experts first think of encryption algorithms, perfect forward secrecy (PFS), Diffie-Hellman groups… and a long pre-shared key (PSK). Ouch!

What about VPN certificates?

Every security expert knows how much better certificates are for gaining high security levels. Therefore certificates are always best practice in enterprise grade security environments.

However, most VPN site-to-site setups are still based on simple, long lasting pre-shared keys. In many cases these keys were even forgotten by the administrators in charge of keeping the network secure because once configured for the VPN tunnel they are not needed anymore.

This is because it’s much quicker and really easy to set up a VPN with a simple pre-shared key than having to deal with certificates and a certificate authority (CA).

But is it really that hard to implement a way better security architecture based on certificates? This article shows how simple it can be when you work with Check Point Firewall & VPN security gateways.

Let’s get started! Continue reading