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

Figure 10.8. Simple network with NAT

graphics/10fig08.gif

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.

Table 10.8. Network objects for sample configuration 1

Name

Object Type

IP/Netmask/Group Objects

Description

net-internal

Network

10.0.0.0/255.255.255.0

The network that represents the internal network

web-server

Node, host

10.0.0.6

The mail/Web server on the internal network

mail-server

Node, host

10.0.0.5

The mail/Web server on the internal network

mail-ext

Node, host

192.168.0.3

The translated IP for the mail server

web-ext

Node, host

192.168.0.4

The translated IP for the Web server

external-hide

Node, host

192.168.0.2

The IP that users will hide behind when going out

valid-internal

Group

net-internal

Your internal interface's valid addresses for anti-spoofing

firewall

Check Point gateway

192.168.0.1

Your firewall

Table 10.9. Valid address settings for the firewall in sample configuration 1

Interface

Valid Address Setting

3C5x91

Specific: valid-internal

3C5x92

External

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.

Figure 10.9. Security policy for sample configuration 1

graphics/10fig09.gif

Figure 10.10. Address translation policy for sample configuration 1

graphics/10fig10.gif

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

Figure 10.11. Migrating to a larger network with NAT

graphics/10fig11.gif

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.

Table 10.10. Network objects for sample configuration 2

Name

Object Type

IP/Netmask/Group Objects

Description

net-internal

Network

10.0.0.0/255.255.255.0

The network that represents the internal network

net-dmz

Network

172.17.0.0/255.255.255.0

The network that represents the DMZ

net-external-old

Network

192.168.0.0/255.255.255.248

The old external network now on the DMZ

mail-server

Node, host

172.17.0.25

The mail server

mail-server-ext

Node, host

192.168.1.67

The translated IP for the mail server

mail-server-ext-old

Node, host

192.168.0.3

The translated IP for the mail server (historical)

web-server

Node, host

172.17.0.80

The Web server

web-server-ext

Node, host

192.168.1.68

The translated IP for the Web server

web-server-ext-old

Node, host

192.168.0.4

The translated IP for the Web server (historical)

intranet-web-server

Node, host

172.17.0.81

The intranet Web server

intranet-web-server-int

Node, host

10.0.0.5

The translated IP for the intranet Web server

external-hide

Node, host

192.168.1.66

The IP that users will hide behind when going out

valid-dmz

Group

net-dmz + net-external-old

Your DMZ interface's valid addresses for anti-spoofing

valid-internal

Group

net-internal

Your internal interface's valid addresses for anti-spoofing

firewall

Check Point gateway

192.168.1.65

Your firewall

Table 10.11. Valid address settings for the firewall in sample configuration 2

Interface

Valid Address Setting

qe3

Specific: valid-dmz

qe0

Specific: valid-internal

le0

External

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.

Figure 10.12. Security policy for sample configuration 2

graphics/10fig12.gif

Figure 10.13. Address translation policy for sample configuration 2

graphics/10fig13.gif

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.

Figure 10.14. Network diagram for double-blind NAT

graphics/10fig14.gif

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.

Figure 10.15. Proxy ARP Entries section in Network Voyager

graphics/10fig15.gif

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

Figure 10.16. Quick-add static routes in Network Voyager

graphics/10fig16.gif

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.

Table 10.12. Network objects for sample configuration 3

Name

Object Type

IP/Netmask/Group Objects

Description

net-protected-device

Network

192.168.255.0/255.255.255.0

The network on which the protected device resides

net-internal

Network

10.0.0.0/255.0.0.0

The internal network

protected-device

Node, host

192.168.255.2

The protected device's internal IP

protected-device-xlate

Node, host

10.20.30.6

The translated IP for the protected device

management-device

Node, host

10.250.0.5

The host allowed to connect to IP330 via HTTP

firewall-eth-s4p1

Node, host

192.168.255.1

A host object that represents the system's interface facing the protected device.

valid-eth-s4p1

Group

net-protected-device

The valid address setting for eth-s4p1, the interface to which the protected device is hooked

firewall

Check Point gateway

10.20.30.5

Your firewall

Table 10.13. Valid address settings for the firewall in sample configuration 3

Interface

Valid Address Setting

eth-s4p1c0

Specific: valid-eth-s4p1

eth-s3p1c0

External

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.

Figure 10.17. Security policy for sample configuration 3

graphics/10fig17.gif

Figure 10.18. Address translation policy for sample configuration 3

graphics/10fig18.gif

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.