Note that this time the packet was passed through the INPUT chain instead of the FORWARD chain. Quite logical. Most probably the only thing that's really logical about the traversing of tables and chains in your eyes in the beginning, but if you continue to think about it, you'll find it will get clearer in time.
Now we look at the outgoing packets from our own local host and what steps they go through.
Table 6-2. Source local host (our own machine)
| Step | Table | Chain | Comment |
|---|---|---|---|
| 1 | Local process/application (i.e., server/client program) | ||
| 2 | Routing decision. What source address to use, what outgoing interface to use, and other necessary information that needs to be gathered. | ||
| 3 | raw | OUTPUT | This is where you do work before the connection tracking has taken place for locally generated packets. You can mark connections so that they will not be tracked for example. |
| 4 | The state machine | ||
| 5 | mangle | OUTPUT | This is where we mangle packets, it is suggested that you do not filter in this chain since it can have side effects. |
| 6 | nat | OUTPUT | This chain can be used to NAT outgoing packets from the firewall itself. |
| 7 | Routing decision, since the previous mangle and nat changes may have changed how the packet should be routed. | ||
| 8 | filter | OUTPUT | This is where we filter packets going out from the local host. |
| 9 | mangle | POSTROUTING | The POSTROUTING chain in the mangle table is mainly used when we want to do mangling on packets before they leave our host, but after the actual routing decisions. This chain will be hit by both packets just traversing the firewall, as well as packets created by the firewall itself. |
| 10 | nat | POSTROUTING | This is where we do SNAT as described earlier. It is suggested that you don't do filtering here since it can have side effects, and certain packets might slip through even though you set a default policy of DROP. |
| 11 | Goes out on some interface (e.g., eth0) | ||
| 12 | On the wire (e.g., Internet) |
In this example, we're assuming that the packet is destined for another host on another network. The packet goes through the different steps in the following fashion:
Table 6-3. Forwarded packets
| Step | Table | Chain | Comment |
|---|---|---|---|
| 1 | On the wire (i.e., Internet) | ||
| 2 | Comes in on the interface (i.e., eth0) | ||
| 3 | raw | PREROUTING | Here you can set a connection to not be handled by the connection tracking system. |
| 4 | The state machine | ||
| 5 | mangle | PREROUTING | This chain is normally used for mangling packets, i.e., changing TOS and so on. |
| 6 | nat | PREROUTING | This chain is used for DNAT mainly. SNAT is done further on. Avoid filtering in this chain since it will be bypassed in certain cases. |
| 7 | Routing decision, i.e., is the packet destined for our local host or to be forwarded and where. | ||
| 8 | mangle | FORWARD | The packet is then sent on to the FORWARD chain of the mangle table. This can be used for very specific needs, where we want to mangle the packets after the initial routing decision, but before the last routing decision made just before the packet is sent out. |
| 9 | filter | FORWARD | The packet gets routed onto the FORWARD chain. Only forwarded packets go through here, and here we do all the filtering. Note that all traffic that's forwarded goes through here (not only in one direction), so you need to think about it when writing your rule-set. |
| 10 | mangle | POSTROUTING | This chain is used for specific types of packet mangling that we wish to take place after all kinds of routing decisions have been done, but still on this machine. |
| 11 | nat | POSTROUTING | This chain should first and foremost be used for SNAT. Avoid doing filtering here, since certain packets might pass this chain without ever hitting it. This is also where Masquerading is done. |
| 12 | Goes out on the outgoing interface (i.e., eth1). | ||
| 13 | Out on the wire again (i.e., LAN). |
As you can see, there are quite a lot of steps to pass through. The packet can be stopped at any of the iptables chains, or anywhere else if it is malformed; however, we are mainly interested in the iptables aspect of this lot. Do note that there are no specific chains or tables for different interfaces or anything like that. FORWARD is always passed by all packets that are forwarded over this firewall/router.
Caution Do not use the INPUT chain to filter on in the previous scenario! INPUT is meant solely for packets to our local host that do not get routed to any other destination.
We have now seen how the different chains are traversed in three separate scenarios. If we were to figure out a good map of all this, it would look something like this:
To clarify this image, consider this. If we get a packet into the first routing decision that is not destined for the local machine itself, it will be routed through the FORWARD chain. If the packet is, on the other hand, destined for an IP address that the local machine is listening to, we would send the packet through the INPUT chain and to the local machine.
Also worth a note, is the fact that packets may be destined for the local machine, but the destination address may be changed within the PREROUTING chain by doing NAT. Since this takes place before the first routing decision, the packet will be looked upon after this change. Because of this, the routing may be changed before the routing decision is done. Do note, that all packets will be going through one or the other path in this image. If you DNAT a packet back to the same network that it came from, it will still travel through the rest of the chains until it is back out on the network.
Tip If you feel that you want more information, you could use the rc.test-iptables.txt script. This test script should give you the necessary rules to test how the tables and chains are traversed.