The PhoneBoy Blog

FireWall-1 FAQ: Routing and ARP Issues with NAT

Last Modified: 11 Nov 2001

Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.

I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.

If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)

---

Q:

I could configure the Address Translation. I am having difficulties in passing through the firewall now. The log shows as the telnet session got established but I couldn’t get the log on messages.

Check Point’s User Guide didn’t suggest anything on how the routes are to be established on the Firewall system with Address Translation. One of the interfaces of Netra is connected to our local network (126.0.10.0 - an illegal ip address) and the other interface is connected to the 206.99.98.0 which is our official Class C.

Our NAT rules look like:

</table> ## A: The following considerations apply when using address translation: **[Routing](#Routing)**: * Not translating the FireWall-1 machine internal address * Destination Static translation needs explicit route **[ARP](#ARP)** * Proxy ARP for Source Static and Hide ### Some Background Information A full connection from machine A to machine B requires that packets can travel from machine A to machine B AND back from machine B to machine A. Getting a packet from machine A to machine B can generally be divided into 2 stages * **Stage 1**: Getting the packet from network A to network B. The simplest case being that network A and B are the same network. This is where routing occurs. * **Stage 2**: Once we get to network B, how to deliver it to machine B. This is where ARP comes in. Stage 1 involve routing. Routing tells machine A the next hop that machine A can send the packet destined for machine B. These are the commands you will most likely need, though check your operating system manuals for details: netstat -rn route add ... route delete ... Stage 2 involes ARP. ARP is used to find the MAC address of the machine on the local network. The MAC address is needed to deliver a packet to a local machine. There are the commands you will most likely need, though check your operating system manuals for details: arp -a arp -s ... arp -d ... ### Back to FireWall-1 address translation specific problem #### Routing **Not translating the FireWall-1 machine internal address:** This rule:

#	Original</td>			Translated</td> </tr>
	Source	Destination	Service	Source	Destination	Service
1	126.0.10.150	Any	Any	206.99.98.2 (S)	Orig	Orig
2	206.99.98.2	Any	Any	126.0.10.150 (S)	Orig	Orig
3	126.0.10.1-126.0.10.49	Any	Any	206.99.98.10 (H)	Orig	Orig
4	126.0.10.51-126.0.10.254	Any	Any	206.99.98.10 (H)	Orig	Orig
5	126.0.11.1-126.0.11.254	Any	Any	206.99.98.11 (H)	Orig	Orig

4

126.0.10.51-126.0.10.254

Any

Any

206.99.98.10 (H)

Orig

Orig

will hide the internal interface of the firewall-1 machine (le0 - 126.0.10.98). The above rule will cause subtle routing problem that are very hard to debug. For example, an http session started from the firewall machine to the web server 126.0.10.50 will hide the source address 126.0.10.98 to 206.99.98.10. Packets from 206.99.98.10 (126.0.10.98) will get to 126.0.10.50 OK, but it's likely that the return packets from 126.0.10.50 to 206.99.98.10 (126.0.10.198) will not back unless 126.0.10.50 has a route to reach 206.99.98.10. You can avoid this problem by splitting the above rule into two rules:

4	126.0.10.51-126.0.10.97	Any	Any	206.99.98.10 (H)	Orig	Orig
5	126.0.10.99-126.0.10.254	Any	Any	206.99.98.10 (H)	Orig	Orig

or you can create a "no translate" rule for the 126.0.10.0 network like this:

4	126.0.10.0/255.255.255.0	126.0.10.0/255.255.255.0	Any	206.99.98.10 (H)	Orig	Orig
5	126.0.10.51-126.0.10.254	Any	Any	206.99.98.10 (H)	Orig	Orig

If you REALLY REALLY need to have just one rule, you will need to make sure that there is a route from your internal network to 206.99.98.10. #### Destination Static translation needs explicit route Because translation occurs after routing in FireWall-1 4.1 and earlier, all destination static translations require a route on the firewall machine in the following form: route add _translated_address_ _original_address_ 1 For example, for the following rule <1, 206.99.98.2, 206.99.98.2, FWXT_DST_STATIC, 126.0.10.50, 0>, you will need to add, on the Unix server: route add 206.99.98.2 126.0.10.50 1 Hint: you could modify the FireWall-1 startup script to include those route commands so that they will be run automatically after FireWall-1 has started. For Windows NT and 2000, the syntax is a little different: route -p add 206.99.98.2 126.0.10.50 The '-p' option adds the route into the Windows NT registry so that the route will be enabled even after a reboot. If the original address is more than one hop away from the firewall (i.e. it is on a different logical network segment), then use the IP address of the "next hop" instead of the original address. NG is a little different in this regard, depending on whether manual or automatic rules are used. See [How NAT works in NG](/fw1/faq/0430.html). ### ARP #### Proxy ARP for Source/Destination Static and HIDE translations The firewall needs to advertise all the translated IP addresses as its own so that when a packet (destined for the translated IP address) has reached its final hop (network 206.99.98.0, in this case), the packet can be delivered locally. This is what is known as a proxy-arp. In the NG release of FireWall-1, you can enable the property "Automatic ARP Configuration" in the Global Properties, Network Address Translation tab. This handles all the chores of creating proxy-arp entries. However, this will only work for automatic NAT entries. In 4.1 and earlier releases, or in NG if manual NAT is used, you can use the command 'arp -s' to add an "proxy" arp entry in Unix. See 'man arp' for more information. To use 'arp -s', you will need to know the MAC address of the external interface. In Unix, use 'ifconfig -a' to get that information. In this case, the MAC address of the external interface (be0) is 0:c0:78:20:0:6d. be0: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500 inet 206.99.98.1 netmask ffffff00 broadcast 206.99.98.255 ether 0:c0:78:20:0:6d You will need to add arp -s _translated_address_ _mac_address_ pub So if you have the following address translation table: </table> You will need to add arp -s 206.99.98.2 0:c0:78:20:0:6d pub arp -s 206.99.98.10 0:c0:78:20:0:6d pub arp -s 206.99.98.11 0:c0:78:20:0:6d pub Hint: Again, you could modify the startup scripts to include those route commands so that they will be run automatically after the system has started. Proxy ARPs are also need in Windows NT. Unfortunately, the ARP command in Windows NT can not be used for this purpose. To do this on NT, see the following FAQ entry: [ARPs on NT Disappear After a Short Time](/fw1/faq/0008.html).

#	Original</td>			Translated</td> </tr>
	Source	Destination	Service	Source	Destination	Service
1	126.0.10.150	Any	Any	206.99.98.2 (S)	Orig	Orig
2	206.99.98.2	Any	Any	126.0.10.150 (S)	Orig	Orig
3	126.0.10.1-126.0.10.49	Any	Any	206.99.98.10 (H)	Orig	Orig
4	126.0.10.51-126.0.10.254	Any	Any	206.99.98.10 (H)	Orig	Orig
5	126.0.11.1-126.0.11.254	Any	Any	206.99.98.11 (H)	Orig	Orig