This chapter is from the book
This chapter is from the book
This chapter is from the book
Sample Configurations
The following three situations presented are representative of situations I have come across 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.
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 only given you 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 9-9.)
){kind=link}
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.
Figure 9-9 Sample configuration network #1
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.
Implementation
You must first determine which IPs you will use. Your usable IPs are 192.168.0.2– 192.168.0.5. Let's make 192.168.0.2 the IP you use 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:
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
Both 192.168.0.3 and 192.168.0.4 each need a static host route. The 192.168.0.2 address does not need one, as users should never be directly connecting to 192.168.0.2. Because the real host is on the same subnet as the firewall, 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.5
Because you are using the -p option, these routes will be available after a reboot; they will be stored in the Registry.
Table 9-8 lists the network objects you will create.
Table 9-8 Network objects for sample configuration #1
|
Name |
Object Type |
IP/Net Mask/Group Objects |
Description |
|
Net-internal |
Network |
10.0.0.0/255.255.255.0 |
The network that represents the Internal Network |
|
mail-web-server |
Workstation |
10.0.0.5 |
Mail/Web Server on theInternal Network |
|
mail-ext |
Workstation |
192.168.0.3 |
Translated IP for Mail Server |
|
web-ext |
Workstation |
192.168.0.4 |
Translated IP for Web Server |
|
external-hide |
Workstation |
192.168.0.2 |
IP that users will hide behind when going out |
|
valid-internal |
Group |
net-internal + mail-ext + web-ext |
Represents your internalinterface's valid addresses for anti-spoofing |
|
firewall |
Workstation |
192.168.0.1 |
Your firewall |
When configuring your firewall object, set your valid address settings according to the settings shown in Table 9-9.
Table 9-9 Valid address settings for firewall
|
Interface |
Valid Address Setting |
|
Internal |
Specific: valid-internal |
|
External |
Others |
The valid address settings are set 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.
The rulebase should look similar to the rules shown in Figure 9-10.
){kind=link}
The NAT rules should look like the rules shown in Figure 9-11.
){kind=link}
Save and install the policy.
Figure 9-10 Security policy for sample configuration #1
Figure 9-11 NAT policy for sample configuration #1
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 adaptor, 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.
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 9-12.)
){kind=link}
Figure 9-12 Sample configuration network #2
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, historical IPs as well as their new IPs.
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.
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.
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 net mask (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 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 external and internal interfaces' MAC address. An ifconfig -a 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. The ARPs you would do are as follows:
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 (note that you still need static routes for the "old" addresses, even if you don't need ARPs for them):
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
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 9-10 shows the network objects that will be created.
When configuring your firewall object, set your valid address settings according to the settings shown in Table 9-11.
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.
The rulebase should look similar to the rules shown in Figure 9-13.
){kind=link}
The NAT rules should look like the rules shown in Figure 9-14.
){kind=link}
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.
Table 9-10 Network objects for sample configuration
|
Name |
Object Type |
IP/Net Mask/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 |
Workstation |
172.17.0.25 |
The Mail Server |
|
mail-server-ext |
Workstation |
192.168.1.67 |
Translated IP for the Mail Server |
|
mail-server- ext-old |
Workstation |
192.168.0.3 |
Translated IP for theMail Server (historical) |
|
web-server |
Workstation |
172.17.0.80 |
The Web Server |
|
web-server-ext |
Workstation |
192.168.1.68 |
Translated IP for the Web Server |
|
web-server- ext-old |
Workstation |
192.168.0.4 |
Translated IP for the Web Server (historical) |
|
intranet-web- server |
Workstation |
172.17.0.81 |
The Intranet Web Server |
|
intranet-web-server-int |
Workstation |
10.0.0.5 |
Translated IP for the Intranet Web Server |
|
external-hide |
Workstation |
192.168.1.66 |
IP that users will hide behind when going out |
|
valid-dmz |
Group |
net-dmz + intranet-web-server-int + mail-server-ext + web-server-ext + net-external-old |
Represents your DMZ interface's valid addresses for anti-spoofing |
|
valid-internal |
Group |
net-internal |
Represents your internal interface's valid addresses for anti-spoofing |
|
firewall |
Workstation |
192.168.1.65 |
Your firewall |
Table 9-11 Valid address settings for firewall
|
Interface |
Valid Address Setting |
|
DMZ |
Specific: valid-dmz |
|
Internal |
Specific: valid-internal |
|
External |
Others |
Figure 9-13 Security policy for sample configuration #2
Figure 9-14 NAT policy for sample configuration #2
Double-Blind Network Configuration
The Situation
There is a device within your network that has a faulty IP implementation and can only talk to hosts on the same subnet as it is on (i.e., it has no concept of routing).8 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.
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 9-15 only shows the relevant parts of the network.
){kind=link}
Figure 9-15 Sample configuration network #3
The Goals
Allow FTP and Telnet access to 10.20.30.6 (the translated IP address for this device).
Allow HTTP 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.
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.
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 Voyager. Figure 9-16 shows the interface ARP entries, which are on the ARP configuration page.
){kind=link}
Figure 9-16 Interface ARP entries in Voyager
You can see the two interfaces and their MAC addresses. For 10.20.30.6, you will use 0:a0:8e:6:26:68. Right above the Interface ARP entries on the Voyager page is where you create this ARP entry (see Figure 9-17).
){kind=link}
Figure 9-17 Create ARP entries in Voyager.
Click the Apply button at the bottom of the page. You then need to set the MAC address for this entry (see Figure 9-18).
){kind=link}
Figure 9-18 Add MAC to ARP entries in Voyager.
Click Apply again. Go to the bottom of the static route page in Voyager, and add a static route to route 10.20.30.6 to 192.168.255.2 (see Figure 9-19).
){kind=link}
Figure 9-19 Add static route in Voyager.
Click Apply, and then click Save. This configuration is now active across reboots.
The network objects you will create are shown in Table 9-12.
Table 9-12 Network objects for sample configuration
|
Name |
Object Type |
IP/Net Mask/Group Objects |
Description |
|
net-protected-device |
Network |
192.168.255.0/255.255.255.0 |
The network that the protected device is on |
|
net-internal |
Network |
10.0.0.0/255.0.0.0 |
The internal network |
|
protected-device |
Workstation |
192.168.255.2 |
The protected device's internal IP |
|
protected-device-xlate |
Workstation |
10.20.30.6 |
Translated IP for the protected device |
|
management-device |
Workstation |
10.250.0.5 |
Host allowed to connect to IP330 via HTTP |
|
firewall-eth-s4p1 |
Workstation |
192.168.255.1 |
A workstation object (defined without FireWall-1 installed) that represents the system's interface facing the protected device. You will need this later. |
|
valid-eth-s4p1 |
Group |
net-protected-device + protected-device-xlate |
Represents the valid address setting for eth-s4p1, the interface that the protected device is hooked to |
|
Firewall |
Workstation |
10.20.30.5 |
Your firewall |
When configuring your firewall object, set your valid address settings according to the settings shown in Table 9-13.
Table 9-13 Valid address setting for firewall
|
Interface |
Valid Address Setting |
|
eth-s4p1c0 |
Specific: valid-eth-s4p1 |
|
eth-s3p1c0 |
Others |
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.
The rulebase should look similar to the rules shown in Figure 9-20.
){kind=link}
Figure 9-20 Security policy for sample configuration #3
The NAT rules should look like the rule shown in Figure 9-21.
){kind=link}
Save and install the policy.
Figure 9-21 NAT policy for sample configuration #3
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 only shows the connections occurring in one direction.