The PhoneBoy Blog


Simplifying Telecom, Mobile Phones, Gadgets, and More!

FireWall-1 FAQ: Routing and ARP Issues with NAT

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 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 <UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
            inet 127.0.0.1 netmask ff000000 
    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 
    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

  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

A:

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 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:

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.

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:

#

Original

Translated

  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 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.

C-List #Cybersecurity Celebrity, Podcaster, #noagenda Producer, Frequenter of shiny metal tubes, Expressor of personal opinions, and of course, a coffee achiever.