Network Address Translation (NAT)
By Chad McIntyre
What is NAT?
Network Address Translation (NAT) is a scheme for reducing the number of IP addresses required by a network. It enables networks using the defined private IP addresses to connect to the Internet. NAT may operate on a physical router, or software that performs routing.
A network that is setup to use private addresses may employ NAT to translates the private addresses into legal addresses before the packets are forwarded onto another network. NAT may also be configured to use only one external IP address. This permits the entire private network to appear as one IP address to all external networks. From a security standpoint, this is advantageous as it narrows the externally visible and hence vulnerable portions of the network to a single IP address.
From a home-users point of view, NAT offers the ability for several home computers to use a single Internet connection at the same time, eliminating the need to install a second connection or switching the connection between machines. Furthermore, the home-user can also stand to benefit from the increased security NAT provides via single-point-of-access.
The remainder of this paper will focus on a popular implementation of NAT known as IP-Masquerading (IP MASQing) on the Linux operating system. It should be noted that as of kernel version 2.4, IP MASQing is referred to as NAT.
Linux IP Masquerading offers the simple yet powerful ability to translate network addresses and hence realize the benefits discussed above. Using IP masquerading and the ability of Linux to behave as a firewall, various types of unauthorized access may be stopped before reaching the internal network. This is one of the features that make Linux an attractive solution to small company and home networks.
IP Masquerading has been offered as part of the Linux operating system kernel since the version 2.0 kernel. The reader is encouraged to consult the references provided at the end of this paper for more information on this topic.
How does IP Masquerading work?
To understand how masquerading works, consider the process of setting up a TCP/IP connection. The initiating machine builds a packet that includes the destination IP address, the port on the destination machine, the source IP address, the port to which the recipient can reply, and the actual data to be sent.
On a non-masqueraded connection, the host would send the packet across the Internet and await the response. However, in a masqueraded environment the process is different.
When the sending machine on the internal network sends a packet to initiate a TCP/IP connection, it is intercepted by the IP masquerading system that acts as a gateway. When the gateway machine receives the packet, it performs several steps depending on whether the packet is a connection initiation or traffic for an existing connection.
For a connection initiation, the gateway does the following:
1. Records the source address, and source port of the packet to be sent.
2. Builds a new connection packet using the gateways externally visible IP address in the source address field of the packet, and the data from the received packet.
3. Associates the new connection created in (2) with the information stored in (1).
4. Send the new packet across the Internet.
For connection traffic, the machine executes the following steps:
1. Determine to which entry created during initialization this packet belongs.
2. Copy the gateways IP address into the source address section of the packet, and copy the source port that was generated when the new connection packet was made during initialization into the source port of the outgoing packet.
3. Send the outgoing packet.
Port numbers are generated randomly on the gateway so that multiple outgoing connections can be tracked.
Once the connection packet has been created and sent, the gateway machine listens for a response on the source port specified in the sent packet. When the gateway machine receives a packet on one of the ports it is listening to, it checks among the source address and source ports it recorded in step 1 of the connection initiation to determine to which machine (and port), on the local network should receive this packet. The kernel builds a new packet destined for the machine on the internal network, and the source address field set to the remote machines IP address. The data portion is directly copied over and the packet is sent.
Thus, to the internal machine, it appears as though machines on the Internet are directly reachable despite the fact that it may be assigned one of the private network IP addresses outlined in RFC-1918.
What about incoming connections?
Consider a remote machine that wishes to connect to a machine on the internal network. Herein lies part of the security that masquerading provides, and also part of the problems with using it.
For arguments sake, let us say that the remote machine knows that an internal machine is awaiting a connection but at the address of the IP masquerading gateway. The remote machine then builds a connection packet with the appropriate source address and port; the destination address set as the gateway machine, and the destination port on which it believes the recipient is listening. It then sends this packet. The packet arrives at the Linux gateway. The gateway examines the packet and determines if that port is listening. Chances are good that it is not. This situation arises because the remote machine that performed transparent communications with the internal machine before is now trying to connect to the destination port on the gateway machine, not the internal machine. Thus, currently it is not possible for the remote machine to contact the internal machines.
This can be both good and bad. On the positive side, one can protect hosts on an internal network from contact initiated from external networks. That is, machines outside the internal network can be denied access to potential weak-points of the internal network. This is very helpful. However, what happens if external access to a machine on the internal network is desired? Solutions to this problem exist and are also quite attractive.
As an example, consider using one of the internal machines as an http server. In order to permit external machines access to the internal machine, the gateway machine must be instructed to port-forward connections on the incoming connection port (typically 80 for http). Thus, when the gateway receives a connection initialization from an external network, it checks the destination port. If that port is 80, it then creates a new packet bound for the machine on which the server is running, and sends it. The internal machine may then respond to the remote machine via the process above.
This setup is advantageous because it observes one of the cardinal rules of network security: only permit the services you absolutely need. That is, the internal network is still shielded from all other incoming connections.
This also permits some rudimentary load balancing to occur. Consider setting up an http server, and an ftp server. For arguments sake both are under heavy load at all times. Port forwarding permits you to direct all http requests to one machine, and all ftp requests to another. Thus, each machine can handle its single task, and if one server crashes, the other one can still operate.
An example setup
NAT and IP masquerading provide internal network protection and network connection sharing. These services have been demonstrated to enhance security by forcing a single point of access to the internal network. Please see the following resources for further information: