Figure 5-2. Network Address Translation
One common feature of many firewalls is Network Address Translation (NAT). Many routers now offer NAT as an optional service. NAT can function in several different ways, but they all involve rewriting the source address in IP packets. NAT is also sometimes called address masquerading.
Figure 5-2 shows a typical NAT implementation. The protected internal network is on the inside of the firewall, to the left. The external network is to the right. Perhaps the most important feature here is that the IP addressing of the internal network is completely unregistered.
I will discuss IP addressing schemes shortly, but one common scheme involves using an open range of addresses that cannot be owned by any organization. These addresses are, in effect, public domain. Because of this, they can never be presented to a public network. Since any organization is allowed to use the IP address range 10.x.x.x, for example, then it is impossible for the public network to know which of the millions of sites using this range is the right one.
Figure 5-2 has the interior of the network using 10.x.x.x for its address range. This means that the firewall must rewrite every packet that passes through it so that the 10.x.x.x addresses on the inside are changed to legitimate addresses on the outside. A workstation on the inside of the firewall uses the IP address 10.1.1.5. The outside of the firewall has the legitimate registered address 204.148.40.5. For the example, assume that this organization has registered the entire range 204.148.40.x.
Every packet passing through the firewall from 10.1.1.5 must have its source address rewritten to something in the range 204.148.40.x. There are three common ways to do this. You can make every internal device appear with the same address as the outside of the firewall, 204.148.40.5. The second option is to create a range of legitimate addresses, such as 204.148.40.51, 52, 53, and 54. These addresses are then uniquely and permanently assigned to specific internal devices, so 10.1.1.5 will always appear on the outside of the firewall, 204.148.40.51, 10.1.1.6 will always appear as 204.148.40.52, and so forth.
The last commonly available option is to assign a pool of address such as 204.148.40.51-54, as in the previous example. This time, the addresses will be dynamically associated with internal devices. When one device wants to make a connection to the Internet, it gets whatever address is the next one available in the list. The next internal device gets the second address from the list, and so forth. This technique makes better use of the address resources than the previous example because an idle device returns its external address to the pool.
The most common method, however, is the first one, in which every internal device has the same IP address on the outside of the firewall. This situation makes the entire network look to the outside world as if it is a single, very busy device. Internally, the firewall must do a very difficult task, however. It must keep track of which of the many sessions are associated with which internal devices.
This method is considerably easier to use with TCP than with UDP-type services because the firewall can keep track of the different TCP sessions. With UDP, the firewall has to try to associate incoming packets with previous outgoing UDP packets. If a particular internal device sends out a UDP packet on a particular port number, then the firewall simply waits a short time for a response from that same external IP address and directs it to the originating internal device.
The problem becomes even harder for ICMP packets such as ping, though. The firewall has only the IP address of the external device to connect to the originating internal device. If several people all try to ping the same external device at the same time, it can be very difficult for the firewall to figure out which response packets to direct to which internal devices. To the outside world, all packets look like they came from the firewall itself; they all have the same source IP address.
Not only must the firewall rewrite the source address of every outgoing packet, but it must also rewrite the destination address of all incoming packets. If it doesn't know how to rewrite the address, then most firewalls take the safe approach—they assume that the incoming packet is unsolicited and drop it.
NAT can cause serious confusion in some places. Specifically, some applications include the IP address information somewhere inside the packet's data segment. One common example of this is SNMP. If one attempts to manage a network through a firewall, NAT can become extremely confusing.
The worst case comes when a network management service vendor tries to manage the networks of several different clients who all use the same IP address ranges. The vendor may try to use NAT to rewrite the addresses of the monitored client machines, but data contained inside the SNMP packets indicate the real source address, and the conflicting address ranges have to be removed by other means.
A worse example is seen in the applications of certain information service providers. Some of these applications work by means of TCP connections from the client workstation to the vendor's server. The TCP connection starts with a packet from the client workstation that passes through the firewall. As I discussed earlier, the packet's header contains four key pieces of information: the source and destination IP addresses and the source and destination TCP port numbers. The firewall rewrites the source address and often also rewrites the source TCP port. The server then responds with a packet addressed back to the modified source address (which is delivered to the firewall) and the modified source port. This information is rewritten by the firewall to the original values and directed back to the client workstation.
If the source IP address and port number are also contained within the data part of the packet, perhaps for some sort of authentication system, then the server has considerable room to be confused. It cannot communicate directly with the real source IP address indicated. The real source TCP port number is also of no use to it.
Unfortunately, there is no universal solution to this problem. Some firewalls are able to work around parts of the problem—for example, by maintaining the source TCP port number. But in the worst examples, the only way around the problem is to simply eliminate the firewall, eliminate NAT, and use a standard router with extensive packet filtering to implement the required security precautions.