Digital Elephant
Network Address Translation
This is also called masquerading, largely because of the way traffic appears to the outside world: traffic from any machine whose address is being translated will seem to be coming from the boundary machine. That system keeps track of how it has altered each packet that it translates, so that when replies come back, the boundary machine will be able to retranslate the packet header so that the proper recipient will receive it, and so that it appears to have come unmolested from the Internet source.
Understanding exactly how this is all done takes quite a bit of study; understanding how to cause it to happen is very simple. The same tool that is used for firewall filtering, either iptables or ipchains, can be used to set up masquerading, by specifying the range of addresses that should be translated, and perhaps the interface on which they ought to appear. Details of the command syntax are in the sections on firewall setup, since there is more than one program that you might encounter.
| Configuring a Firewall (iptables) |
| Configuring a Firewall (ipchains) |
| Configuring a Firewall (ipfwadm) |
Once this all works, you may find that you want to advertise only some of the machines in your network via the Domain Name System (DNS), while making a larger set of names available to machines on the Private Network. This notion is described further here.
How Address Translation Works
Network Address Translation depends on there being a single boundary machine that connects the private network to the public Internet; that machine can then intercept all traffic that flows between the two. When it sees a packet from a machine on the private net side, it alters that packet's header in two ways: it changes the IP address to the address of the boundary machine, and it removes the source-port from the packet, substituting a high-numbered port. These details are saved in a lookup table, and the boundary machine sends the altered packet out into the Internet.
The outgoing packet now appears to be a normal packet originating on the boundary machine. When the intended target (some server somewhere on the Internet) receives this packet, it responds in entirely normal ways. When the return packet arrives at the boundary machine (now with the original source-port in the destination-port field), the boundary machine looks up the source-address and destination-port in its lookup table. If it is found, that implies that the incoming packet is a reply to one that was translated previously. The original source-port is re-inserted in the incoming packet's destination-port field, and the corresponding private-network IP address is inserted in the destination IP address field. The packet is then routed onto the private network, where it appears to be a perfectly normal reply from an Internet host.
There are two advantages to doing things in this roundabout way: first, the operator of a private network does not need to apply for a range of IP addresses for hosts on that network in order to achieve nearly all of the benefits of Internet access. Second, since the process is asymmetric (it must be initiated from the private network side), machines on the private network are relatively protected from many of the kinds of hacker attacks that assail publicly-accessible Internet hosts.
The major disadvantage is that private network machines cannot act as publicly-accessible hosts without special assistance from a boundary system. This makes the process of setting up servers behind a NAT boundary machine a little more challenging that if they were connected directly to the Internet. It is a trade-off.