Network Address Translation (NAT)

What is NAT?

Figure 5
Figure depicting The NAT table
The NAT table

Destination network address translation (DNAT)

What is DNAT?

Destination network address translation (DNAT) is most often used to redirect packets destined for a particular IP address, or a specific port on an IP address, on one host to a different address and/or port, possibly on a different host. As this functionality is mostly used to forward packets arriving on a particular port to the same port on a different host it is often also referred to as port-forwarding.

How does DNAT work?

To make the DNAT example, and especially the DNAT caveats discussed in the next section, easier to understand let's examine what happens when a packet arrives on the WAN interface destined for an address and port which we have decided to forward.

  1. A packet arrives at our public address with that address set as its destination address and its source address set to that of the originating host.
  2. The packet traverses the PREROUTING chain of the nat table and encounters our DNAT rule where its destination address is modified to that specified in the --to-destination option.
  3. The firewall host makes a routing decision and sends the packet out of the correct interface destined for the address which was just rewritten. The packet's source address is unchanged and still represents the originating host.
  4. The packet arrives at the host we specified. This host then generates a response packet which it sends back to the originating host. As the source address was unchanged it should be sent back via the default gateway which will be the firewall host in the previous step.
  5. The packet is received by the firewall host which sees that it is destined for the same host which it just performed the DNAT operation for. It therefore modifies the source address of the returning packet so that it looks like it came from the address it was destined for before it was DNATed in step two.
  6. The packet arrives at the host which requested it and, as its source address is the same as that to which the original request was sent, is gratefully received.

As you can see this provides an almost completely transparent mechanism which enables a host on one network to appear as if it is handling requests when in fact a different host, possibly on a different network, is responding. This makes it ideal when we want to host a variety of services on different machines but only have a single public facing address.

A simple DNAT example

The Netfilter framework provides a target to implement destination network address translation, rather unsurprisingly named DNAT. The example below illustrates how one could forward all packets arriving on a particular port, in this case that reserved for the IAX2 protocol, to a different machine, which for the purposes of this example is a machine on a private local network although this is not a requirement.

/usr/local/sbin/config-firewall
iptables -t nat -A PREROUTING -i $WAN_IF -p udp --dport iax2 -j DNAT --to-destination 10.0.0.30

As you can see we specify the interface, protocol and port exactly as we have done for all the other match specifiers we have written so far. If we only wanted to apply this rule to a specific address on our WAN interface then we could use the --dst match specifier and specify that address in addition to the interface. The only new option which we have used is -t nat to indicate that we want iptables to operate on the nat table.

DNAT caveats

Although the above rule looks extremely simple, and indeed it is, there are some fairly subtle complications which at first glance may not be obvious.

The first of these is encountered when a machine on the same network as the destination host is the source of the packet. In this case when step four of the DNAT example above is reached the source address of the packet indicated that the host is on the local network. This means that the packet does not need to be routed back through the firewall which performed the DNAT operation. Instead it is sent directly to the requesting host which, as it has no record of ever requesting a packet from that host, drops it.

The second problem is more subtle still as it only affects the firewall machine. When a packet leaves the firewall destined for a local address it will not traverse the PREROUTING chain and will therefore actually end up at the address of the firewall.

Both of these problems can be solved by adding more rules to the firewall script however a better solution, which does not have any of the associated drawbacks, is to configure a local DNS server to supply the correct internal address for the services. This has the added advantage of not requiring any processing by the firewall machine for local connections.

Warning:
Whenever DNAT is used to allow an internal machine to service requests from the Internet it should probably be placed in a DMZ, a separate firewalled network segment, so that if it is compromised in any way there is still something between it and the rest of your network.
 

Source network address translation (SNAT)

What is SNAT?

Source network address translation (SNAT) is essentially the opposite of destination network address translation. Instead of being used to change the destination address of a packet it is used to change the source address of a packet. This is usually done to allow a network using a private address range to make requests to hosts on the Internet using a single public facing address.

How does SNAT work?

To make the SNAT example, and especially the SNAT caveats discussed in the next section, easier to understand let's examine what happens when a packet leaving the local network arrives on the LAN interface of the firewall host.

  1. A packet arrives at our local address with an Internet address set as its destination address and its source address set to that of the originating host on out local network.
  2. The firewall host makes a routing decision and sends the packet out of the WAN interface destined for the Internet address of the destination host. The packet's source address is unchanged and still represents the originating host on our LAN.
  3. The packet traverses the POSTROUTING chain of the nat table and encounters our SNAT rule where its source address is modified to that specified in the --to-source option.
  4. The packet arrives at the host on the Internet. This host then generates a response packet which it sends back to the source address of the request packet. As this was rewritten it will be the address of the public interface of the firewall host in the previous step.
  5. The packet is received by the firewall host which sees that it is part of a stream which it just performed the SNAT operation on. It therefore modifies the destination address of the returning packet to the address of the host on the local network which sent the packet we received in step one.
  6. The packet arrives at the host which requested it and is gratefully received.

This provides an almost completely transparent mechanism which enables multiple hosts on a network to issue requests and appear as a single host. This makes it ideal when we want to allow a network using private addresses to access the Internet when we only have a single public address.

A simple SNAT example

As you may have guessed the Netfilter framework provides a target to implement source network address translation named SNAT. The example below illustrates how one could perform source network address translation to allow an entire private network to access the Internet using a single public address.

/usr/local/sbin/config-firewall
iptables -t nat -A POSTROUTING -o $WAN_IF -j SNAT --to-source $WAN_IP

SNAT caveats

You have probably realised by now that network address translation is never completely transparent. SNAT is no exception. When we described how SNAT works we assumed in step three that this was the only connection to that destination using that source port. If this was not the case then the SNAT system would have no alternative but to rewrite the source port as well.

Source port rewriting rarely has any noticeable impact however in some circumstances a service requires that clients connect from a particular source port, sometimes even one which they have specified. If this is the case then only a single host on the private network will be able to establish a connection with each such host on the Internet. A proxy server can often be used to solve this problem if it is a well known protocol.

Masquerading (SNAT for DHCP)

What is masquerading?

When we described the SNAT target in the previous section we explained how the new source address was specified using the --to-source option. Users of dynamically assigned network addresses, such as those provided by DHCP servers to DSL and cable-modem users, will have realised that their network address can change and that to specify it in advance is therefore impossible.

For this reason the Netfilter system provides a target called MASQUERADE which automatically retrieves the network address which the system has been assigned and uses that when performing SNAT. It also monitors for address changes and, should this occur, resets the connection tracking tables.

A simple MASQUERADE example

The MASQUERADE target is used in exactly the same way as the SNAT target we described in the previous section. The only difference is that there is no need to specify a source address. Port rewriting can be controlled using the --to-ports option.

/usr/local/sbin/config-firewall
iptables -t nat -A POSTROUTING -o $WAN_IF -j MASQUERADE