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.

Standalone installation of Eventia Suite

We have to notice that for Check Point R70.30 Eventia Suite is a must. So even though you have not installed the Eventia Suite when you are installing R70, when you install the upgrade package R70.30 the Eventia Suite is automatically installed.
Now for R70 standalone installation of Eventia Suite is not supported. What we mean standalone is Management Server (SmartCenter Server) and Eventia Suite installed in the same machine. What Check Point mean by not supported here is that you can install the two components in a single host but the configuration in the Dashboard is not allowed.
So is it really not supported? Can't you use the Eventia Suite when it is installed along with the Management Server (primary management server).
The fact is you can. I searched a lot in various forums even in the Check Point Usercenter, but couldn't find anything regarding this issue.
But the solution is simple.
First of all what you need is a valid license :). Once you have installed a valid license you can proceed.
Second what you need to make sure is whether the appropriate servers are running. For this you can issue "evconfig" and enable the necessary components. After you have enabled the necessary components, restart the Eventia Suite by issuing "evstop;evstart".
Now login to SmartDashboard and edit the Management Server object.
In the General view of the management server object you can see the Management Software blades enabled for your management server. But you will notice that all the components related to Eventia products are greyed out, meaning you cannot enable them. Unless you enable them in the management object, you cannot connect to the management server using a Eventia client.
So we are kind of stuck here.......
But Check Point allows you to manually manipulate its object database using dbedit. What we can do is use the gui version of the dbedit, which is "guidbedit". This is located in the SmartConsole installation directory.
Launch GuiDbedit, and provide the credentials to login to the management server.
Go to network_objects and locate the management server object.

Reverting back from R71 to R70

Recently I went on upgrading a Check Point Management Server having R70.30 installed to R71. I downloaded the R71 upgrade package from the Check Point site. The package was for upgrading from web ui.
So I used the Web UI to upgrade the management server. During the upgrade process I created a snapshot image (as mentioned in the upgrade process window).
According to the Web UI, the upgrade was successful.
So after the management server was upgraded, I upgraded it to R71.20.
After the upgrade process I couldn't event log into the Web UI.
When going through the fwm.elg it mentioned that fwm process didn't start.
I will explain the details about this specific issue in another post. In this post I will emphasize on how to revert back the snapshot image created in the R70.30 environment, in R71 environment.
So when I tried to revert the created snapshot image (pre_upgrade_snapshot.tgz) it failed. I tried numerous times but the result was the same. This is due to the fact that the snapshot image and the current running version have dissimilar major releases (R70 and R71).
"revert"ing does not support between two major releases.
This true if you try do it on the boot-up process, with snapshot image management.
So in this kind of a situation the easiest way to revert back to the earlier snapshot is as follows.

• Uninstall all the new packages related to R71
  - issue "rpm -qa | grep R71"
  - this will give you all the rpms installed for R71
  - using "rpm -e" uninstall all the related packages for R71
• The use the "revert" command and select the previous snapshot image

This will restore your management server back to R70 (in my case it was R70.30).

Check Point VPN-Client (SecureClient) connectivity issue

Our company's head-office is running a Check Point UTM-1 firewall cluster at the perimeter. Recently we encountered a strange SecureClient behaviour in some internal users. The scenario is like this.
Some of the staff members want to establish Remote Access VPN connections with another Check Point gateway. When they use an ADSL connection or a HSPA connection they can connect to that particular gateway but when they try to establish the same connection through our perimeter Check Point gateway the connection fails stating,

"Negotiation with gateway xxxx at site x.x.x.x has failed. Received notification: invalid id information"

When we observed the firewall logs (using SmartView Tracker) we observed that the IKE connection was sent to one of the interfaces of our Check Point gateway, which should not be the case.

The problem was, once the site is created in the VPN client, it automatically downloads the topology information and stores it in the userc.C file in the SecuRemote/database directory. It also stores the interface addresses of the remote gateway.
When I observed the file I saw that some of the interface IPs of the remote gateway are the exact same as our firewall interface IPs. So the vpn-client tries to connect to one of the internal IPs and eventually ends up by trying to terminate the connection in our gateway.

When I searched in the Check Point usercenter I found the following article sk26189.
It seems that the Remote Gateway is running an older version of Check Point.
So as for the article the change should be done at the Remote Gateway's object_5.0.C file, so that the gateway interface information is not downloaded to the client.

Now there's a problem. We cannot do the changes in the remote gateway. So how to overcome this.

I edited the userc.C file manually and located the interface information of the remote gateway and deleted all the interface information (not the whole topology information). Then restarted the VPN-client.

After that the Remote-Access-VPN got connected successfully. :)

Source-based routing in Checkpoint VSX

Recently I was testing Checkpoint VSX. In the checkpoint documentation they said that you can do source based routing in VSX, but this is with the Virtual Routers that they provide. Source-based routing works well when you put a Internal Virtual Router (IVR).
In an earlier post I mentioned how to do source-based routing in Linux using 'iproute2'. The good news is that you can use the same concept in the VSX virtualized environment.
In VSX each and every virtual device is associated with a VRF (Virtual Routing and Forwarding) instance. So the good news here is that, you have a routing instance running for each and every virtual device you have created.
Routing table entries are made only in one file, that is common for all the virtual systems, '/etc/iprotue2/rt_tables'. You can place the routing table number and give an alias for that. After you have created a routing table entry you can use that table in a VRF.
The two important commands that is used in iproute2 environment are

ip rule
ip route

First of all you have to add a rule saying, Traffic originating from this source should lookup the table you have created. Say that you have created a table called 'customerA', and you want traffic originating from 10.10.10.0/24 subnet to lookup the table 'customerA', and this should reside on vrf 2. For this you simply execute the command,

ip rule add from 10.10.10.0/24 via table customerA vrf 2

Now its time to add the routing entries for the table. For this you can use the same syntax you have used for normal iproute2 environment, that is without vrf, additionally you have to specify the vrf number. So for the default gateway it should look like,

ip route add default via 192.168.1.1 table customerA vrf 2

That's it. Very simple isn't it!

Routing for Office Mode IPs in Checkpoint

When configuring Remote Access VPNs in checkpoint, Office Mode is used very often. When using Office Mode, we can allocate a Network Rage to be assigned to the Remote Access VPN clients. So when the Remote Access VPN clients get connected, they get a private IP from the pool we have assigned. This becomes handy when we want to assign rules that allow internal users/devices to access the remotely connected clients.
We don't want to create an explicit route for the set of Office Mode IPs. This is because, it is routed via the default gateway. But there are instances where you should create a route for the set of office mode IPs. Consider the following example.
The firewall is Internal network is 192.168.x.0/24, and there are branch networks (around 20) with 192.168.w.0/24. You assign the office mode IPs to be 192.168.y.0/24. Since there are many networks internal to the router, the easiest way to configure the routing is to have 192.168.0.0/16 pointed to the internal router.
When you do this kind of a routing configuration, the Remote VPN clients won't get any return packets to them. In simple words, they cannot access any resource which they are intended to access, though the VPN tunnel get established. This because the return traffic is routed to the Internal network because of the summary route we have inserted.f To overcome this issue, you have to add a specific route for the Office Mode IPs. The route should be as follows.
192.168.w.0/24 via Default route.
Say the office mode IPs are assigned from 192.168.23.0/24 network, and the external interface is eth2. Then go to sysconfig. Choose 6 for Routing configuration. Select 1 to Add a Network Route.
Network IP: 192.168.23.0
Subnet mask: 255.255.255.0
Gateway:

This will route the traffic via the VPN tunnel.

Interface Bonding In SPLAT

The ClusterXL documentation in Checkpoint covers all the necessary things for HA link redundancy. But it does not cover interface redundancy for a standalone installation.
Interface Bonding is supported in almost all Linux/Unix distributions. SPLAT also supports interface bonding. You can configure interface bonding via sysconfig command. In NGX releases prior to R70 (including R70) does not provide the options for "High Availability" and "Load Balancing" when you create Bond interfaces.
But in R70.30 it includes this feature. So when you create a bond interface you are given the option to create the bond to support either HA or Load Balancing.
Configuring Interface bonding is straightforward.

1) First you have to make sure there are no IP addresses configured for the physical interfaces that are going t obe bonded. You can remove the IP addresses by sysconfig command.

• Choose 5 - Network Connections
• Choose 2 - Configure Connection
• Select the appropriate interface
• Choose 3 - Remove IP address

2) After you have removed all the IP addresses. Select Add new connections in Network Connections configuration menu

3) Select Bond Interface

4) Choose an interface to be slave

5) Choose another interface to be slave

6) After you have done selecting interfaces enter 'n' go to next.

7) Select "1" for High Availability, or select "2" for Load Sharing.

8) If you select Load Balancing you are given two other interfaces. Here I will discuss about HA only.

9) When you select HA you are given two options either to select default advanced parameters or to customize advanced parameters..

10) Selecting default advanced parameters, you will be asked whether you want to select a primary slave interface or not. If you select 'y' then you have to select a primary interface in the bond.

11) Then you will be asked to configure the IP address and the subnetmask for the interface.

The configurations in the SmartDashboard will be the same as you are doing for a normal interface.

Checkpoint Standalone Installation - post installation issue

Recently I deployed a Checkpoint Standalone installation in one of our customers. It was a HP DL360 G6 Server, with an additional interface card. The deployment was R70 (actually R70.30).
The first problem I encountered was that the network card was not recognized by SPLAT. Checking the NIC details, it was found that the card which was installed (NC375T) was not supported by SPLAT. Then it was replaced by a compatible card.
After the installation process, when I logged into the SmartDashBoard, the checkpoint object was created automatically. But when I tried to retrieve the interface configurations, all the interfaces were defined as External. There was no option to change it.
Before this implementation, I did a UMT-1 standalone installation with R65, this issue was not encountered.
The solution was not a magical thing. There was an option in the Dashboard itself. When you right-click the checkpoint object, there is an option to convert the object into a Gateway. When you convert it to a gateway, the normal firewall interface configurations can be carried out. :)

How to crack SPLAT password

SPLAT is the secure hardened OS provided by Checkpoint Software Technologies. There may be instances where firewall administrators have forgotten the password and need to reset the password. This article will give you an insight on how to reset the 'admin' and 'expert' passwords of SPLAT. For this you need physical access to your device, and a Linux live CD (ubuntu, will do the job).

1. Boot the device using the live CD.
2. Mount the '/' partition. If you are using Ubuntu, this will be an easy task. Otherwise, change your user to root or login as root. To change into root login, in RedHat based Linux systems issue
   "su -" followed by the root password. In Debian based Linux systems, issue "sudo su -" followed by the account password. After changing into root user issue the following commands,
   mkdir /mnt/_root
   mount /dev/hda1 /mnt/_root (you have to replace hda1 with the appropriate partition)
   
   
3. Open a terminal (you should be in root mode), and browse into the mounted "/" partition. If you mount it using GUI, it will be "/media/_". Then browse into the "etc" folder in the mounted partition. We are going to edit the "passwd" file. So it will be,
   "vi /media/_/etc/passwd"
   
   
4. Notice that the shell set for admin user is "/bin/cpshell". This shell has a limited functionality. So it restricts most of the common Linux commands to be executed using the admin account. You have to change this shell to "bash".
   For this use your favourite CLI based editor. In my case it will be "vi". Replace the "/bin/cpshell" to "/bin/bash" in the admin user's line. Save it and exit.
   
   
5. Now edit the shadow file inside etc folder. "vi /media/_/etc/shadow". In this file delete the hashed password of the admin user. Save it and exit.
6. Reboot the device.
7. Once the device is booted. Login as admin. You don't have to provide the password. Now you are in Expert mode. (See it's the bash shell that gives you the Expert view :) )
8. Issue "passwd" and change the password. This is the password that you provide for the expert.
9. After you have set the expert password, edit the "/etc/passwd" file. Change the admin user's shell from "/bin/bash" to "/bin/cpshell". Save it and exit.
   
10. Now logout from the shell.
11. The login prompt will appear, login an admin. You don't need any password to login.
    
12. Once you have logged in, issue "passwd". When it asks for the current password, just press Enter, because there is no admin password. Then enter the password you desire.

That's all. :D

Source Routing in Linux

This is about creating source routing in Linux kernel.
For this we'll be using 'iproute2'.
The first file we'll be looking at is 'rt_tables' file. The default complete path for this file is,
'/etc/iproute2/rt_tables'.
Use your favorite editor (gedit, or vi editor) to edit this file. In this file you will see some default values, which are all commented. You will also see some number appearing in them.
The lower the value, the higher the precedence of these numbers will be.
Actually this file holds the name of the routing tables that should looked up for specific instances.
We'll create a routing table name 'my_routes'.
Add the following line to the 'rt_tables' file.

1 my_routes

The next step is to add routes to the table. For this we will use the 'ip route add ' command.
For example we'll say, for all traffic going to 192.168.12.0/24 the next hop is 192.168.12.254 and this entry belongs to the table 'my_routes'.

'ip route add 192.168.12.0/24 via 192.168.1.254 table my_routes'

To add a default route (say the default route is 10.0.0.254)

'ip route add default via 10.0.0.254 table my_routes'

The next step is to say for traffic with a specific source to look-up the table 'my_routes' for routing entries.

'ip rule add from 10.0.0.0/24 table my_routes'

To view the entries,

'ip route show tables'

'ip rule show'

That's it.

Happy Source Routing!!!!

Virtual Private Networks (VPN)

A Virtual Private Network (VPN) is a private network that uses a public network (such as the internet) to connect remote sites or users. VPNs use virtual connections routed through the internet, instead of using dedicated leased line connections. VPN enables distance users to work together. Distant users gain access to the company's private LAN through the internet, so they remain as a part of the private network accessing the company's resources.
The following features are needed for a well-designed VPN:

• Security
• Reliability
• Scalability
• Network and Policy Management

When talking about VPNS, there are three types of VPNs. They are,

• Remote-Access VPN
• Site-to-Site VPN
• MPLS based VPN

Remote-Access VPN
These are also called Virtual Private Dial-up Networks (VPDN).

BIOS Beep Codes

When a computer is first turned on, or rebooted, its BIOS performs a power-on self test (POST) to test the system's hardware, checking to make sure that all of the system's hardware components are working properly. Under normal circumstances, the POST will display an error message; however, if the BIOS detects an error before it can access the video card, or if there is a problem with the video card, it will produce a series of beeps, and the pattern of the beeps indicates what kind of problem the BIOS has detected.

Here a few Beep codes are listed. Mainly for AMD motherboards, but also applicable to Intel systems too.


AMI Beep Codes

1 beep - DRAM refresh failure. There is a problem in the system memory or the motherboard.

2 beeps Memory parity error. The parity circuit is not working properly.

3 beeps - Base 64K RAM failure. There is a problem with the first 64K of system memory.

4 beeps - System timer not operational. There is problem with the timer(s) that control functions on the motherboard.

5 beeps - Processor failure. The system CPU has failed.

6 beeps - Gate A20/keyboard controller failure. The keyboard IC controller has failed, preventing gate A20 from switching the processor to protect mode.

7 beeps - Virtual mode exception error.

8 beeps - Video memory error. The BIOS cannot write to the frame buffer memory on the video card.

9 beeps - ROM checksum error. The BIOS ROM chip on the motherboard is likely faulty.

10 beeps - CMOS checksum error. Something on the motherboard is causing an error when trying to interact with the CMOS.

11 beeps - Bad cache memory. An error in the level 2 cache memory.

1 long beep, 2 short - Failure in the video system.

1 long beep, 3 short - A failure has been detected in memory above 64K.

1 long beep, 8 short - Display test failure.

Continuous beeping - A problem with the memory or video



Phoenix Beep Codes

Phoenix uses sequences of beeps to indicate problems. The "-" between each number below indicates a pause between each beep sequence. For example, 1-2-3 indicates one beep, followed by a pause and two beeps, followed by a pause and three beeps. Phoenix version before 4.x use 3-beep codes, while Phoenix versions starting with 4.x use 4-beep codes.


4-Beep Codes :

1-1-1-3 Faulty CPU/motherboard. Verify real mode.

1-1-2-1 Faulty CPU/motherboard.

1-1-2-3 Faulty motherboard or one of its components.

1-1-3-1 Faulty motherboard or one of its components. Initialize chipset registers with initial POST values.

1-1-3-2 Faulty motherboard or one of its components.

1-1-3-3 Faulty motherboard or one of its components. Initialize CPU registers.

1-1-3-2 Failure in the first 64K of memory.
1-1-3-3 Failure in the first 64K of memory.
1-1-3-4 Failure in the first 64K of memory.

1-1-4-1 Level 2 cache error.

1-1-4-3 I/O port error.

1-2-1-1 Power management error.

1-2-1-2 Faulty motherboard or one of its components.
1-2-1-3 Faulty motherboard or one of its components.

1-2-2-1 Keyboard controller failure.

1-2-2-3 BIOS ROM error.

1-2-3-1 System timer error.

1-2-3-3 DMA error.

1-2-4-1 IRQ controller error.

1-3-1-1 DRAM refresh error.

1-3-1-3 A20 gate failure.

1-3-2-1 Faulty motherboard or one of its components.

1-3-3-1 Extended memory error.

1-3-3-3 Error in first 1MB of system memory.
1-3-4-1 Error in first 1MB of system memory.
1-3-4-3 Error in first 1MB of system memory.

1-4-1-3 CPU error.
1-4-2-4 CPU error.

1-4-3-1 BIOS ROM shadow error.
2-1-4-1 BIOS ROM shadow error.

1-4-3-2 Level 2 cache error.
1-4-3-3 Level 2 cache error.

1-4-4-1 Faulty motherboard or one of its components.
1-4-4-2 Faulty motherboard or one of its components.
2-1-1-1 Faulty motherboard or one of its components.

2-1-1-3 IRQ failure.
2-1-2-1 IRQ failure.

2-1-2-3 BIOS ROM error.

2-1-2-4 I/O port failure.
2-1-3-2 I/O port failure.

2-1-3-1 Video system failure.
2-1-3-3 Video system failure.

2-1-1-3 IRQ failure.
2-1-2-1 IRQ failure.

2-1-2-3 BIOS ROM error.

2-1-2-4 I/O port failure.

2-1-4-3 Video card failure.
2-2-1-1 Video card failure.

2-2-1-3 Keyboard controller failure.
2-2-2-1 Keyboard controller failure.
2-2-2-3 Keyboard controller failure.

2-2-3-1 IRQ error.

2-2-4-1 Error in first 1MB of system memory.

2-3-1-1 Extended memory failure.
2-3-3-3 Extended memory failure.

2-3-2-1 Faulty motherboard or one of its components.

2-3-2-3 Level 2 cache error.
2-3-3-1 Level 2 cache error.

2-3-4-1 Motherboard or video card failure.
2-3-4-3 Motherboard or video card failure.

2-3-4-1 Motherboard or video card failure.
2-3-4-3 Motherboard or video card failure.
2-4-1-1 Motherboard or video card failure.

2-4-1-3 Faulty motherboard or one of its components.

2-4-2-1 RTC error.

2-4-2-3 Keyboard controller error.

2-4-4-1 IRQ error.

3-1-1-1 I/O port error.
3-1-1-3 I/O port error.
3-1-2-1 I/O port error.
3-1-2-3 I/O port error.

3-1-3-1 Faulty motherboard or one of its components.
3-1-3-3 Faulty motherboard or one of its components.

3-1-4-1 Floppy drive or hard drive failure.
3-2-1-1 Floppy drive or hard drive failure.
3-2-1-2 Floppy drive or hard drive failure.

3-2-1-3 Faulty motherboard or one of its components.

3-2-2-1 Keyboard controller error.

3-2-2-3 Faulty motherboard or one of its components.
3-2-3-1 Faulty motherboard or one of its components.
3-2-4-1 Faulty motherboard or one of its components.

3-2-4-3 IRQ error.

3-3-1-1 RTC error.

3-3-1-3 Key lock error.

3-3-3-3 Faulty motherboard or one of its components.


3-3-4-1 Faulty motherboard or one of its components.
3-3-4-3 Faulty motherboard or one of its components.
3-4-1-1 Faulty motherboard or one of its components.
3-4-1-3 Faulty motherboard or one of its components.
3-4-2-1 Faulty motherboard or one of its components.
3-4-2-3 Faulty motherboard or one of its components.
3-4-3-1 Faulty motherboard or one of its components.
3-4-4-1 Faulty motherboard or one of its components.
3-4-4-4 Faulty motherboard or one of its components.

4-1-1-1 Floppy drive or hard drive failure.

4-2-1-1 IRQ failure.
4-2-1-3 IRQ failure.
4-2-2-1 IRQ failure.

4-2-2-3 Faulty motherboard or one of its components.
4-2-3-1 Faulty motherboard or one of its components.
4-2-3-3 Faulty motherboard or one of its components.
4-2-4-1 Faulty motherboard or one of its components.

4-2-4-3 Keyboard controller error.

4-3-1-3 Faulty motherboard or one of its components.
4-3-1-4 Faulty motherboard or one of its components.
4-3-2-1 Faulty motherboard or one of its components.
4-3-2-2 Faulty motherboard or one of its components.
4-3-3-1 Faulty motherboard or one of its components.
4-3-4-1 Faulty motherboard or one of its components.
4-3-4-3 Faulty motherboard or one of its components.

4-3-3-2 IRQ failure.
4-3-3-4 IRQ failure.

4-3-3-3 Floppy drive or hard drive failure.
4-3-4-2 Floppy drive or hard drive failure.


3-Beep Codes

1-1-2 Faulty CPU/motherboard.

1-1-3 Faulty motherboard/CMOS read-write failure.

1-1-4 Faulty BIOS/BIOS ROM checksum error.

1-2-1 System timer not operational. There is a problem with the timer(s) that control functions on the motherboard.

1-2-2 Faulty motherboard/DMA failure.
1-2-3 Faulty motherboard/DMA failure.

1-3-1 Memory refresh failure.

1-3-2 Failure in the first 64K of memory.
1-3-3 Failure in the first 64K of memory.
1-3-4 Failure in the first 64K of memory.

1-4-1 Address line failure.

1-4-2 Parity RAM failure.

1-4-3 Timer failure.

1-4-4 NMI port failure.

2-_-_ Any combination of beeps after 2 indicates a failure in the first 64K of memory.

3-1-1 Master DMA failure.

3-1-2 Slave DMA failure.

3-1-3 Interrupt controller failure.
3-1-4 Interrupt controller failure.

3-2-4 Keyboard controller failure.

3-3-1 CMOS error.
3-3-2 CMOS error.

3-3-4 Video card failure.

3-4-1 Video card failure.

4-2-1 Timer failure.
4-2-2 CMOS shutdown failure.

4-2-3 Gate A20 failure.

4-2-4 Unexpected interrupt in protected mode.

4-3-1 RAM test failure.

4-3-3 Timer failure.

4-3-4 Time of day clock failure.

4-4-1 Serial port failure.

4-4-2 Parallel port failure.

4-4-3 Math coprocessor.

Telephone Ring Detection

Approximate values for telephone line conditions are as follows.

On-hook - 40 – 50 VDC (usually 48V)

Off-hook - 4 – 6 VDC (usually 5V)

Ringing - 90 – 100 VAC

As for the literature the ring detection circuit used in modems is as follows.

The purpose of the two Zener diodes is to avoid detection of small AC transients as ringing. The capacitor used here will block the DC and allow only the AC ringing signal to pass. The diode used in parallel with the photo diode in the opto-isolator is to protect photo diode being damaged by the reverse current.

The frequency of the AC ringing signal is usually 20 – 40 Hz. The transistor in the opto-isollator can be used as a switch. If you connect an LED to see how the switching occurs, you can witness that the LED blinks in either positive or negative half of the ringing signal. If you are planning to get the ringing signal as a logic signal this is not desirable.

To get the ringing signal as a logic signal we can use a full-bridge rectifier circuit to rectify the AC ringing signal.

Lifting the receiver or going off-hook

After detecting the ringing, most of us need our circuitry to answer the call in order carry out further processing like detecting the DTMF entered.

Usually when we lift the receiver the two telephone lines are connected thus closing the loop. When the loop is closed a current around 40mA flows in the line. The Central Office (CO) senses this current.

The standard impedance of a telephone when off-hook is 680 ohms. Hanging a 680 ohms resistor across the telephone line will drop the voltage from 48 V to about 5 V. This will cause the line to go active.

Passing BCMSN 642-812

For BCMSN exam I did not attend for any classes and did not do any labs. But strictly speaking this is not good. To me BCMSN is not that much important to me. That's why I did not put that much effort on that. And that's the main reason why I got very low marks in that exam.
The concepts in the BCMSN was important to me.
I don't have much experience in BCMSN to share with you.