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-user’s 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.
IP Masquerade
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
gateway’s 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 gateway’s 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 machine’s 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
Conclusion
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:
References
http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html
http://www.linuxfocus.org/English/January2000/article134.shtml