Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions

  




 

 

Chapter 6. Traversing of tables and chains

In this chapter we'll discuss how packets traverse the different chains, and in which order. We will also discuss the order in which the tables are traversed. We'll see how valuable this is later on, when we write our own specific rules. We will also look at the points which certain other components, that also are kernel dependent, enter into the picture. Which is to say the different routing decisions and so on. This is especially necessary if we want to write iptables rules that could change routing patterns/rules for packets; i.e. why and how the packets get routed, good examples of this are DNAT and SNAT. Not to be forgotten are, of course, the TOS bits.

6.1. General

When a packet first enters the firewall, it hits the hardware and then gets passed on to the proper device driver in the kernel. Then the packet starts to go through a series of steps in the kernel, before it is either sent to the correct application (locally), or forwarded to another host - or whatever happens to it.

First, let us have a look at a packet that is destined for our own local host. It would pass through the following steps before actually being delivered to our application that receives it:

Table 6-1. Destination local host (our own machine)

StepTableChainComment
1  On the wire (e.g., Internet)
2  Comes in on the interface (e.g., eth0)
3manglePREROUTINGThis chain is normally used for mangling packets, i.e., changing TOS and so on. This is also where the connection tracking takes place, which we discuss in the The state machine chapter.
4natPREROUTINGThis chain is used for DNAT mainly. Avoid filtering in this chain since it will be bypassed in certain cases.
5  Routing decision, i.e., is the packet destined for our local host or to be forwarded and where.
6mangleINPUTAt this point, the mangle INPUT chain is hit. We use this chain to mangle packets, after they have been routed, but before they are actually sent to the process on the machine.
7filterINPUTThis is where we do filtering for all incoming traffic destined for our local host. Note that all incoming packets destined for this host pass through this chain, no matter what interface or in which direction they came from.
8  Local process/application (i.e., server/client program)

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)

StepTableChainComment
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.
3mangleOUTPUTThis is where we mangle packets, it is suggested that you do not filter in this chain since it can have side effects. This is also where the locally generated connection tracking takes place, which we discuss in the The state machine chapter.
4natOUTPUTThis chain can be used to NAT outgoing packets from the firewall itself.
5  Routing decision, since the previous mangle and nat changes may have changed how the packet should be routed.
6filterOUTPUTThis is where we filter packets going out from the local host.
7manglePOSTROUTINGThe 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.
8natPOSTROUTINGThis 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.
9  Goes out on some interface (e.g., eth0)
10  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

StepTableChainComment
1  On the wire (i.e., Internet)
2  Comes in on the interface (i.e., eth0)
3manglePREROUTINGThis chain is normally used for mangling packets, i.e., changing TOS and so on. This is also where the non-locally generated connection tracking takes place, which we discuss in the The state machine chapter.
4natPREROUTINGThis chain is used for DNAT mainly. SNAT is done further on. Avoid filtering in this chain since it will be bypassed in certain cases.
5  Routing decision, i.e., is the packet destined for our local host or to be forwarded and where.
6mangleFORWARDThe 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.
7filterFORWARDThe 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.
8manglePOSTROUTINGThis 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.
9natPOSTROUTINGThis 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.
10  Goes out on the outgoing interface (i.e., eth1).
11  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.

 
 
  Published under the terms fo the GNU General Public License Design by Interspire