Re: lifecycle of a packet

[Joel Newkirk <netfilter@newkirk.us>]

On Thursday 09 January 2003 05:54 pm, Tony Clayton wrote:
> I've been reading the various docs linked to from netfilter.org,
> hoping to figure out the exact order in which a packet traverses the
> various tables and chains as it passes through the network stack.
>
> Unfortunately, I couldn't find a definative resource that contained
> this information, so I decided to figure it out myself.

Oskar's tutorial at http://iptables-tutorial.frozentux.net covers it 
pretty nicely, although his main diagrams and tables don't clarify the 
single-hit nature of the NAT chains.  (he covers this elsewhere)

> I build a quick script to insert LOG rules into every chain of every
> table, so that I could log the order in which the tables and chains
> are traversed.

That's the best solution anyway.  Until you do it yourself you can't 
/really/ know it, and IIRC some earlier versions traversals were 
slightly different.  (All through my childhood my mom had a sign in one 
room "I hear and I forget, I see and I remember, I do and I understand" 
which seems pretty accurate usually :^)

> Here are my findings, using the three test cases below:

[snipped]

> This is quite interesting, and not at all what I was expecting based
> on what I'd read.

One you missed, which threw me when I first discovered it:  Firewall box 
to itself.  This one bypasses nat PREROUTING entirely...  I guess since 
it's inbound on interface lo then there is only one rational destination 
anyway, so that chain would be pretty much useless.  If you want to DNAT 
a localhost connection you do it in nat OUTPUT.

> I have a list of questions about this behaviour, keeping in mind that
> I'm fairly new to iptables/netfilter:
>
> 1. Why does only the first packet for a TCP/IP connection seem to pass
> through the nat table?  Does connection tracking take over if the
> packet is (ESTABLISHED,RELATED) and work some magic under the covers?

Precisely, plus some.  Even if you don't have an 'EST/REL' rule, 
conntrack's still there under the hood.  (check "lsmod | grep ip" and 
you'll see that ip_conntrack is a dependancy for iptable_nat)  This is 
how netfilter knows that return traffic IS return traffic, and what IP 
to forward it back to when unSNATting packets.

> 2. Why do both OUTPUT and POSTROUTING chains get traversed for packets
> that the firewall sends out?  Is this useful at all?

As an example, you can DNAT in nat OUTPUT, (but not POSTROUTING - the 
routing decision has already been made) to allow you to change 
destination without the local process knowing or needing to know.  You 
can SNAT in nat POSTROUTING but not OUTPUT.  You can change TTL in 
mangle POSTROUTING for all packets, whether OUTPUT or FORWARD fed them 
in, so that for example they are all the same, (a few ISP's apparently 
look for differing TTL's when policing for 'hidden' machines that they 
want to charge connection fees for) and you can change TOS or mark in 
mangle OUTPUT so that routing can be based on those, which again has 
already been decided before the packet reaches any POSTROUTING chains.

> 3. Most of the documents I looked at were fairly old.  Is there a
> somewhat recent document that perhaps might benefit from including
> these tests?

Oskar Andreasson's tutorial is updated and tweaked frequently, I believe 
he announced the latest update on this list Dec 19.  The only references 
I've EVER used for iptables are his tutorial and the main documentation.  
He also recommends setting up log rules the way you did to double-check 
that traversal works the way you believe it does.

> thanks,
>
> Tony

j