Check Point Firewall-1 NGX - Automatic Address Translation - Proxy ARP Fails

Scope

This technote refers to an issue that arose following an upgrade from Check Point Firewall-1 NG FP2 running on a Windows 2000 Server to Check Point Firewall-1 NGX running on SecurePlatform.

The network diagram above represents the overall configuration described by this technote.

The problem with Address Translation has always been an issue of getting hardware devices on a network to talk to other devices that are not actually there.

Originally when configuring a Check Point Address Translation solution, you where required to either proxy ARP for the translated addresses or you had to add host static routes to the next hop router, forcing it to send packets destined for the external address to the Firewall where they could then be correctly handled.

The next step was to ensure that the Firewall routed the packet correctly and forced it out of the right interface and on the the internal host. This was normally handled using a host static route on the Firewall forcing the external translated address on to the internal host.

As Check Point has updated and upgraded their product the need for this additional work is supposed to have been removed, and indeed when testing against a fresh install, it has been.

When using automatic address translation, the Firewall will automatically start to proxy ARP for any addresses that it is performing static address translations on. Also since the introduction on Check Point NG, the stage in the process that the address translation occurs has been moved to a point before the system makes a routing decision on where to send the packet. This should in theory remove the need for any intervention at the OS level.

However during a recent upgrade, this was proved not to be the case. Despite the install and upgrade both going smoothly, it was found that address translation failed completely and the Firewall didn't appear to make any attempt to proxy ARP for translated addresses.

Solution

It was possible to prove the basic functionality of the server by putting a host static route on the external client and forcing the translated address to the external interface of the firewall, unfortunately there where too many hosts on the external network to make this a viable solution and therefor more digging was require.

A quick trawl of the Internet turned up a couple of options, but nothing really seemed to solve the issue completely.

The main issue seems to be that if proxy ARP does fail, you need to edit /etc/sysctl.conf and add the following lines:

net.ipv4.conf.all.proxy_arp = 1
net.ipv4.conf.default.proxy_arp = 1

Then either reboot the machine or run sysctl -p

While we had limited success with this (everything worked until a reboot), we also found it necessary to add host static routes onto the Firewall platform forcing the translated external address on to the internal host. (Note this needs to be done within the web interface if you with the changes to be permanent.)