- Introduction
- RFC-1918 and Link Local Addresses
- How NAT Works in FireWall-1
- Implementing NAT: A Step-by-Step Example
- Limitations of NAT
- Troubleshooting NAT
- Summary
- Sample Configurations
This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementing NAT: A Step-by-Step Example
The following sample configuration involves NAT. You are shown what you need to do step-by-step to configure FireWall-1 to support this configuration. (See Figure 9-3.)
){kind=link}
The security policy is defined as follows:
Figure 9-3 Implementing NAT sample network
Allow the External Mail and Web server to be reached from anywhere via SMTP and HTTP respectively.
Allow the External Mail Server to send e-mail to anywhere on the Internet and to the Internal Mail Server.
Allow a second Web instance of a Web server (running on port 81) to be accessible via a separate IP address on port 80.
Allow clients on Segment A and Segment B to browse the Internet via HTTP or HTTPS hiding behind a single IP address.
Allow an Intranet Web server to be accessible on the Internet via HTTP. The Web server will provide its own authentication, so no authentication is necessary by FireWall-1.
Except for the former requirements, deny all other traffic.
The preceding policy is specially crafted for demonstration purposes only. Generally speaking, it is not wise to permit traffic from the Internet all the way into the internal network without some sort of encryption. Let's take the following steps to set this up:
Determine which IP addresses will be used for translation.
Set up the necessary proxy-ARPs.
Set up the necessary static host routes.
Create the necessary network objects.
Make the necessary modifications to anti-spoofing.
Create the necessary rulebase rules to permit the desired traffic.
Create the NAT rules.
Install the security policy, and verify that everything works as planned.
Determining Which IP Addresses Will Be Used
The legal addresses include everything in 192.168.0.0/24 except for the firewall (.1) and the router (.2). You can choose any other IP address in the range. The following hosts will use the following static mappings:
External Mail Server: 192.168.0.10
Web Server: 192.168.0.11
Web Server (instance on port 81): 192.168.0.12
Intranet Web Server: 192.168.0.13
For the browsing that Segment A and Segment B hosts will need, use the firewall's external IP address of 192.168.0.2.
Proxy-ARPs
Before you begin, you need to determine which MAC address you are going to use to ARP for the translated IP addresses. You know that all of the translated addresses are on the same subnet as the external interface of the firewall. You simply need to determine what the MAC (or physical) address of the external interface is and use that address. To do this, use the following command:
On a UNIX platform, you will see something like this:5
lo0: flags=849 <UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
le0: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu
1500
inet 192.168.0.1 netmask ffffff00 broadcast
192.168.0.255
ether 0:11:22:33:44:55
le1: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu
1500
inet 10.0.0.1 netmask ffffff00 broadcast 10.0.0.255
ether 0:c0:78:2:0:d6
le2: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu
1500
inet 172.16.0.1 netmask ffffff00 broadcast 172.16.0.255
ether 0:c0:78:20:0:6d
On a Nokia platform, the output is slightly different:
loop0c0: flags=57<UP,PHYS_AVAIL,LINK_AVAIL,LOOPBACK,MULTICAST>
inet mtu 63000 127.0.0.1 —> 127.0.0.1
phys loop0 flags=10b<UP,LINK,LOOPBACK,PRESENT>
tun0c0: lname tun0c0
flags=cf<UP,PHYS_AVAIL,LINK_AVAIL,POINTOPOINT,MULTICAST> encaps
vpn
phys tun0 flags=107<UP,LINK,POINTOPOINT,PRESENT>
eth-s1p1c0: lname eth-s1p1c0
flags=e7<UP,PHYS_AVAIL,LINK_AVAIL,BROADCAST,MULTICAST>
inet mtu 1500 192.168.0.1/24 broadcast
192.168.0.255
phys eth-s1p1 flags=133<UP,LINK,BROADCAST,
MULTICAST,PRESENT>
ether 0:11:22:33:44:55 speed 100M full duplex
eth-s2p1c0: lname eth-s2p1c0
flags=e7<UP,PHYS_AVAIL,LINK_AVAIL,BROADCAST,MULTICAST>
inet mtu 1500 10.0.0.1/24 broadcast 10.0.0.255
phys eth-s2p1 flags=133<UP,LINK,BROADCAST,
MULTICAST,PRESENT> ether 0:c0:78:2:0:d6 speed 100M full
duplex
eth-s3p1c0: lname eth-s3p1c0
flags=e7<UP,PHYS_AVAIL,LINK_AVAIL,BROADCAST,MULTICAST>
inet mtu 1500 172.16.0.1/24 broadcast
172.16.0.255
phys eth-s3p1 flags=133<UP,LINK,BROADCAST,MULTICAST,
PRESENT> ether 0:c0:78:20:0:6d speed 100M full duplex
On a Windows NT or 2000 platform, you will see this:
Ethernet adapter 3C5x91:
Description . . . . . .: 3Com 3C5x9 Ethernet
Adapter
Physical Address. . . .: 00-11-22-33-44-55
DHCP Enabled. . . . . .: No
IP Address. . . . . . .: 192.168.0.1
Subnet Mask . . . . . .: 255.255.255.0
Default Gateway . . . .: 192.168.0.254
Ethernet adapter 3C5x92:
Description . . . . . .: 3Com 3C5x9 Ethernet
Adapter
Physical Address. . . .: 00-C0-78-20-00-6D
DHCP Enabled. . . . . .: No
IP Address. . . . . . .: 10.0.0.1
Subnet Mask . . . . . .: 255.255.255.0
Default Gateway . . . .:
Ethernet adapter 3C5x93:
Description . . . . . .: 3Com 3C5x9 Ethernet
Adapter
Physical Address. . . .: 00-0C-87-02-00-D6
DHCP Enabled. . . . . .: No
IP Address. . . . . . .: 172.16.0.1
Subnet Mask . . . . . .: 255.255.255.0
Default Gateway . . . .:
Use the ether or physical address of the system's external interface. In this case, you will use 00:11:22:33:44:55. Now that you know what that MAC address is, you can set up the ARPs. On UNIX systems, this is done as follows:
arp -s 192.168.0.10 00:11:22:33:44:55 pub
arp -s 192.168.0.11 00:11:22:33:44:55 pub
arp -s 192.168.0.12 00:11:22:33:44:55 pub
arp -s 192.168.0.13 00:11:22:33:44:55 pub
In order for these ARPs to be available on reboot, you need to add them to a file that executes on startup. Do not add them to the /etc/rc3.d/S95firewall1 script, which gets overwritten during an upgrade. Create a new startup script like /etc/rc3.d/S94nat.
Windows NT does not have a proxy-ARP facility, so Check Point has included it as part of the software. Create the file %FWDIR%\state\local.arp, and enter the following information:
192.168.0.10 00-11-22-33-44-55
192.168.0.11 00-11-22-33-44-55
192.168.0.12 00-11-22-33-44-55
192.168.0.13 00-11-22-33-44-55
These ARPs will not become active until a policy reload is performed. In some cases, it may be necessary to stop and start FireWall-1.
NOTE
The Windows 2000 version of FireWall-1 does not support local.arp prior to version 4.1 SP4. Refer to article ID sk699 in Check Point's Knowledge Base for a workaround.
NOTE
FireWall-1's proxy-ARP function will not work in Windows 2000 if you are running Microsoft's Routing and Remote Access Service. Microsoft has produced a hot fix to this issue. To obtain this hot fix, refer to article ID Q82312 in Microsoft's Knowledge Base.
On the Nokia platform running IPSO 3.1 and later, add these ARPs via the Voyager interface as "Proxy-Only" type. In a VRRP configuration, configure both firewalls and use the VRRP MAC address instead of the network card's MAC. You may also configure the NAT IPs as VRRP backup IPs, thus eliminating the need for proxy-ARPs.
NOTE
Do not configure the NAT IPs as VRRP backup IPs in FireWall-1 4.1 SP2, because there are some bugs with the anti-spoofing code.
NOTE
In IPSO 3.3 or later, there is an option to allow connections to VRRP IP addresses. Make sure this option is disabled if you plan on configuring the NAT IPs as VRRP IPs.
NOTE
There is a bug with proxy-ARP when used with VRRP MAC addresses that causes some switches to become confused. IPSO 3.3 FCS8, IPSO 3.3.1 FCS7, and IPSO 3.4 and later resolve this problem. Refer to Resolution 3324 in the Nokia Knowledge Base for more details.
Static Host Routes
The only translations for which you need to set up static host routes are those that involve a destination static translation (i.e., where the destination IP address needs to be translated). In this case, you need to set up static host routes for all of them because they will all be connected by their translated IP address.
You need to determine where the real hosts for the virtual IPs are in relation to the firewall. This is so you can determine the next hop for the static host routes you will set up. Using Figure 9-3, you know the following information:
The external mail and external Web servers are on the same subnet as the firewall. In this case, you simply use the real host's IP address as the next hop.
The intranet Web server is not on the same subnet as the firewall. In this case, you want to use the next hop IP address, which is the router that is connected to Segment A—the segment on which the intranet Web server is connected. This is 10.0.0.2.
On UNIX platforms (not IPSO), you would add the static routes like this:6
route add 192.168.0.10 172.16.0.25 1
route add 192.168.0.11 172.16.0.80 1
route add 192.168.0.12 172.16.0.80 1
route add 192.168.0.13 10.0.0.2 1
Like the previous ARPs, these lines need to go into a startup file so that they are available after a reboot. On Windows NT platforms, the static routes are similar:
route add 192.168.0.10 172.16.0.25 –p
route add 192.168.0.11 172.16.0.80 -p
route add 192.168.0.12 172.16.0.80 -p
route add 192.168.0.13 10.0.0.2 -p>
Note that on Windows NT/2000, if you use the -p flag, the routes are persistent; that is, they are stored in the Registry and will stay there until they are deleted, even after a reboot.
On a Nokia platform, you add these static routes via Voyager.
Network Objects
You must create network objects for both translated and untranslated objects as well per Table 9-2.
Anti-Spoofing
When configuring your firewall object, set your Valid Address settings according to the settings shown in Table 9-3.
These settings are configured on the Interfaces tab. Also, make sure that each interface has the Spoof Tracking set to "Log" to catch any errors in the anti-spoofing configuration.
Security Policy Rules
The rules created are based on the security policy defined earlier in the "Implementing NAT, a Step-by-Step Example" section. (See Figure 9-4.)
Address Translation Rules
Once the security policy is defined, NAT rules must be defined. Before you begin, make sure you define a service for port 81. It will be a service of type TCP. In Figure 9-5, it will be referred to as "http81," so you can do the port translation that the security policy requires. Note that the "s" refers to "static" rules, and the "h" refers to "hide" rules. (See Figure 9-5.)
){kind=link}
Install the Security Policy and Test
Initiate a connection to exercise each rule to ensure that each rule is functioning as you expect. Test access from inside and outside the network.