Routing and ARP issues with NAT

[roadrunner]

Routing and ARP issues with NAT
Contributed by PhoneBoy
Published in geeklog Saturday, May 17 2003 @ 05:02 AM EST
Published in oldfaq 2002-Nov-10 00:16 dwelchATphoneboyDOTcom
The following document explains various routing and ARP issues that occur with address translation.


Question
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 network
----------------------------------------------------------------------------
|
|
L|
o|
c|
a| --------- -------- ----
l| 126.0.10.98| Fire |206.99.98.1 | | |CSU | MCI
|-------------| |-----------------| Router |----| |----------
N| le0 | Wall |be0 | | |DSU |
e| |_________| |________| |____|
t|
|
|
|
126 |
. | --------
0 |------|Web serv|126.0.10.50
. | --------
10 |
. | ----
0 |------|FTP |
| ----
|
| -----
|------|Mail |
| -----
|
----------------------------------------------------------------------------

--------------------------------------------------------------------------
Output of 'ifconfig -a'
--------------------------------------------------------------------------
# ifconfig -a
lo0: flags=849 mtu 8232
inet 127.0.0.1 netmask ff000000
be0: flags=863 mtu 1500
inet 206.99.98.1 netmask ffffff00 broadcast 206.99.98.255
ether 0:c0:78:20:0:6d
le0: flags=863 UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 126.0.10.98 netmask ffffff00 broadcast 126.0.10.255
ether 0:c0:78:20:0:6d
Our NAT rules look like:

Original Translated
No. 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



Answer
The following considerations apply when using address translation:


Routing:
Not translating the FireWall-1 machine internal address
Destination Static translation needs explicit route
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 AGetting 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 involves 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:

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 1For 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 1Hint: 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.50The '-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 FireWall-1 NG.


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 pubSo if you have the following address translation table:

Original Translated
No. 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


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 pubHint: 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 disappear after a short time on Windows.

-- RayLodato - 07 Jan 2004


FAQForm
FAQs.Class: NetworkAddressTranslationFAQs
FAQs.OS:
FAQs.Version: