Configure Policy-Based Routing On Check Point Secure Platform

There's no straight-forward way to achieve policy-based routing on Check Point SPLAT (Secure Platform). Since SPLAT is Linux-based and Check Point firewalls relies on operating system routing functions, policy-based routing is also archived through iproute2 - a set of utilities used to control network traffic on Linux systems. iproute2 is available with most of the Linux distributions (including SPLAT) with a kernel version above 2.2.

For more information about iproute2, please refer to the links in the Additional References section of this article.

When configuring policy-based routing with iproute2 on SPLAT, there is some important point you need to remember.

1. You need to configure a routing table per policy and it's independent of your normal routing table
2. Because of that, once a policy is matched only that particular table is looked for routing
3. Therefore you must manually add all the routing information (including directly connected routes) for each and every table you create
4. route --save command does not save the policy based route you configure using ip route command.

With those points in mind, let's look at a scenario and configure policy-based routs.

In the above diagram, there's a simple, typical network.

• There are two internet connections. One leased line to access internally hosted mail, web and name servers. And one ADSL connection for employees to access the internet. 
• All the internal users use proxy server 172.16.0.10 to access the internet. 
• Now the objective of this policy routes is to direct traffic coming from the proxy through the ADSL connection and all the other traffic should go through the internet leased line.

Current routing configuration of the firewall is as follows:

Defining the Table

First, we must tell the kernel that we have a new table. You should give a distinct name for the table - let's call it PROXY.

edit /etc/iproute2/rt_tables file using a text editor and append the following line to it.

10 PROXY

The same thing can be achieved with echo using output redirection:

echo "10 PROXY" >> /etc/iproute2/rt_tables

Now the kernel knows that there's a table called PROXY, now we have to specify for which traffic this table should be looked at.

Defining Matching Criteria

iproute2 has the ability to match incoming interface, source address, ToS (type of service), etc. In this case, we are going to match the source address. Matching criteria is defined using ip rule add command.

ip rule add from 172.16.0.10/32 table PROXY

Now the kernel knows that, if it receives a packet from the above IP address, the PROXY table should be looked for routes.


Configuring Route

Instead of the old route add command iproute2 uses ip route add command. And there are two additional parameters at the end. First, you must tell what the exit interface is. And you must also indicate the table name which the route belongs to.

# Default route
ip route add default via 192.168.1.1 dev eth3 table PROXY


# Static routes
ip route add -net 10.0.0.0/16 via 10.0.0.2 dev eth0 table PROXY

Directly Connected Routes

Remember the second point? Because of your custom routing table is independent of your default routing table, once a policy is matched only that particular table is looked for routing. In this case, only the PROXY tabled is matched. However, PROXY table does not know about any directly connected routes. Therefore those also need to be added to the PROXY table.

# Directly Connected Networks
ip route add -net 1.1.1.0/29 dev eth2 table PROXY

ip route add -net 10.0.0.0/24 dev eth0 table PROXY

ip route add -net 192.168.1.0/24 dev eth3 table PROXY

ip route add -net 172.16.0.1/24 dev eth1 table PROXY

Making Source Route Effective
 
The routes we just added will not take effect until the route cache is flushed (or cache expire - this takes some time).

# Flush the route cache
ip route flush cache

Make the Policy Routes Survive Reboots

Now, these routing tables are effective and you can perform troubleshooting. However, these routes do not survive if you reboot the gateway. To overcome this problem, you need to apply this routing table each time the router reboots.

First, create a file called /etc/rc3.d/S99PolicyRoutes and add all the "IP *" lines you previously typed into the script. For more information about Linux start-up script, click here.

vi /etc/rc3.d/S99PolicyRoutes

#### Policy routes for the proxy server ####

# Rules
ip rule add from 172.16.0.10/32 table PROXY

# Default route
ip route add default via 192.168.1.1 dev eth3 table PROXY

# Static routes
ip route add -net 10.0.0.0/16 via 10.0.0.2 dev eth0 table PROXY

# Directly Connected Networks
ip route add -net 1.1.1.0/29 dev eth2 table PROXY
ip route add -net 10.0.0.0/24 dev eth0 table PROXY
ip route add -net 192.168.1.0/24 dev eth3 table PROXY
ip route add -net 172.16.0.1/24 dev eth1 table PROXY

# Flush the route cache
ip route flush cache

You also need to set the execute flag for the script

chmod +x /etc/rc3.d/S99PolicyRoutes

Troubleshooting

There are a few commands that you can use to troubleshoot routing issues.

View the main routing table (this does not show policy routing tables)

ip route list

or  

netstat -nr

or  

route

View policy routing table

ip route list table PROXY

PROXY is the name of the table

Check how the gateway route packets
You can check how the gateway routes packets without actually sending any packets to the gateway using ip route get command. Syntax of the command is as follows:

ip route get ADDRESS [ from ADDRESS iif STRING ] [ oif STRING ] [ tos TOS ] 

The man page describes the switches and options as follows:

to ADDRESS (default)

the destination address.

from ADDRESS

the source address.

tos TOSdsfield TOS

the Type Of Service.

iif NAME

the device from which this packet is expected to arrive.

oif NAME

force the output device on which this packet will be routed.

connected

if no source address (option from) was given, relookup the route with the source set to the preferred address received from the first lookup. If policy routing is used, it may be a different route.

Note that this operation is not equivalent to ip route show. show shows existing routes. get resolves them and creates new clones if necessary. Essentially, get is equivalent to sending a packet along this path. If the iif argument is not given, the kernel creates a route to output packets towards the requested destination. This is equivalent to pinging the destination with a subsequent ip route ls cache, however, no packets are actually sent. With the iif argument, the kernel pretends that a packet arrived from this interface and searches for a path to forward the packet.

To check the policy routing table, you need to specify from and iff options. For example, if you need to test how the gateway would router a packet cumming from the proxy server (172.16.0.10) and going out to the internet, type in the following command.

ip router get 8.8.8.8 from 172.16.0.10 iif eth1

Verifying Routing Table Using fw monitor.

fw is a utility that comes with Check Point and with fw monitor, you can capture and print packets passing through Check Point gateway. The most important feature in fw monitor to check ip router is that it displays incoming and outgoing interfaces of packets. There two good documents that you can refer on fw monitor on the internet: fw monitor cheat sheet by Jens Roesen and fw monitor guide on cpug.org.

To use fw monitor, you need to send packets. For example, if you need to test the policy routes we just created for the proxy, you need to send packets from the proxy.

In the following example, we are going to see the gateway would route packets to destination 8.8.8.8 from the proxy server (it should use the eth3 [ADSL] port as the outgoing interface.

fw monitor -e "accept src=172.16.0.10 and dst=8.8.8.8;"

You need to check the incoming (simple "i") and outgoing interface (simple "o") in the output. If you get eth3:o ... in the output, that means the policy routing table we just created works. Please refer to Check Point documentation for more information about Check Point's input and output notations.

Additional References

• IPROUTE2 Utility Suite Howto
• Linux Advanced Routing & Traffic Control HOWTO
• ip command man page
• fw monitor cheat sheet by Jens Roesen