BarbWire Basics
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. 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 3-1. Forwarded packets
| Step |
Table |
Chain |
Comment |
| 1 |
|
|
On the wire
(i.e., internet) |
| 2 |
|
|
Comes in on
the interface (i.e., eth0) |
| 3 |
mangle |
PREROUTING |
This chain is
normally used for mangling packets, i.e., changing TOS
and so on. |
| 4 |
nat |
PREROUTING |
This chain is
used for Destination Network
Address Translation mainly. Source
Network Address Translation 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
localhost or to be forwarded and where. |
| 6 |
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 ruleset. |
| 7 |
nat |
POSTROUTING |
This chain
should first and foremost be used for Source
Network Address Translation. Avoid doing
filtering here, since certain packets might pass this
chain without ever hitting it. This is also where
Masquerading is done. |
| 8 |
|
|
Goes out on
the outgoing interface (i.e., eth1). |
| 9 |
|
|
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. 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.
Now, let us have a look at a packet that is destined for
our own localhost. It would pass through the following steps
before actually being delivered to our application that receives
it:
Table 3-2. Destination local host (our own machine)
| Step |
Table |
Chain |
Comment |
| 1 |
|
|
On the wire
(e.g., Internet) |
| 2 |
|
|
Comes in on
the interface (e.g., eth0) |
| 3 |
mangle |
PREROUTING |
This chain is
normally used for mangling packets, i.e., changing TOS
and so on. |
| 4 |
nat |
PREROUTING |
This chain is
used for Destination Network
Address Translation 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. |
| 6 |
filter |
INPUT |
This is where
we do filtering for all incoming traffic destined for
our localhost. Note that all incoming packets destined
for this host pass through this chain, no matter what
interface or in which direction they came from. |
| 7 |
|
|
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.
Finally we look at the outgoing packets from our own local
host and what steps they go through.
Table 3-3. Source local host (our own machine)
| Step |
Table |
Chain |
Comment |
| 1 |
|
|
Local
process/application (i.e., server/client program) |
| 2 |
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. |
| 3 |
Nat |
OUTPUT |
This is
currently broken, could someone tell me when this will
be fixed? Please? |
| 4 |
Filter |
OUTPUT |
This is where
we filter packets going out from the local host. |
| 5 |
|
|
Routing
decision. This is where we decide where the packet
should go. |
| 6 |
Nat |
POSTROUTING |
This is where
we do Source Network Address
Translation 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. |
| 7 |
|
|
Goes out on
some interface (e.g., eth0) |
| 8 |
|
|
On the wire
(e.g., Internet) |
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:
|
ontact Details: