Static routing is supported by CKP (Checkpoint firewalls or gateways). Let’s recall that a static route defines a destination subnet or network and the way to reach it: the outgoing interface on the gateway, a connected nexthop ip address… whatif we configure this static routing using an intermediate address: an address of a nexthop that is not directly connected? in many other platforms, this works if the intermedaite nexthop address is resolvable to a directly connected one (any router interface).

But it is not possible to configure a static route with an intermediate address in a Checkpoint security gateway. Let’s check this statement found in the configuration guide.

Lab setup

In our lab setup: a network with four routers simulating connecting networks and two security gateway managed by a single SM, R4 tries to reach R3 using its loopback0 interface as the source. To reach R3, a packet from R4 loopback passes R4 interface in network 20.3.4.0, passes R1, gets through SG1 before R3 interface in network 10.1.2.0.

R4 is configured with a default static route that points to R1 interface in the subnet 20.3.4.0/24. All traffic behind R4 (including the loopback0) is routed by default to R1.

Both R1 and R3 are configured with a default static route pointing towards firewall SG1. All traffic from R1 (and behind from R4) and R3 is routed by default to SG1.

In addition router R1 is configured with a more specific route that points towards R4 to reach 4.4.4.4/32 network. The R4 loopback from the perspective of R1 is behind R4, not on the shared connected subnet.

SG1 is configured with rules to allow such a traffic and anti-spoofing has been disabled for simplicity (to keep only the features needed to demonstrate our case). A rule si set to allowed explicitly any traffic from/to R4 loopback interface towards R3.

We check that traffic is allowed through the firewall (in smartView) :

We configure a static route on SG1 pointing to R4 loopback interface network with a nexthop on the directed connect network to R1 and check its state in the firewall routing table (shell mode):

In the routing table (using commande show route static in shell mode) the route is compiled, present with coherent information: correct output interface eth3 towards R1, with cost of 0 (being connected).

We test that the setup is working by doing pings from R4 to R3. R4 is receiving replies from R3 through SG1. The setup is up. Let’s move to our test of the intermediate nexthop: R4 interface in the intermediate subnet 20.3.4.0 (not directly connected to SG1).

configuring an intermediate next hop address instead of the directly connected one

Let’s try to point this static route to R4’s intermediate address 20.3.4.2 instead of R1’s directly connected address by shutting down the first static route and bringing on the same route with only the nexthop change:

The “show route static” in shell mode shows that the route configuration is accepted by the firewall. It means that pre-checks (during parsing or compilation) did not fail. We add another route to show the firewall how to get to the intermediate subnet. We expect that both routes would be installed in the routing table… BUT!

limitation

But the 4.4.4.4/32 (R4 loopback0 subnet) is not installed in the routing table. Only the static route to the intermediate address is added and resolved to the directly connected nexthop. If the nexthop is not directly connected the route is not installed…

This route would have eventually allowed for a recursive route lookup in the routing table as it is the case on many other platforms (Cisco, Juniper, etc.) and solve many situations where the directly connected nexthop is not possible, changing or not available.

This is very limiting because it does not allow the configuration to respond to this example case or need:

1. If we don’t have the control over the next hop address of router R1? in the case it is assigned dynamically by the ISP or partner?
2. and without the use of a dynamic routing protocol?

hopefully there is a workaround to this situation to get work on CKP gateway.

workaround (in expert mode)

It is possible to do it (to get static route with intermediate address work) thanks to a trick hinted by: https://www.adminsehow.com/2011/09/gateway-on-a-different-subnet-on-linux/. The idea is simple: add the intermediate subnet to the outgoing interface at system level (physically the network is one hop far).

We check in our table (using shell) that no route exists to our destination 4.4.4.4/32:

doing it in expert mode (versus shell mode)

In expert mode we check the same and add our intermediate gateway address as being attached to eth3 by using the command route add dev (device) eth3:

Now we add our route. We check that it shows only in the expert mode table (not in shell mode… which is problematic, inconsistent) and that pings are successful.

What is weirder is that pings are successful and getting through the firewall even if:

1. the route is not present in the shell routing table
2. the gateway (intermediate nexthop address previousely configured in expert mode) has been deleted from the expert mode!

As conclusion

We were able to get intermediate next hop address work in doing static routing but in expert mode. What it is weird is that the setup continues to work evenif our changes (adding the ip address of the intermediate nexthop to the gateway interface) were undone!

See you next to try to understand this…