Sample Configurations

The following three situations are representative of those I have encountered in the real world. Each is designed to demonstrate what people typically do with NAT and how the situations would be implemented on the chosen platform.

Creating a Simple Network with NAT

The Situation

You work for a small company with a few hosts on a flat network segment. Your firewall runs on a Windows NT platform. The ISP has given you only a /29 net block, which effectively gives you six hosts you can use on the outside segment. Because the firewall and Internet router each need a unique IP address, this leaves a total of four addresses that can be used for other hosts (see Figure 10.8).

The Goals

• Allow Internet users access to the mail and Web servers via SMTP and HTTP, respectively. In the future, these services will be provided on separate systems, so setting up each service with a unique IP is desirable to make future migration easier.

• Allow internal users to access anything on the Internet. All outbound users will be hidden behind a single IP address; however, this IP address should be different from the firewall.

The Checklist

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

The Implementation

You must first determine which IPs you will use. Your usable IPs are 192.168.0.2?192.168.0.5. Let's use 192.168.0.2 as the IP for your external clients to hide behind, 192.168.0.3 for the SMTP server, and 192.168.0.4 for the HTTP server.

Next, set up the static ARPs for the translated addresses. In order to do this, you need to determine the MAC address of your external interface. Use the command ipconfig /all to determine this address:

Ethernet adapter 3C5x91 :

     Description . . . . . . . . : 3Com 3C5x9 Ethernet Adapter
     Physical Address. . . . . . : 00-22-44-66-88-AA
     DHCP Enabled. . . . . . . . : No
     IP Address. . . . . . . . . : 192.168.0.1
     Subnet Mask . . . . . . . . : 255.255.255.248
     Default Gateway . . . . . . : 192.168.0.6

Ethernet adapter 3C5x92:

     Description . . . . . . . . : 3Com 3C5x9 Ethernet Adapter
     Physical Address. . . . . . : 00-00-87-20-66-69
     DHCP Enabled. . . . . . . . : No
     IP Address. . . . . . . . . : 10.0.0.1
     Subnet Mask . . . . . . . . : 255.255.255.0
     Default Gateway . . . . . . :

The external MAC is 00-22-44-66-88-AA, which you will enter along with the IP addresses in the %FWDIR%\state\local.arp file:

192.168.0.2 00-22-44-66-88-AA
192.168.0.3 00-22-44-66-88-AA
192.168.0.4 00-22-44-66-88-AA

The 192.168.0.3 and 192.168.0.4 addresses each need a static host route. The 192.168.0.2 address does not need one because users should never be directly connecting to 192.168.0.2. The Web/mail host has two unique IP addresses associated with it. This is necessary because NAT requires a direct one-to-one mapping of IPs. This host is on the same subnet as the firewall, so the static route should be directed at the host itself:

> route -p add 192.168.0.3 10.0.0.5
> route -p add 192.168.0.4 10.0.0.6

Because you are using the -p option, these routes will be available after a reboot; they will be stored in the Registry.

Table 10.8 lists the network objects you will create.

When configuring your firewall object, set your valid address settings according to those shown in Table 10.9. Use the Topology frame of your gateway object. Also, make sure that each interface has the Spoof Tracking set to Log to catch any errors in the anti-spoofing configuration.

The rulebase should look similar to the one shown in Figure 10.9. The NAT rules should look like those shown in Figure 10.10.

Save and install the policy.

Notes

It is not a wise idea to have your internal hosts on the same LAN segment as hosts that are accessible from an untrusted network like the Internet. However, this is a situation that, for various reasons, all too many security administrators find themselves in. From a security standpoint, you are much better off trying to move externally accessible servers to a DMZ. It will cost a couple hundred dollars to purchase an extra LAN adapter, an extra switch or hub, and a few extra cables, but the extra security gained will be well worth it.

You will not be able to access the mail/Web server from the internal segment via its translated addresses without some additional configuration, which is left as an exercise. (Hint: look at the "white" rules in Figure 10.6.)

Migrating to a Larger Net with NAT

The Situation

The company you work for has grown. Your ISP has given you an external segment with a few more addresses (192.168.1.64/28), and you have a separate LAN segment for your DMZ, which now also has a few more hosts in it. Your firewall platform has also changed from Windows NT to Solaris.

A certain amount of backward compatibility needs to be maintained with the old setup; that is, certain hosts need to be reachable by their old addresses. For the external addresses, the ISP is continuing to route the 192.168.0.0/29 segment to you until such time as the address space is no longer needed (see Figure 10.11).

The Goals

• Allow Internet users access to the mail and Web servers via SMTP and HTTP, respectively. Note that the servers will have to be accessible by their old IPs as well as their new ones.

• Allow internal users to access anything on the Internet. All outbound users will be hidden behind a single IP address; however, this IP address should be different from the firewall.

• Allow internal users to access the intranet Web server by its old IP address (10.0.0.5). This server will not be accessible from the Internet.

The Checklist

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

The Implementation

To simplify your NAT configuration a bit, assign the 192.168.0.0/29 network to the DMZ. Make sure the external router is configured to route all requests for this network to the firewall. You also need to give the firewall an IP address of 192.168.0.1 on the DMZ interface. In Solaris, you add an /etc/hostname.qe3:1 file with this IP address. You also have to modify /etc/netmasks so that 192.168.0.0 has the correct netmask (255.255.255.248). So that you don't have to reboot for this to take effect, execute the following set of commands:

# ifconfig qe3:1 plumb
# ifconfig qe3:1 inet 192.168.0.1 netmask 255.255.255.248
          broadcast 192.168.0.7 up

The SMTP and HTTP servers need to have secondary IP addresses of 192.168.0.3 and 192.168.0.4, respectively. Similar steps need to be taken on these servers.

You must then determine which IPs you will use for translation. Your new usable address range is 192.168.1.66?192.168.1.77. Let's make 192.168.1.66 the IP you use for your external clients to hide behind, 192.168.1.67 the new IP for your SMTP server, and 192.168.1.68 the new IP for your HTTP server. You are also translating 10.0.0.5 to 172.17.0.81.

Next, set up the static ARPs for the translated addresses. Because you are translating both internal and external addresses to the DMZ, you need both the internal and external interfaces' MAC addresses. An ifconfig -a command shows you the following:

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.1.65 netmask fffffff0 broadcast 192.168.1.79
     ether 0:12:34:56:78:9a
qe0: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING, MULTICAST> mtu 1500
     inet 10.0.0.1 netmask ffffff00 broadcast 10.0.0.255
     ether 8:0:20:6d:0:20
qe3: flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
     inet 172.17.0.1 netmask ffffff00 broadcast 172.17.0.255
     ether 8:0:20:20:0:6d
qe3:1 flags=863 <UP,BROADCAST,NOTRAILERS,RUNNING, MULTICAST> mtu 1500
     inet 192.168.0.1 netmask fffffff8 broadcast 192.168.0.7

The external MAC is 00:12:34:56:78:9a, and the internal MAC address is 8:0:20:20:0:6d. You would do the following ARPs:

# arp -s 192.168.1.66 0:12:34:56:78:9a pub
# arp -s 192.168.1.67 0:12:34:56:78:9a pub
# arp -s 192.168.1.68 0:12:34:56:78:9a pub
# arp -s 10.0.0.5     8:0:20:20:0:6d   pub

Static routes are as follows:

# route add 192.168.1.67 172.17.0.25 1
# route add 192.168.1.68 172.17.0.80 1
# route add 10.0.0.5     172.17.0.81 1

(Note that you still need static routes for the "old" addresses, even if you don't need ARPs for them.) Because this is a UNIX platform, these ARPs and routes will disappear after a reboot. You need to add these routes and ARPs to a startup file. It is recommended that you create a new script for this purpose (such as /etc/rc3.d/S94addroutes) and add the preceding commands to this file.

Table 10.10 shows the network objects that will be created.

When configuring your firewall object, use the Topology frame to set your valid address settings according to those shown in Table 10.11. Also, make sure that each interface has the Spoof Tracking set to Log to catch any errors in the anti-spoofing configuration.

The rulebase should look similar to the ones shown in Figure 10.12. The NAT rules should look like those shown in Figure 10.13.

Save and install the policy.

Notes

Sites on the DMZ should be accessible by their translated IP addresses, even from the internal network. This is because the communication is now mediated by the firewall. In the previous example, this was not the case.

Using a Double-Blind Network Configuration

The Situation

There is a device within your network that has a faulty IP implementation and can talk to only those hosts on the same subnet it is on (i.e., it has no concept of routing).^[7] Because it is also not desirable to allow everyone to access this host, a firewall is necessary to restrict access to this host. The host is using nonroutable addresses and cannot be seen by the rest of the network. It must be given a routable address so that it can be accessed. Because neither side of the connection can know the true IP address of its peer, this is referred to as a double-blind network configuration.

^[7] I've actually run into this configuration with a PBX at a college campus. As Dave Barry would say if he were writing this book, I'm not making this up.

A Nokia IP330 will be used to protect this device, which will be directly connected to the device via a crossover cable. The rest of the network (the entire 10.0.0.0/8) is used internally. Figure 10.14 shows only the relevant parts of the network.

The Goals

• Allow FTP and Telnet access to 10.20.30.6 (the translated IP address for this device).

• Allow HTTPS access to the IP330 for management purposes from a specific management console (10.250.0.5, not pictured here).

• Allow SSH access to the IP330 for management purposes from anywhere.

The Checklist

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

• Create the necessary rulebase rules to permit the desired traffic.

• Create the NAT rules.

• Install the security policy.

The Implementation

From the preceding goals, you know that you will be translating 10.20.30.6 to 192.168.255.2. You also know that all access to this protected device must appear to be coming from a device on the same subnet. The firewall is appropriate in this case.

You need to create an ARP for 10.20.30.6 using the MAC address of the external interface of the IP330. You can easily do this in Network Voyager. Figure 10.15 shows the Proxy ARP Entries section, where you can add a proxy ARP using a specific interface's MAC address, which is what we want. For 10.20.30.6, we will use eth-s3p1c0 as the interface. Click the Apply button at the bottom of the page.

Go to the bottom of the static route page in Voyager. Use the quick-add static routes to add a static route to route 10.20.30.6 to 192.168.255.2 (see Figure 10.16).

Click Apply, and then click Save. This configuration is now active across reboots.

The network objects you will create are shown in Table 10.12. When configuring your firewall object, set your valid address settings according to those shown in Table 10.13. These settings are configured in the Topology frame. Also, make sure that each interface has the Spoof Tracking set to Log to catch any errors in the anti-spoofing configuration.

The rulebase should look similar to the rules shown in Figure 10.17. The NAT rules should look like the one shown in Figure 10.18.

Save and install the policy.

Notes

You could do this in the reverse direction as well (i.e., have the protected device access hosts on the other side of the firewall as if they were on the same subnet), but this sample configuration shows the connections occurring in only one direction.