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!