Featured image of post Iptables for Routing

Iptables for Routing

Iptables provide five tables (filter, nat, mangle, security, raw), but the most commonly used are the filter table and the nat table. Tables are organized as chains, and there are five predefined chains, PREROUTING, POSTROUTING, INPUT, FORWARD, and OUTPUT.

Here we focus only on the nat table. The filter table is also essential, but it’s mainly used for firewalls, so we do not discuss it here. The nat tables are used for network address translation, and it’s available in PREROUTING, POSTROUTING, and OUTPUT chains.

Below is the general diagram of the nat table in iptables.


It helps to break the diagram down. An incoming packet goes through the PREROUTING chain, and then the kernel makes the routing decision based on the routing table. If the packet is destined for the machine itself, it’s put into a local process listening on the machine. If it’s destined for another machine (so this machine serves as a router), the kernel will put it through the POSTROUTING chain and then send it to an output interface.

A packet generated from a local process will be routed and then put into the OUTPUT chain. The reroute check step is a little bit complicated, so we will explain it afterwards. The packet then goes to POSTROUTING and then goes to an output interface.

In this article, we will continue to use the home network setup below.

home network

You might find it’s hard to experiment with what I described in this article since your router might not have iptables. You need more advanced router firmware to use iptables, like OpenWrt or ASUS-Merlin. Don’t worry, in the article Network Namespaces and Docker, you will learn how to simulate this setup on your Linux machine.

SNAT in iptables

To access the Internet from the two computers in the local network, the following SNAT (S stands for source) rule has to be added to the router:

iptables -t nat -A POSTROUTING -o eth0 -s -j SNAT --to-source

Here -t stands for table, -A stands for append, -s stands for source, -o stands for output interface and -j stands for jump. This rule will replace the source address of any IP packets going to the Internet through interface eth0 whose source address is in our local subnet with, the public IP address of the router. For any response packets, the reverse operation that sets the destination address to the private address of the connecting device (e.g., is automatically applied, so we do not need to worry about configuring it. The network address translation process works like the diagram below.


Note that SNAT rules have to be configured in the POSTROUTING chain. Sometimes this requirement is reasonable. For example, in our case, the matching condition includes the output interface (eth0), so it can only be used when the routing decision has been made. But sometimes we do not match against output interfaces, and it’s still a requirement that SNAT can only be in the POSTROUTING chain.

However, our router may be allocated a dynamic address by DHCP instead of being configured a static one. In this case, we could use the MASQUERADE target, which is similar to SNAT except that we do not need to specify --to-source address. Instead, the IP address of the output interface (here, eth0) will be used automatically.

iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE

MASQUERADE can only be used in the POSTROUTING chain because the source IP address of the packet will be obtained from the network interface it gets routed to, so it should be placed after the routing decision.

Port forwarding

Another use case of NAT is port forwarding. When we are running a service on one of our computers, say, PC1, and would like to access it from the Internet. Port forwarding is usually implemented using DNAT (D stands for destination) rules

DNAT in iptables

Suppose the service is opened on port 80 and we want to access it on port 8080 of the router. We will add the following DNAT rule.

iptables -t nat -A PREROUTING -p tcp -m tcp --dport 8080 -j DNAT --to-destination

The option -p tcp (p stands for protocol) matches for TCP connections (so this rule doesn’t apply to UDP), while --dport 8080 (--dport stands for destination port) matches for TCP traffic destining port 8080. This rule will replace the destination address of any IP packets going to port 8080 with, the IP address of the service. The port is also replaced with 80, the port of the service. For any response packets, the reverse operation is also automatically applied, just like in SNAT. The process works like the diagram below.


You might wonder why iptables, a layer 3 (network layer) tool, could modify port information, which is on layer 4 (transport layer). In fact, although iptables mainly work on layer 3, it has been extended to work on layer 4 as well, so working with ports is also possible for iptables. In our case, the option -m tcp (m stands for “match” an extension) loads an extension called tcp to work on ports, and the --dport option is provided by this extension. Actually, the option -p tcp implicitly loads the tcp extension so -m tcp is redundant. Here is the documentation for all standard extensions on Ubuntu. Also note that DNAT rules must be configured on the PREROUTING or OUTPUT chain because it’s useless to modify the destination IP address after the routing decision has been made.

Router access

If you try to access the service from the router itself using, you will find that it doesn’t work. Note that our command puts the DNAT rule into the PREROUTING chain, but packets generated by local processes go to the OUTPUT chain instead of PREROUTING. As a result, we have to also configure DNAT on the OUTPUT chain for a local process to access the service.

iptables -t nat -A OUTPUT -p tcp --dport 8080 -j DNAT --to-destination

Note that -m tcp is removed in the command above. It’s also valid since the tcp extension is loaded automatically by -p tcp. However, now we can access the service only by the IP address, and if we use or it still fails. Let me explain why.

How locally-generated packets are processed

A machine has more than one IP address. For example, the host PC1 has for the loopback interface and for interface eth0. The router has three IP addresses because it has two physical interfaces and a loopback interface. The local process generating packets must specify the destination address, but the source address is usually not specified. Here is the question: How do we determine the source IP address of a locally generated packet? Which IP address for which interface should we choose? The answer is: by looking at the route table.

For a packet generated by a local process, it goes to the routing step first. The kernel matches the destination address against the route table, selects an output interface, and takes the IP address of the chosen interface as its source address. For example, when PC1 sends a packet to (or other localhost addresses), the packet will be routed to the loopback interface and thus take the IP address In contrast, if the packet is sent to the Internet, it will be routed by the routing rule default via dev eth0 to interface eth0 and take the IP address After the routing process, the packet is then put into the OUTPUT chain. As a result, we have access to both the packet’s source and destination address in the OUTPUT chain.

However, as is shown above, we might do NAT in the output chain, which might change the destination address. In this case, we need to re-select an output interface by doing another routing process, and this is what the “reroute check” step does.

reroute check

For example, suppose we send a packet to from the router. The steps it will go through are:

  1. Its destination address is, so it’s routed to the loopback interface, and its source IP address is set to
  2. The DNAT rule in the OUTPUT chain gets applied, which modifies its destination IP address to
  3. The packet is rerouted to the eth1 interface by reroute-check, and then sent to PC1, but PC1 does not know where to reply: its source IP is!

The caveat here is that reroute check does not touch the source address, which brings us the problem with local access.

On most routers, the output interface will drop the request packet without sending them out, since is not a valid source address for interface eth1. The same goes for the case where we access from the router: The packet gets dropped before being sent out since is invalid for eth1.

What if the packet is sent to It will go through the following steps:

  1. Its destination address is, so it’s routed to the eth1 interface, and its source IP address is set to
  2. The DNAT rule in the OUTPUT chain gets applied, which modifies its destination IP address to
  3. The packet goes through reroute-check, but the output interface doesn’t get modified. It is then sent to PC1, with a correct source IP address so PC1 knows where to reply

This explains why works: The source IP address happens to be correct!

MASQUERADE rule for router access

It turns out that we must add another SNAT rule to correct the source address of the packet.

iptables -t nat -A POSTROUTING -m addrtype --src-type LOCAL -o eth1 -j MASQUERADE

The option src-type is provided by extension addrtype, which matches against all IP addresses on the machine, including:

  • all addresses in
  • since it’s the address on eth1
  • since it’s the address on eth0

This SNAT rule applies after the reroute-check step since it’s in the POSTROUTING chain. In this way, the packet sent to the local network will always have the source address, so PC1 knows where to send the response.

Kernel option for routing localhost addresses

However, the SNAT rule above alone is not sufficient. At this time, accessing the service via succeeds, but still fails. It turns out that the reroute check step will deny packets with a localhost source address, for security reasons. For packets to pass reroute-check, we need to turn on route_localnet for the interface eth1 using the Linux kernel parameter net.ipv4.conf.eth1.route_localnet by doing

sysctl -w net.ipv4.conf.eth1.route_localnet=1

The command above only sets the parameter temporarily. To set kernel parameters permanently, see Hosts as routers


In summary, for the router to access the exposed port locally, we need to

  • add the port forwarding rule to the OUTPUT chain
  • add a SNAT rule to correct the source address of packets going to the local network
  • set the option route_localnet to enable access through addresses

Load balancing

What if the service is running on both PC1 and PC2? In this case, the router has to do load balancing by randomly distributing traffic to PC1 and PC2. We use an extension called statistic to implement it. Again, statistic is also a standard extension on Ubuntu.

iptables -t nat -A PREROUTING -p tcp --dport 8080 -m statistic --mode random --probability 0.5 -j DNAT --to-destination
iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination

The first rule sends TCP traffic destining port 8080 to with a 50% probability, while the second rule sends all (remaining) traffic to You might be wondering why the second rule is not configured to use statistic. In fact, iptables match rules linearly. 50% of the traffic matches the first rule and the second rule only matches the remaining 50%, so just sending all of them to PC2 is sufficient for it. Thus, the effective probability of sending traffic to PC2 is (1-50%)*100%=50%.

Note that the two commands above only configure load balancing for packets sending to the router from elsewhere. To also configure load balancing for local processes, we need to add them to the OUTPUT chain.

iptables -t nat -A OUTPUT -p tcp --dport 8080 -m statistic --mode random --probability 0.5 -j DNAT --to-destination
iptables -t nat -A OUTPUT -p tcp --dport 8080 -j DNAT --to-destination

Hairpin NAT

Let’s go back to the scenario that the service is running only on PC1. What happens when, say, PC2 accesses and gets redirected to PC1? The process is illustrated in the diagram below. Red lines stand for request packets, and green lines stand for response packets. Here in the example, we are accessing, but we can also access The results are similar.

hairpin not working

First, note that the packet received by the router arrives at the eth1 interface in this scenario, while public network packets arrive at the eth0 interface. That is why we do not specify any input interface in DNAT in iptables. It provides a chance for all machines, including local machines and machines on the public network, to access the service via its 8080 port.

The destination address of the request packet gets translated to, which is the IP address and port for the service running on PC1. Thus, the request packet arrives at PC1 successfully. However, the response packet will not go to the router since the source address of the request packet is, and it’s in the local network. As a result, the response packet arrives at PC2 through the switch without going to the router.

What is the problem here? From the perspective of PC2, it sends a packet to but receives a packet from In this case, it will not think of the received packet as the response for the request packet, so the upper layer (the transport layer) will not put them into the same connection. For example, if the request packet is a TCP handshake SYN and the response is a TCP handshake SYN/ACK, the handshake will not succeed.

The reverse rule of DNAT which sets the source address to applies automatically for response IP packets going through the router, but here the response packets never go to the router. So what is the solution for this issue? It turns out we must add a MASQUERADE rule.

iptables -t nat -A POSTROUTING -s -o eth1 -p tcp --dport 80 -j MASQUERADE

Note that we use the port number 80 here because the port number has already been translated from 8080 to 80 by the DNAT rule in PREROUTING chain.

The whole process after MASQUERADE is added looks like the diagram below.

hairpin working

When the request packet goes through the router, its destination address is translated to by the DNAT rule. In addition to this, its source address is translated to, the address of the gateway, by the MASQUERADE rule. Because of the translation of the source address, the response packet will be sent to the router, which gives the reverse rule of DNAT a chance to apply, so the source address of the response packet is translated to PC2 now sees the source address of the response packet to match the destination address of the request packet so that the upper layer can put them into one connection.

The situation that a machine in the internal network access a service exposed through DNAT is called hairpin NAT, since the packet is forwarded back, just like a hairpin.


The case where a machine access itself through hairpin NAT is similar, but a little bit harder to reason. I include a diagram below. You might be wondering why a machine may access itself through hairpin NAT. One situation is when a group of machines is providing a service that is load-balanced by the router. If one of the machines access the service and the router routes the request back to the machine itself, a hairpin NAT looping back to the same machine will happen.

hairpin same machine

The video series below explains iptables and other networking-related topics in great detail.