Before delving into the tools, the need for Network Address Translation (NAT) needs to be understood.
The Internet as we know it today originally started out as a Department of Defense (DOD) research project called DARPANET. In the early 1980s (when the IP protocol was developed), there were less than 1,000 systems connected and IP address allocations were free and easy to obtain. By the late 1980s, there were close to 100,000 systems. Thanks to the commercialization of the Internet in the mid-1990s, there are now well over 400 million active systems connected—all requiring unique IP addresses. The upshot of this is that we are facing an IP address shortage. Several techniques have been developed to combat this problem; the most successful is Network Address Translation, also historically known as Network Masquerading or IP Masquerading.
A device must be configured to do NAT and generally needs at least two interfaces: an outside and an inside. The IP address for the inside interface can be almost anything, but good form dictates we use a reserved or non-Internet-routable IP address from the ranges provided by RFC-1918, which includes the 192.168.x.x, 172.16.x.x through 172.32.x.x, and 10.x.x.x subnets. The outside interface IP address is generally an address that is routable to the rest of the Internet.
Systems behind the NAT device (i.e., on the inside) route their packets to the NAT for forwarding. These packets have nonroutable addresses such as those just mentioned. When they pass through the NAT, the NAT removes the nonroutable address, replaces (translates) the address with a routable one (generally the outside interface IP address), logs the session in a session table, and sends the packet on its way. When a response packet arrives at the outside interface that matches the session quadruple (Source-IP, Source-Port, Destination-IP, Destination-Port), the NAT simply translates the IP address to the true inside IP address, and then sends the packet on to the requestor. More advanced NAT systems also modify the requestor's source port to avoid possible session collision. An example is given in the sidebar "The Need for Port NAT" in this chapter.
A side benefit of having a session table is that any packet arriving at the outside NAT interface that does not match a session in the session table is dropped, as it does not know which inside system to map the address to—an instant block-all-incoming-connection firewall. Of course, the downside is that no one behind the NAT is directly reachable from the Internet. While that method may be effective for blocking attackers, it's worthless when you're trying to provide a service (e.g., HTTP, FTP, SMTP) from one of these inside systems. Some ISPs purposely place their clients on nonroutable IP addresses and NAT them as they leave the ISP's network for this very reason—they do not want customers hosting servers.
Before anyone ever heard of Linksys, D-Link, or Buffalo Systems, some people wanted to share an Internet connection with systems on their local LAN. And so IP Masquerade using a regular PC was born. Nowadays, you can't swing a dead cat around in a Best Buy, CompUSA, Circuit City, or Fry's without knocking over a NAT router, two Wi-Fi NAT routers, and a VOIP Wi-Fi NAT router. In fact, the Linksys WRT54G and WRT54GS both use Linux with iptables to provide firewall and NAT services.
And there are a number of reasons why you might want to use a real PC for a NAT gateway: put a spare machine gathering dust to use (gateways generally do not need much in the way of hardware), ability to use enhanced packet mangling/filtering rules, or desire to built a specialized proxy system.
As I mentioned, a simple NAT system keeps a table of active sessions it is translating. These sessions are created when a host on the inside initiates the connection through the NAT firewall to a remote server. However, this creates a problem: what if someone on the outside of a NAT firewall wants to initiate a connection inwards to a server located behind the firewall? The server's true inside IP is generally not routable, so there is no simple way to access this server. There is also no existing session in the session table for the NAT firewall to map the session to, even if the IP address is known.
To solve this connectivity problem, most firewalls support Reverse Static NAT mapping or Mapped IP or something similar. The actual idea is simple: create a static session map that says "Anytime a packet is sent to port X on your outside interface, always map it to port Y and IP address A.B.C.D on the inside." Note that port X does not need to equal port Y, but for simplicity's sake, they often do. Once a mapping such as this is enabled, and any other packet filtering options allow outsiders to connect to this port, then the inside host is directly reachable from the Internet, with all of the benefits and liabilities that come with that access.