Sample Configuration with NAT

[roadrunner]

Sample Configuration with NAT
Contributed by BenSmith
Published in geeklog Wednesday, June 25 2003 @ 07:28 PM EST
Published in oldfaq 2002-Nov-23 00:47 dwelchATphoneboyDOTcom

Here's a detailed example of how to set this up NAT with a very simple network. Though I don't necessarily recommend having machines that provide external services on the same network as your clients and internal servers (see below), it is effective for demonstration purposes.

NAT is as much a part of the security policy as the rules in the Security Policy. NAT should be taken into consideration when planning a security policy. In this example, private address space is being used on the internal network, which means NAT is required if machines on the internal network need to talk to the Internet.

The security policy for this site is as follows:


Allow all client machines to access the web and FTP sites
Allow outbound SMTP traffic through the SMTP server
Allow inbound SMTP and WWW traffic to the Mail and Web servers respectively.
Except for the above, deny all other traffic.
The network looks like this:


____________
| |
-------------------------------| FireWall |------------------------- Router
| 192.168.0.1 |____________| 204.32.38.1 204.32.38.254
|
|---- Web Server (192.168.0.2)
|
|---- SMTP Server (192.168.0.10)
|
|---- Client machines (All other IPs)
The internal network is an RFC-1918 network (the 192.168.0 class 'C'). The external network is 204.32.38.0. The firewall has a default route set to 204.32.38.254 and has IP forwarding enabled (the firewall should disable this when a security policy is unloaded). All the machines on the 192.168.0.0 network have their default routers set to 192.168.0.1.

Since the SMTP server and WWW server provide services to the outside world, they will require static address translations. The SMTP server's "legal" IP address (e.g. the IP the Internet will know it by) will be 204.32.38.2 and the web server's "legal" IP address will be 204.32.38.10. The rest of the machines will hide behind the firewall's external IP address (204.32.38.1).

There are five things that need to be done here.


Configure the network objects in FireWall-1
Configure the security policy in FireWall-1
Configure the NAT rules in FireWall-1
Configure the OS of the firewall and/or other devices for NAT
Install the new security policy
If anti-spoofing is configured, changes will need to be made to that configuration.


Configure the Network Objects
Whenever crafting a security policy, define all the objects that will make up your security policy first. Without these objects, it will be difficult to define the security policy in a desirable manner. The network objects below will be used throughout the rest of this document. Don't worry if you don't understand why these objects need to be created -- it will be explained later.

Object Name Description
InternalNet The 192.168.0.0/24 network.
InternalNetRange A range object that covers all IP addresses from 192.168.0.2 to 192.168.0.254.
SMTP-Server The SMTP server's "real" IP address (192.168.0.2).
SMTP-Server-External The SMTP server's "legal" IP address (204.32.38.2).
WWW-Server The WWW server's "real" IP address (192.168.0.10).
WWW-Server-External The WWW server's "legal" IP address (204.32.38.10).
Firewall The network object for the firewall (defined as an internal gateway with FireWall-1 Installed). Though all of it's interfaces are defined in the Interfaces section, the IP address listed in the network object itself is 204.32.38.1 (it's external IP).



Creating the Security Policy
The security policy would look like this:

No. Source Destination Service Action Tracking
1. InternalNet any ftp,http accept long
2. SMTP-Server any smtp accept long
3. any SMTP-Server-External smtp accept long
4. any WWW-Server-External http accept long
5. any any any drop long


The rules perform the following functions :


Allow Internal machines to access to the web and FTP sites.
Allow the SMTP server to send outbound mail.
Allow the SMTP server to receive incoming mail.
Allow everyone on the Internet to access the web server via HTTP.
Except for the above rules, drop all other traffic
Notes:


Both Security Policy rules and NAT rules are matched in-order.
Since NAT happens after the traffic has been scanned by the security policy, the security policy needs to be defined in terms of how the firewall will see the traffic before NAT is applied. This is why it is necessary to create "external" versions of the SMTP and WWW server objects and use those in the rulebase.

Configure NAT Rules
The NAT rules would look like this in the GUI:

Original Translated
No. Source Destination Service Source Destination Service
1 SMTP-Server Any Any SMTP-Server-External(S) Orig Orig
2 Any SMTP-Server-External Any Orig SMTP-Server(S) Orig
3 Any WWW-Server-External Any Orig WWW-Server(S) Orig
4 InternalNetRange Any Any Firewall(H) Orig Orig


The rules perform the following functions:


If the SMTP Server initates a connection out to the Internet, it will appear as though it is coming from SMTP-Server-External (e.g. 204.32.38.2) via a static translation. Replies to this traffic will automatically be translated.
If anyone initates a connection to the SMTP server's "legal" IP address (e.g. 204.32.38.2), it will be translated to the server's "real" IP address (e.g. 192.168.0.2) via a source static translation. Replies to this traffic will automatically be translated.
If anyone initiations a connection to the WWW server's "legal" IP address (e.g. 204.32.38.10), it will be translated to the server's "real" IP address (e.g. 192.168.0.10) via a destination static translation. Replies to this traffic will automatically be translated.
Users in the InternalNetRange (e.g. all IPs in 192.168.0.0 except for 192.168.0.1) will be hidden behind the firewall's external interface via a hide translation (e.g. outbound traffic will appear to be coming from 204.32.38.1).
Notes:

Never translate any interface on your firewall. This is why a range object was created to define the Internal net in a way that excluded the firewall's internal interface.
The rules are processed in-order. This means that the SMTP server, while it is covered by both rules 1 and 4, will be translated to 204.32.38.2 via a source static translation and not 204.32.38.1 via the hide translation. This also means that if someone surfs the web from the web server itself, it will appear to be coming from the firewall.

Configure the Firewall's OS for NAT
You will need to make changes to the OS to support NAT. This is where the instructions are somewhat implementation dependent. To cover these issues in more detail, see Routing and ARP issues with NAT.

Generally speaking, you need to:


Set up proxy arps for the "legal" IP addresses used (for both source and destination static translations). This will ensure that, at least on the data link level, the traffic will get to the firewall.
Set up routes on the firewall itself for the destination static translations. This will ensure that the traffic eventually gets delivered out the right interface on the firewall. If you're running NG and you've enabled client-side NAT as per How NAT works in FireWall-1 NG?, you can omit this step.
In this case, we need to set up:


A proxy arp for 204.32.38.2 and 204.32.38.10
A static route for 204.32.38.2 and 204.32.38.10
To set up a proxy arp, the MAC or Ethernet address of the external interface of the firewall needs to be known. On Unix, use ifconfig to get this information. On NT, use the command IPCONFIG /ALL.

Once the MAC address is known (in this case, it is 00:c0:78:20:00:6d), type the following commands on a Unix machine. Add these to a separate startup file so that they will be active after a reboot:

arp -s 204.32.38.2 00:c0:78:20:00:6d pub
arp -s 204.32.38.10 00:c0:78:20:00:6d pub

On an NT machine, the arp command does not allow for proxy arping. You will need to use FireWall-1's proxy arping capability. To use this capability, create a file called %FWDIR%\state\local.arp. The contents of this file will have the following format.

translated_ip_address mac_address

In our specific case, the local.arp file would look like this:

204.32.38.2 00-C0-78-20-00-6D
204.32.38.10 00-C0-78-20-00-6D

Note: For changes to this file to take effect, you must install your security policy.

As for routing changes, it will be necessary to set up static routes to direct packets from the "legal" IP addresses and route them to their "real" equivelants. In this example, static routing is being used, so routing commands must be issued via the OS. If your specific situation requires the use of RIP, OSPF, or some other routing protocol, you may need to add these routes into the routing software configuration files instead of entered into the OS. The specifics of that are beyond the scope of this example.

On a Solaris machine (other Unixes will have slightly different syntax), the routes would be added as follows. As with the arps above, you will need to add them to a startup file so the routes will not be lost on reboot.

route add 204.32.38.2 192.168.0.2 1
route add 204.32.38.10 192.168.0.10 1

On an NT machine, the routes are slightly different:

route add 204.32.38.2 192.168.0.2 -p
route add 204.32.38.10 192.168.0.10 -p

The -p option insures the routes will be added to the registry and will be active, even after rebooting.


Installing the Security Policy
Anytime changes are made to the security policy or NAT rules, the security policy must be installed for the changes to take effect. Install the security policy and test to see that each rule is being enforced correctly by watching the logs while performing actions that you believe are permitted and not permitted.


Anti Spoof Configuration
If anti-spoofing is configured (e.g. the entries for "Valid Addresses" on each interface are set to something other than "Any") and you are running FireWall-1 4.1 or earlier, you will need to modify the anti-spoofing configuration to account for address translation. In NG and later, provided you've changed the properties as above, you will not need to modify anti-spoofing. Otherwise, you will either see:


Traffic accepted by the firewall to the "translated" IP address, but the traffic never makes it to it's intended destination.
rops or rejects on rule 0 in the logs.
General Note: It is always a good idea to have your spoof track set to log on all your interfaces, even if you currently do not use the anti-spoofing configuration. This aids in debugging, particularly if you do configure it.

Before NAT was set up, the anti-spoofing was set up like this:

Interface IP Address Valid Address Setting
le0 204.32.38.1 Others
le1 192.168.0.1 This Net


Unfortunately, this is not sufficient when you are using NAT to devices on your internal network. It is necessary to also include those "legal" IP addresses that are staticly translated to your internal network. In this case, it means adding 204.32.38.2 and 204.32.38.10 to the "valid addresses" setting for the internal interface. To do this, create a group. In this case, it will be called "le1-valid". Put the following objects into this group:


InternalNet
WWW-Server-External
SMTP-Server-External
Then set the "valid addresses" for le1 (the internal interface, in this case) to le1-valid.

Interface IP Address Valid Address Setting
le0 204.32.38.1 Others
le1 192.168.0.1 Specific: le1-valid


Re-install your security policy.

-- RayLodato - 13 Jan 2004


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