Convert Check Point Global Policy Rules and Global Objects imported into SMS, to local objects and rules

In the unlikely event, that you get handed over a database export of a CMA to be imported into a SmartCentre server, which has global objects and a global policy assigned, you will have the need to unlock those objects and the rules for editing.

As you know the problem with Global Policy and Global Objects are once they are assigned to a CMA, you cannot edit them in the CMA level. So the same applies to the imported policy and objects on the SMS.

In this example, I am not going to delete the global objects or delete the firewall rules, I am going to keep them in an editable state. But once you make them editable, you can delete them as well.

Few notes on the Global Objects on the SMS (I am only going to speak about the network objects here):

• They got a different icon assigned to them, and 
• you cannot edit them :)

So to convert them to local objects we are going to edit the Objects_5_0.C file in $FWDIR/conf directory in the SMS.

Once you edit the file using your favourite text editor (vi in my case), search for the object name and look for the properties

• icon
• global_level

To make it a local object either remove the line :global_level(1) for the object definition or modify it to :global_level(0).

To change the icon of the object remove the "_G" at the end of the icon name. For instance if it's a Host object you will see the property as:

:icon ("NetworkObjects/Nodes/Host_G")

So the modified value would be:

:icon ("NetworkObjects/Nodes/Host")

This will convert the object to a local object and you can modify/delete the object as you wish.

Now let's deal with the policy.

As you know all the firewall policies are written in the file rulebases_5_0.fws. (Make a copy of this file before you proceed).
Open the rulebases_5_0.fws in $FWDIR/conf file with your favourite editor (vi in my case).

You can see all the policy packages defined. Let's assume you only have one policy package + the global policy.

Locate the start of the policy package that you are working on. It's start with:
:rule-base ("##
followed by the policy package name. For instance :rule-base ("##Standard"

All the rules assigned as part of the global policy (either located in the start or the end of the policy package), will have the :global_level(1) value set.
To make this rule local, either delete the line or modify the value to :global_level(0).

Now the rules are made local and you can modify/delete the rules.

Ok now comes the interesting part. Though you have converted the rules in the current policy, to local, any new policy package that you create will have the global policy assigned.

So how do we get rid of this? Glad you asked :).

For this, we'll need to delete the Global Policy package from the rulebases_5_0.fws file. Remove everything under the Global Policy package definition.

:rule-base ("##Global_Rules_Container"

Once you are done with the editing, issue a cpstop;cpstart to reload the database.

OK now we are done. Or are we???

Go ahead and login to the SMS using SmartDashboard. Open the policy package that you were working with.

Did you notice something in the Title Bar? Assigned Global Policy: Policy Package Name.

Hmm.... How do we get rid of this?

For this we'll have to go back to our good old friend Objects_5_0.C file. (Make sure you make copy of this file before you proceed). Edit the Objects_5_0.C file and locate the SMS (in this case the imported CMA) object definition.
Under the object's properties (there's a lot there), you will find the below.
:gp_name (Global policy package name).

For instance :gp_name (Standard)

Delete the value within the parenthesis.

Save the changes and issue a cpstop;cpstart.

Checkpoint Gaia Radius authentication with Cisco ISE 2.1

This post describes how to configure Cisco Identity Service Engine (ISE) 2.1 to authenticate Checkpoint Gaia users.

The Checkpoint support article SK105542 on "How to configure a RADIUS server on Cisco ACS for authentication with Gaia OS" is very handy on getting this implemented on Cisco ISE as well.

The first step is to Add the Vendor Specific Attributes for Checkpoint.

For this in ISE Web UI Select Policy -> Policy Elements -> Dictionaries



On the Radius Dictionaries section, expand System -> Radius and click on Radius Vendors.
 

Click on Add to add a new Vendor and complete as follows.

Dictionary Name : Checkpoint
Vendor ID : 2620

Leave the other values as default. 



Under Dictionary Attributes add the below two values.

 

 
  

Next we need to define a Network Device Profile for Checkpoint as by default ISE doesn't have any Network Device Profile for Checkpoint.

For this navigate to Administration -> Network Resources -> Network Device Profiles.

Click on Add to define the new network device profile for Checkpoint devices.

In here, I've define a very basic Network Device Profile to be used only for Radius authentication for Gaia OS.

Name : Checkpoint-Firewalls (or anything that you prefer)
Vendor :  Other
Supported Protocols : RADIUS
Radius Dictionaries : Checkpoint (this is the dictionary that we created above) 

Leave the rest of the attributes to the default values.


 

Now we need to define a Authorization Profiles to be used for each of the authorization policies that we want to create. For this post, I am going to create on authorization profile to be used in admin authentication giving the matching user group Super-User access and adminRole.

Navigate to Work Centers -> Network Resources -> Policy Elements.
Under Policy Elements expand Results and select Authorization Profiles.
Click Add to add a new authorization profile.

Name : checkpoint-admin (or any other name that you prefer)
Access Type : ACCESS_ACCEPT
Network Device Profile : Checkpoint-Firewalls
Advanced Attribute Settings : 
(add the two radius attributes wed defined earlier in the radius dictionaries with the required values)
Checkpoint:CP-Gaia-User-Role = adminRole
Checkpoint:CP-Gaia-SuperUser-Access = 1



Next we define a Authentication Policy. For this I have used domain based authentication. I have not described how to add Microsoft AD as an external authentication source to ISE.

Navigate to Work Centers -> Network Access -> Authentication Policy.

Add a rule on the top:
Rule name: Checkpoint-auth
Condition:
If DEVICE:Device Type Equals Device Type#All Device Types#Checkpoint
Allow Protocols:
Default Network Access (or any profile that you have created)

Under actions, use the default action and set the identity source to your preferred identity source.



Now we define a Authorization Policy.
Navigate to Work Centers -> Network Access -> Authorization Policy.

Here you can create different authorization policies, depending on your requirements. i.e. you can create one rule to allow full admin access, and another rule to allow a different user role like monitorOnly and without super user rights.
In this example I have created an explicit deny rule as by default in ISE there's an catch all allow rule at the bottom.

Admin Allow Rule


Conditions:
If any and
Network Access:AuthenticationStatus Equals AuthenticationPassed and
and
DEVICE:Device Type Equals Device Type#All Device Types#Checkpoint

Permissions:
checkpoint-admin

Deny Rule 






I am not going to describe how to configure Radius authentication in Gaia, please refer to Configuration on Gaia OS section on SK105542 :).

Packets dropped with "Server to client packet of an old UDP session" log on Tracker

Recently we encountered an issue with one of our printers. What we found out was that the printer was unable to communicate to the print server (which was behind a firewall :) ). The printer was behind a firewall too :) .
This was working fine on the previous week, but suddenly it stopped working. Obviously someone most have done something on either the printer end or on the server end.
When we looked through the firewall logs, what we observed was UDP 53213 is getting blocked on the Firewall close to the Print Server with the message "Server to client packet of an old UDP session". 
Restarting the printer didn't work. We couldn't reboot the print server as there were other sites that were using the same Print Server for printing.
So how did I resolve it? 
SIMPLE: Delete the connection entries for printer to print server, on the connections table on the firewall close to the Print Server.

I found the following article useful for this:
http://www.cpshared.com/forums/showthread.php?t=491

So the steps I followed were:

1. SSH into the active member, and go to expert mode.
2. Calculate the hex value for the source IP, destination IP, source port and destination port.
3. Search for the connection entry in the connection table using the destination port.
   fw tab -t connections -u | grep cfdd

So the output was something similar to


      4. Delete the connection entry from the connection table.

fw tab -t connections -x -e "01,ac1130db,0000cfdd,0a60040a,0000cfdd,11"

Smart-1 25 LOM password not valid after firmware upgrade

There is a SK article for upgrading the LOM firmware to overcome vulnerabilities present on the previous versions of LOM firmware.

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk94228

We have a Smart-1 25 appliance that was affected by this vulnerability and we proceeded to upgrade the firmware to the recommended version.
Parter the upgrade it promoted to reset the admin password and I reset the password which was setup earlier.
After resetting the password I was prompted to log back in, and started the drama. It didn't accept my password.
Then I found a very useful article to reset the LOM settings in the CPUG group.
I proceeded to reset the password, the method worked fine for the first time and I was able to set the password again.
The procedure can be found in the following link
https://www.cpug.org/forums/showthread.php/12778-Reset-LOM-password?p=81394#post81394
I have to say that there is nothing wrong in this article, and it works fine.
But unfortunately I made the same mistake f entering a too complex password so I ended up in the sake issue as before.
For some weird reason I couldn't boot the LOM using reset user name.
But what I've noticed that the complex password I've setup in the WebUI works fine for the LOM
maintenance mode, i.e. after booting using bootfmh and hitting y when it's prompted to goto maintenance mode.
But the thing is you can no longer enter ./reset.sh
But what you can really do is issue find command to find the reset.sh file.
find /-name reset.sh
You will get the exact path if the file and from memory it is located in the www directory.
You can execute this script to reset the LOM configuration.

Unfortunately I didn't want to spend more time on this to look at the content of the script ( I was fed up doing the upgrade on the management server, in fact I ended up spending most of my time in resetting the LOM password  than upgrading the Smart-1 25 to R77 during the change window )

Multiple SNMP communities in GAiA R76 and R77

When using SPLAT, we can edit most of the OS level files do customisation. One such thing is the SNMP configuration file.
For instance if you need to add multiple SNMP read-only communities you can add all the communities by editing the /etc/snmp/snmpd.users.conf
With the the introduction of GAiA we can't edit the snmpd.conf manually, and there is no snmpd.users.conf file in the /etc/snmp directory.

In GAiA,bathe SNMP settings are configured either using the WebUI or using the clish commands. But using these two options you can only define one read-only and one read-write community.

But from R76 and above there is a built-in file in /etc/snmp directory for all the user defined snmp settings.
/etc/snmp/userDefinedSettings.conf 

This file can be used as the snmpd.user.conf file. Before editing this file, you have to stop the snmp agent.

So if you want to add an additional read-only community, you can edit this file and add the following line and save it.

rocommunity <additional ro community>

After saving this file, you need to re-enable the snmp agent.

The thing is, when you issue the clish command "show snmp communities" you will not see the additional communities that you have defined.

In the initial releases of GAiA the /etc/snmp/userDefinedSettings.conf file is not present.

The SK article sk79280 explains how to add SNMP user defined settings in detail. 

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk79280

This article is very useful if you are running GAiA versions below R76.

Site-to-Site VPN between Check Point and Cisco ASA

It's a common occurance that we have to configure Site-to-Site VPNs between Check Point firewalls and Cisco devices (ASAs and routers).
But configuring a Site-to-Site VPN in Check Point with a 3rd Party Device is sometimes a bit tricky. This is because the auto-summarisation or supernetting of networks in Check Point end.
When we are creating the Site-to-Site VPN we have to follow these basic steps.

• Enable VPN feature on the Check Point firewall
• Configure the Encryption Domain
• Create an Interoperable device for the remote end VPN terminator
• Configure the Encryption Domain
• Create a VPN Community and configure the parameters for the VPN (IKE, IPSec parameters)
• Configure Firewall rules for the communication

After configuring all these things correctly we will (most of the time) fall into the famous
"No Valid SA when creating IPSEC tunnel with an interoperable device" problem.

According to sk39419:

"The nature of this problem is due to the ability of the Check Point Security Gateway to dynamically supernet subnets to reduce the amount of SA overhead normally generated by VPN traffic. Most third party vendors are inherently static and therefore do not have the ability to understand this dynamic behaviour."

This article also provides 3 possible solutions for this.

But if you just play around with this you will find an interesting behaviour.

This is what I observed when I played with one of the VPNs I had to troubleshoot.

Our Encryption Domain (behind the Check Point Firewall) is a straight forward 10.16.0.0/24 network.
Remote end Encryption Domain (behind Cisco ASA) had three hosts 192.168.1.240, 192.168.1.241. So if I create two host objects for the above two IPs, add them to a group object and configure that group object to be the Encryption Domain of the Interoperable Device, this is what happens.
IKE Main mode completes correctly.
In the Quick mode negotiation the ids are sent as (10.16.0.0/24 - 192.168.0.0/16) from Check Point to ASA.
As the ASA is not configured to accept 192.168.0.0/16 as the id it will not establish the IPSec tunnel.
On solution we can provide (also mentioned in sk39419) is to set "One VPN Tunnel per each subnet pair" option in VPN Commmunity -> Tunnel Management section.
The problem with this is it will increase the number of phase 2 SAs. This is not desired though it solves the problem.

So luckily we can supernet the IPs used for the two hosts to 192.168.1.240/31 (thus following the solution C in sk39419). So we created a Network object (say Net_remote_enc_domain) with IP address 192.168.1.240 and net mask 255.255.255.253 and added it to the encryption domain of the Interoperable device.
It worked.!!! :)

But later, there was a requirement to add an additional host to remote end's encryption domain - 192.168.1.218.
If we are to have a supernet to the three hosts, eventually we will be adding 64 hosts to the encryption domain. This was not desired from the remote end.
Still we are following the solution C of sk39419:
"Change the encryption domain of the Security Gateway to use a specific subnet instead of using hosts or groups. This will stop the Check Point Security Gateway from supernetting hosts since they now are part of a subnet which has been manually defined."

Now I wanted to play around a little bit.
First I created a group object (grp_remote_enc_domain), added the network object Net_remote_enc_domain (which is 192.168.1.240/31) and host object (say remote_host3) with IP 192.168.1.218, and configure it as the encryption domain to the Interoperable device (i.e. the remote end VPN terminator)

Note: We were informed that there are two ACLs created in the ASA end matching 192.168.1.240/31 and 192.168.1.218/32

I enabled ike debugging in out Check Point firewall (using vpn debug ikeon) and initiated traffic from our end.
First to 192.168.1.240, then to 192.168.1.241 and finally to 192.168.1.218.
The first two communications were successfull, but the final one failed.
When I examined the ike.elg using IKEView, I observed the following phase 2 IDs being exchanged
(10.16.0.0/24 - 192.168.1.240/31) - completing Quick mode
(10.16.0.0/24 - 192.168.0.0/16) - Quick mode failed

So I came to a conclusion that when ever a host object is encountered in the Encryption Domain it Check Point will try to summarise or supernet the IP address.
So what I did was instead of the host object, created a Network object with /32 prefix length.
Net_remote_host2 (with IP address 192.168.1.218 and net mask 255.255.255.255).
So now grp_remote_enc_domain group object has two members:
 - Net_remote_enc_dmoain
 - Net_remote_host2

Saved the policy and installed it in the gateway.
Now when I initiate the traffic (with ike debug on) it WORKED!!!!!!! for the three remote hosts.
When I examined the logs there were two ids negotiated (thus 2 SAs created).
(10.16.0.0/24 - 192.168.1.240/31) for 192.168.1.240 and 192.168.1.241 hosts
(10.16.0.0/24 - 192.168.1.218/32) for 192.168.1.218 host.

So I didn't have to go with editing objects_5_0.C and change the variable ike_use_largest_possible_subnets to false
or
Configure the "max_subnet_for_range" table in $FWDIR/lib/user.def on the management console (SmartCenter)

We don't like to have the above two options because will be not visible in the Dashboard and eventually if it is not well documented the future firewall admins will loose track of it.

Sudden drop in traffic through some interfaces in Power-1 (solved)

Recently we encounter a strange behaviour in one of the Power-1 clusters deployed in one of our telco customers. A brief explanation of the problem we encountered is as follows.
AAA traffic was entering from the external interface and was designated to a RADIUS server which lies in another interface. In the traffic graphs they have experienced a sudden drop of traffic and all the authentication requests are lost in that instance. After a couple of seconds the traffic is back to normal. This happens not only in the peak hours but also in other times too. Even if they switched from one Power-1 device to the other the problem remained.
After digging down into the problem we came up with a solution.
As we suggested there are interface drops recorded. You can get an idea of the Tx/Rx errors and drops by issuing "ifconfig "
So when we issue this command to the relevant interfaces we noticed that there are huge amount of Rx drops in the external interface.
From this we can come to a conclusion that Rx buffer is not sufficient. To better understand about the problem it's always better understand what the Rx buffer is.
When the NIC receives packets it issues an interrupt to the CPU to handle the packet. For each packet it receives it generates an interrupt. So when the CPU is interrupted the CPU handles the packet first by executing the relevant interrupt procedure and then handling the packet with the relevant software component (in this case the Check Point firewall kernel). But the CPU cannot handle the packets at the rate the NIC receives them. So the NIC needs some sort of a temporary storage location. So the NIC is allocated some temporary storage (buffer) from the RAM. This is the same for the Tx buffer.
You can always view the allocated Tx and Rx buffers to an interface by issuing "ethtool -g ". By issuing this command you can see the maximum values as well as the current allocated value.
Now we know what the Rx buffer really is. So the buffer gets filled when the CPU is taking too much time to process traffic. Does Check Point provides a solution for increasing its performance, i.e. both throughput and connection rate. Well it does. It is the SecureXL technology. For SPLAT it is provided with the Performance Pack (another module that is loaded). So we can speed up the packet handling if we tune up SecureXL.
So we analysed the SecureXL stats as well. You can get the details from "fwaccel stats" or else you can view them from "/proc/ppk/statistics". So as doubted the f2f (non accelerated traffic) was higher than accelerated packets. So we tried to optimize this by modifying the rule base. So after some effort put on the rule base, we could get the stats to an acceptable value.
Still the problem remained. Then we moved on to the next step of increasing the buffer memory.
In this case the maximum was 4096kB. We increased the value in 1024kB increments. Until we solved the problem.
As expected it solved the problem.