iptables NAT Semantics

iptables provides full NAT functionality, including both source (SNAT) and destination (DNAT) address mapping. The term full NAT isn't a formal term; I'm referring to the capability to perform both source and destination NAT, to specify one or a range of translation addres-ses, to perform port translation, and to perform port remapping. iptables supports the three general types of NAT (traditional NAT, bidirectional NAT, and twice NAT), as defined in RFC 2663.

A partial implementation of NAPT, known as masquerading among Linux users, was provided in earlier Linux releases. It was used to map all local, private addresses to the single public IP address of the site's single public network interface.

NAT and forwarding were often spoken of as two components of the same thing because masquerading was specified as part of the forward rule's semantics. Blurring the concepts was irrelevant functionally. Now it's very important to keep the distinction in mind. Forwarding and NAT are two distinct functions and technologies.

Forwarding is routing traffic between networks. Forwarding routes traffic between network interfaces as is. Connections can be forwarded in either direction.

Masquerading sits on top of forwarding as a separate kernel service. Traffic is masqueraded in both directions, but not symmetrically. Masquerading is unidirectional. Only outgoing connections can be initiated. As traffic from local machines passes through the firewall to a remote location, the internal machine's IP address and source port are replaced with the address of the firewall machine's external network interface and a free source port on the interface. The process is reversed for incoming responses. Before the packet is forwarded to the internal machine, the firewall's destination IP address and port are replaced with the real IP address and port of the internal machine participating in the connection. The firewall machine's port determines whether incoming traffic, all of which is addressed to the firewall machine, is destined to the firewall machine itself or to a particular local host.

The semantics of forwarding and NAT are separated in iptables. The function of forwarding the packet is done in the filter table using the FORWARD chain. The function of applying NAT to the packet is done in the nat table, using one of the nat table's POSTROUTING, PREROUTING, or OUTPUT chains:

• Forwarding is a routing function. The FORWARD chain is part of the filter table.

• NAT is a translation function that is specified in the nat table. NAT takes place either before or after the routing function. The nat table's POSTROUTING, PREROUTING, and OUTPUT chains are part of the nat table. Source NAT is applied on the POSTROUTING chain after a packet has passed through the routing function. Source NAT is also applied on the OUTPUT chain for locally generated, outgoing packets. (The filter table OUTPUT chain and the nat table OUTPUT chain are two separate, unrelated chains.) Destination NAT is applied on the PREROUTING chain before passing the packet to the routing function.

A word of caution is in order for readers who are used to the combined forward and MASQ semantics of ipfwadm and ipchains. In iptables, maintaining the clear demarcation between prerouting, forwarding, and post-routing has serious repercussions in terms of the forwarding and NAT rules, as compared to those in ipfwadm and ipchains. In iptables forwarding, the rules are usually specified as a pair, one for each direction between the two interfaces. Use of the state module can hide this fact by allowing all ESTABLISHED rules to be collapsed into a single pair.

In iptables NAT, a single rule is specified. The NAT table entry is created when the first packet in the exchange is received or sent. NAT recognizes returning responses by their destination address and port pair, and it automatically reverses the original process. Because forwarding and NAT are applied on different chains at different points in the packet's path, all three rules are needed: the two rules in the forwarding rule pair and the single NAT rule.

Perhaps a more insidious issue is just what the address in the packet is on any given chain. Associated rules on the PREROUTING, POSTROUTING, FORWARD, INPUT, and OUTPUT chains will see different addresses in the same packet. The various rules applying to the same packet will have to match on different addresses.

WHICH DESTINATION ADDRESS IS SEEN WHERE?

Destination NAT is applied on the nat table's PREROUTING chain, before the routing decision is made. Rules on the PREROUTING chain must match on the original destination address in the packet's IP header. Rules on the filter table's INPUT or FORWARD chain must match on the modified, NATed address in the same packet header. Likewise, if that same packet were to also have source NAT applied after the routing decision is made, and if the destination address were important to match on, the rule on the nat table's POSTROUTING chain would match on the modified destination address.

Source NAT is applied on the nat table's POSTROUTING chain, after the routing decision is made. Rules on any chain match on the original source address. The source address is modified immediately before sending the packet on to the next hop or destination host. The modified source address isn't seen on the host applying the source NAT.

None of these distinctions between forwarding and NAT was an apparent issue with ipfwadm and ipchains. The forwarding rule pair wasn't necessary when masquerading. Two-way forwarding and NAT were implied by a single rule. The incoming local interface was implied by the source address. The translated source address was taken from the outgoing public interface specification. Reverse translation for response packets was implied without an explicit rule.

DON'T GO OVERBOARD USING NAT SYNTAX

The rest of this chapter presents the nat table syntax. Another word of caution is called for when looking at the complete NAT syntax. The following sections describe the simpler, more general syntax used with NAT, which is what will be used most commonly. The average site won't have a use for the specialized features available in the nat table.

Both SNAT and DNAT rules can specify the protocol, source and destination addresses, source and destination ports, and state flags, in addition to the translated address and ports. When this is done, the nat table rules look very much like filter table rules. It's very easy to confuse NAT rules with firewall rules, especially for people who are used to ipchains syntax. Actual filtering is done in the FORWARD chain.

You could mirror the match fields between the FORWARD rules and the NAT rules; the two sets of rules could look nearly identical. For large rule sets, it would quickly become an error-prone, administrative nightmare and would accomplish very little.

Remember that iptables forwarding and NAT are two completely separate functions. The actual firewall filtering is done by the rules in the filter table. For most people, it's best to keep the nat table rules simple.

Source NAT

Two forms of source NAT exist in the iptables nat table, specified as two distinct targets, SNAT and MASQUERADE. SNAT is standard source address translation. MASQUERADE is a specialized form of source NAT for use in environments in which an arbitrary, dynamically assigned IP address is assigned on a temporary, connection-by-connection basis.

Both targets are used on the nat table's POSTROUTING chain. Source address modifications are applied after the routing decision has been made to choose the proper outgoing interface. Thus, SNAT rules are associated with an outgoing interface, not with an incoming interface.

STANDARD SNAT

This is the general syntax for SNAT:

 iptables -t nat -A POSTROUTING -o <outgoing interface> ... \          -j SNAT --to-source <address>[-<address>][:port-port] 

The address is the source address to substitute for the original source address in the packet, presumably the address of the outgoing interface. Source NAT is what NAT is traditionally used for, to allow outgoing connections. Specifying a single translation address performs NAPT, allowing all local, privately addressed hosts to share your site's single, public IP address.

Optionally, a range of source addresses can be specified. Sites that have a block of public addresses would use this range. Outgoing connections from local hosts would be assigned one of the available addresses, with the public address being associated with a particular local host's IP address. Specifying a range of addresses represents what traditional, basic NAT is usually used for, although iptables SNAT is internally implemented as NAPT in both cases.

The final port specification is another option. The range of ports defines the pool of source ports to choose from on the NAT device's outgoing interface.

The ellipsis represents any other packet selectors that are specified. For example, SNAT could be applied only to a select local host or only for TCP connections. Another use might be for VPN, where connections between two sites might be made between two specific source and destination addresses. An alternative with VPN is that connections might be made between specific source and destination ports.

Why might a site add these match selectors to a NAT rule? These selections areor should bemade on the filter table's INPUT, OUTPUT, and FORWARD chains. In the case of applying NAT to select hosts, the site might be excluding hosts containing sensitive information. The site might contain networked devices such as printers or local wireless devices, and it might not be clear just what kinds of traffic these devices generate. Matching on TCP might be done as an added assurance that UDP traffic is not being exchanged with the Internet or that UDP traffic is passed only through specific application proxies.

MASQUERADE SOURCE NAT

The general syntax for MASQUERADE is as follows:

 iptables -t nat -A POSTROUTING -o <outgoing interface> ... \          -j MASQUERADE [--to-ports <port>[-port]] 

MASQUERADE doesn't have an option to specify a particular source address to use on the NAT device. The source address used is the address of the outgoing interface.

The optional port specification is one source port or a range of source ports to choose from on the NAT device's outgoing interface.

As with SNAT, the ellipsis represents any other packet selectors that are specified. For example, MASQUERADE could be applied to only a select local host.

Destination NAT

Two forms of destination NAT exist in the iptables nat table, specified as two distinct targets: DNAT and REDIRECT. DNAT is standard destination address translation. REDIRECT is a specialized form of destination NAT that redirects packets to the NAT device's input or loopback interface.

The two targets can be used on either of the nat table's PREROUTING or OUTPUT chains. Destination address modifications are applied before the routing decision is made to choose the proper interface. Thus, on the PREROUTING chain, DNAT and REDIRECT rules are associated with an incoming interface for packets that are to be forwarded through the device or that are addressed to this host's incoming interface. On the OUTPUT chain, DNAT and REDIRECT rules refer to locally generated, outgoing packets from the NAT host itself.

STANDARD DNAT

The general syntax for DNAT is as shown here:

 iptables -t nat -A PREROUTING -i <incoming interface> ... \          -j DNAT --to-destination <address>[-<address>][:port-port] 

and

 iptables -t nat -A OUTPUT -o <outgoing interface> ... \          -j DNAT --to-destination <address>[-<address>][:port-port] 

The address is the destination address to substitute for the original destination address in the packet, presumably the address of a local server.

Optionally, a range of destination addresses can be specified. Sites that have a pool of public, peer servers would use this range. Incoming connections from remote sites would be assigned to one of the servers. These addresses could be public addresses assigned to the internal machines. For example, a pool of peer servers appears to be a single server to remote hosts. Alternatively, the addresses could be private addresses, and the servers wouldn't be directly visible or addressable from the Internet. In the latter case, the site probably doesn't have public addresses to assign to the servers. Remote hosts attempt to connect to the service on the NAT host. The NAT host forwards the connections transparently to the privately addressed internal server.

The final port specification is another option. The port specifies the destination port, or port range, on the target host's incoming interface that the packet should be sent to.

The ellipsis represents any other packet selectors that are specified. For example, DNAT could be applied to redirect incoming connections from a specific remote host to an internal host. Another use might be to redirect incoming connections to a particular service port to the actual server running in the local network.

REDIRECT DESTINATION NAT

The general syntax for REDIRECT is shown here:

 iptables -t nat -A PREROUTING -i <incoming interface> ... \          -j REDIRECT [--to-ports <port[-port]> 

and

 iptables -t nat -A OUTPUT -o <outgoing interface> ... \          -j REDIRECT [--to-ports <port[-port]> 

Remember, REDIRECT redirects the packet to this host, which is the host performing the REDIRECT.

Packets arriving on the incoming interface are presumably addressed to some other local host. Another alternative could be that the packet is targeted to a particular local service port, and the packet is redirected to a different port on the host transparently.

Locally generated packets, destined for somewhere else, are redirected back to the loopback interface on this host. Again, a packet targeted to a specific remote service might be redirected back to the local machine, perhaps to a caching proxy, for example.

Optionally, a different destination port or port range can be specified. If no port is specified, the packet is delivered to the destination port that the sender defined in the packet.

The ellipsis represents any other packet selectors that are specified. For example, REDIRECT could be applied to redirect incoming connections to a specific service to a server, logger, authenticator, or some kind of inspection software on the local host. The packet could be sent on from this host after some kind of inspection function was performed. Another use might be to redirect outgoing connections to a particular service back to a server or an intermediate service on this host.