Examples of DNAT, LANs, and Proxies

For the residential and small-business site, destination NAT is probably the most welcome addition to Linux NAT.

Host Forwarding

DNAT provides the host-forwarding capability that, until now, was available only through third-party solutions. For small sites with a single public IP address, DNAT allows incoming connections to local services to be transparently forwarded to a server running in a DMZ. Public services aren't required to run on the firewall machine.

With a single IP address, remote sites send client requests to the firewall machine. The firewall is the only local host that's visible to the Internet. The service (for example, a web or mail server) itself is hosted internally in a private network. For packets arriving on that service's port, the firewall changes the destination address to that of the local server's network interface and forwards the packet to the private machine. The reverse is done for server responses. For packets from the server, the firewall changes the source address to that of its own external interface and forwards the packet on to the remote client.

The most common example is forwarding incoming HTTP connections to a local web server:

 iptables -t nat -A PREROUTING -i <public interface> -p tcp \          --sport 1024:65535 -d <public address> --dport 80 \          -j DNAT --to-destination <local web server> 

The tricky part is the question of what address is seen on each chain. Destination NAT was applied before the packet reached the FORWARD chain. So the rule on the FORWARD chain must refer to the internal server's private IP address rather than to the firewall's public address:

 iptables -A FORWARD -i <public interface> -o <DMZ interface> -p tcp \          --sport 1024:65535 -d <local web server> --dport 80 \          -m state --state NEW -j ACCEPT 

Connection tracking and NAT automatically reverse the translation for packets returning from the server. Because the initial connection request was accepted, a generic FORWARD rule suffices to forward the return traffic from the local server to the Internet:

 iptables -A FORWARD -i <DMZ interface> -o <public interface> \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

Of course, don't forget that ongoing traffic from the client must be forwarded as well because the convention used in this book has been to separate individual service rules specifying the NEW state from a single rule for all ESTABLISHED or RELATED traffic:

 iptables -A FORWARD -i <public interface> -o <DMZ interface> \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

Host Forwarding and Port Redirection

DNAT can modify the destination port as well as the destination address. By way of example, I'll set up a rather contrived situation and build on the previous example. Let's say that this site has a second semiprivate web server. The server is bound to port 81 on the same internal host. The internal host is running two separate web servers, hosting two different websites. Clients direct their requests to port 80 on the firewall. Port 81 is closed on the firewall. Incoming connections to the semiprivate server are accepted from only specific remote addresses.

In other words, all incoming web connection requests are targeted to the firewall host's TCP port 80. Requests from general client addresses are NATed and forwarded to port 80 on the server in the DMZ. Requests from specific remote clients are NATed and forwarded to a second web server on port 81 on the same server in the DMZ.

The NAT rule translates both the destination address and the destination port. The order of the two NAT rules is important here. The client traffic is originally targeted to port 80 in both cases. Firewall rules are ordered from most specific to most general. The selected clients must be selected out and redirected to port 81 before their packets match the more general rule that matches all clients and redirects packets to port 80 on the internal host:

 iptables -t nat -A PREROUTING -i <public interface> -p tcp \          -s <allowed remote host> --sport 1024:65535 \_          -d <public address> --dport 80 \          -j DNAT --to-destination <local web server>:81 iptables -t nat -A PREROUTING -i <public interface> -p tcp \          --sport 1024:65535 -d <public address> --dport 80 \          -j DNAT --to-destination <local web server> 

The rule on the FORWARD chain must refer to the internal server's private IP address and port 81 rather than to the firewall's public address and port 80. Rule order is not important here. The NAT modification was done previously on the PREROUTING chain. The forwarding rules see the modified packets:

 iptables -A FORWARD -i <public interface> -o <DMZ interface> -p tcp \          --sport 1024:65535 -d <local web server> --dport 81 \          -m state --state NEW -j ACCEPT iptables -A FORWARD -i <public interface> -o <DMZ interface> -p tcp \          --sport 1024:65535 -d <local web server> --dport 80 \          -m state --state NEW -j ACCEPT 

As in the previous example, the single generic FORWARD rule pair for ongoing connections is repeated here:

 iptables -A FORWARD -i <DMZ interface> -o <public interface> \          -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i <public interface> -o <DMZ interface> \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

Host Forwarding to a Server Farm

DNAT can accept a range of destination addresses to translate to, and it selects one of the addresses when the exchange is initiated. As an example of multiple destination addresses, let's say that this site has a handful of public addresses. A web server is advertised as running on one of these addresses. Five duplicate web servers are running in the DMZ, each assigned a different private IP address ranging from 192.168.1.1 to 192.168.1.5. Remote clients address the web server at the single public address.

The NAT rule translates the original destination address to one of the addresses in the NAT list:

 iptables -t nat -A PREROUTING -i <public interface> -p tcp \          --sport 1024:65535 -d <public Web address> --dport 80 \          -j DNAT --to-destination 192.168.1.1-192.168.1.5 

The private server address range was chosen to allow the FORWARD rule to use an address mask to match any of the servers' addresses:

 iptables -A FORWARD -i <public interface> -o <DMZ interface> -p tcp \          --sport 1024:65535 -d 192.168.1.0/29 --dport 80 \          -m state --state NEW -j ACCEPT 

As in the previous examples, the single generic FORWARD rule pair for ongoing connections is repeated here:

 iptables -A FORWARD -i <DMZ interface> -o <public interface> \          -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i <public interface> -o <DMZ interface> \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

There are, of course, multiple ways to accomplish this same task with Linux including the Linux Virtual Server, which enables more robust configuration of load balancing and redundancy.

Host Forwarding to Servers in a Privately Addressed DMZ

It's fairly common for a small SOHO site to have a handful of public IP addresses. The site offers multiple services from a DMZ. Although the site has enough public addresses to assign to each server, there won't be enough if the address block is divided into multiple subnets. The public addresses can't be assigned to the servers in the DMZ without dividing the subnets or bridging because routing requires that the firewall's public and DMZ interface addresses belong to different address domains. Some sites use a network mask to allow the public interface to accept any address in the public block. The servers in the DMZ are advertised as running at one of these public addresses, but the servers themselves are assigned private addresses. NAT is used to transparently translate between the public address that's associated with the server and the server's actual private address.

As a final example of DNAT, let's say that the site is assigned eight public IP addresses. The site's network information is listed in Table 7.1.

Table 7.1. Sample SOHO Public Address Block with Eight IP Addresses

ADDRESS BLOCK	IP ADDRESS
Network Address	169.254.25.80/29
Network Mask	255.255.255.248
Router Address	169.254.25.81
Firewall/DNS Address	169.254.25.82
First Host Address	169.254.25.83
Last Host Address	169.254.25.86
Broadcast Address	169.254.25.87
Total Local Hosts	5

The site's server's address mapping information is listed in Table 7.2.

Table 7.2. Sample Logical Mapping Between Public and Private Server Addresses

SERVER	PUBLIC ADDRESS	PRIVATE DMZ ADDRESS
Public Web Server	169.254.25.83	192.168.1.3
Customer Web Server	169.254.25.84	192.168.1.4
FTP Server	169.3254.25.85	192.168.1.5
Mail Server	169.254.25.86	192.168.1.6

The NAT rules follow. The addresses in Table 7.2 are replaced with shell variables or constant names for clarification:

 iptables -t nat -A PREROUTING -i <public interface> -p tcp \          --sport 1024:65535 -d $PUBLIC_WEB_SERVER --dport 80 \          -j DNAT --to-destination $DMZ_PUBLIC_WEB_SERVER iptables -t nat -A PREROUTING -i <public interface> -p tcp \          --sport 1024:65535 -d $CUSTOMER_WEB_SERVER --dport 443 \          -j DNAT --to-destination $DMZ_CUSTOMER_WEB_SERVER iptables -t nat -A PREROUTING -i <public interface> -p tcp \          --sport 1024:65535 -d $FTP_SERVER --dport 21 \          -j DNAT --to-destination $DMZ_FTP_SERVER iptables -t nat -A PREROUTING -i <public interface> -p tcp \          --sport 1024:65535 -d $MAIL_SERVER --dport 25 \          -j DNAT --to-destination $DMZ_MAIL_SERVER 

Destination NAT is applied before the packet reaches the FORWARD chain. The rules on the FORWARD chain must refer to the internal servers' private IP addresses:

 iptables -A FORWARD -i <public interface> -o <DMZ interface> -p tcp \          --sport 1024:65535 -d $DMZ_PUBLIC_WEB_SERVER --dport 80 \          -m state --state NEW -j ACCEPT iptables -A FORWARD -i <public interface> -o <DMZ interface> -p tcp \          --sport 1024:65535 -d $DMZ_CUSTOMER_WEB_SERVER --dport 443 \          -m state --state NEW -j ACCEPT iptables -A FORWARD -i <public interface> -o <DMZ interface> -p tcp \          --sport 1024:65535 -d $DMZ_FTP_SERVER --dport 21 \          -m state --state NEW -j ACCEPT iptables -A FORWARD -i <public interface> -o <DMZ interface> -p tcp \          --sport 1024:65535 -d $DMZ_MAIL_SERVER --dport 25 \          -m state --state NEW -j ACCEPT 

As a reminder, the single generic FORWARD rule pair for ongoing connections is repeated here:

 iptables -A FORWARD -i <DMZ interface> -o <public interface> \          -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -i <public interface> -o <DMZ interface> \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

Local Port RedirectionTransparent Proxying

Local port redirection, the REDIRECT target in iptables, is a special case of destination NAT. The packet is redirected to the local host, regardless of the packet's destination address. Incoming packets to be forwarded are redirected from the nat table's PREROUTING chain to the filter table's INPUT chain. The incoming interface is the interface that the packet arrived on. Outgoing packets from the local host are redirected from the nat table's OUTPUT chain to the filter table's INPUT chain. The incoming interface is the internal loopback interface.

This feature is useful for some of the application-level proxies that you might run. The squid web cache server, which is bound to TCP port 3128 by default, is a good example. It can be configured to run transparently. As a local service, the following rules would be used on internal machines rather than on the gateway firewall. The REDIRECT would be applied to outgoing local traffic rather than to incoming remote traffic.

When the squid proxy server is configured to run transparently, the browsers use standard HTTP rather than the special proxy protocol. The browsers aren't configured to use a proxy. Their outgoing client requests are simply intercepted and redirected to the local server transparently.

Again, the following example is a bit contrived. squid is hosted more securely when it is configured to expect proxy traffic rather than regular HTTP traffic.

In this example, outgoing LAN web client traffic is redirected to the squid server running on a local host. That host could be running in the private LAN or in the DMZ:

 iptables -t nat -A PREROUTING -i <lan interface> -p tcp \          -s <lan hosts> --sport 1024:65535 --dport 80 \          -j REDIRECT --to-port 3128 

The redirected packet will be delivered to the input queue associated with the network interface connected to the LAN on this host. As such, an INPUT rule is needed to accept the packet:

 iptables -A INPUT -i <lan interface> -p tcp \          -s <lan hosts> --sport 1024:65535 -d <lan address> --dport 3128 \          -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT 

squid is a proxy as well as a web cache server, so web traffic isn't forwarded. Instead, the squid server establishes connections with the remote web servers, acting as a client itself:

 iptables -A OUTPUT -o <public interface> -p tcp \          -s <public address> --sport 1024:65535 --dport 80 \ -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -i <public interface> -p tcp \          --sport 80 -d <public address> --dport 1024:65535  \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

squid responds as a server to the LAN client:

 iptables -A OUTPUT -o <lan interface> -p tcp \          -s <lan address> --sport 80 --dport 1024:65535 \          -m state --state ESTABLISHED,RELATED -j ACCEPT 

Notice that the OUTPUT rule requires the source address to be the host's local LAN interface address. REDIRECT is a form of destination NAT. The returning response appears to be returning from the remote server that the client originally addressed, but the reverse NAT occurs after the packet leaves the filter table's OUTPUT chain.