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. :)