lifecycle of a packet

lifecycle of a packet

[Tony Clayton]

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.

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.

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

---
TEST A:
Sending http request from masqueraded client, through firewall, to
external box

Request from client

   1. mangle: PREROUTING
   2. nat: PREROUTING (first packet only)
   3. mangle: FORWARD
   4. filter: FORWARD
   5. mangle: POSTROUTING
   6. nat: POSTROUTING (first packet only)

Reply from external box

   1. mangle: PREROUTING
   2. mangle: FORWARD
   3. filter: FORWARD
   4. mangle: POSTROUTING

TEST B
Sending http request from masqueraded client to firewall

Request from client

   1. mangle: PREROUTING
   2. nat: PREROUTING (first packet only)
   3. mangle: INPUT
   4. filter: INPUT

Reply from firewall

   1. mangle: OUTPUT
   2. filter: OUTPUT
   3. mangle: POSTROUTING

TEST C
Sending http request from firewall to external box:

Request from firewall

   1. mangle: OUTPUT
   2. nat: OUTPUT (first packet only)
   3. filter: OUTPUT
   4. mangle: POSTROUTING
   5. nat: POSTROUTING (first packet only)

Reply from external box

   1. mangle: PREROUTING
   2. mangle: INPUT
   3. filter: INPUT

---

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

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?

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

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?

thanks,

Tony

Re: lifecycle of a packet

[Anders Fugmann]

Tony Clayton wrote:
<lots of info on chain traversal>
> 
> This is quite interesting, and not at all what I was expecting based on
> what I'd read.
Depends on what you read :-)
> 
> 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?
Yes. When you change a packet in the nat table, all following packets 
are nat'ed automatically. This way you do not have to worry about 
natting replys etc.
> 
> 2. Why do both OUTPUT and POSTROUTING chains get traversed for packets
> that the firewall sends out?  Is this useful at all?
Yes. in POSTROUTING you may not know if the pakcet has been generated 
locally or not. However in the mangle-output chain you do. Another usage 
that cannot be done in postrouting is alterations to the packet before 
it hits the filter-output chain. The can e.g be used un conjunktion with 
packet marking:
	iptables -t mangle -a OUTPUT -j MARK --set-mark 0x01
	iptables -t filter -a OUTPUT -m mark --mark 0x01 -j ACCEPT.

(Ok - this example is very simple, but still - its imposible without the 
mangle-output chain)

> 
> 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?
Yes. Take a look at Oskar Andreasson's excellent tutorial at:
http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html
Esp. look at the section named: "Traversing of tables and chains"

Hope it helps.
Anders Fugmann

--
Author of FIAIF
FIAIF is an intelligent firewall
http://fiaif.fugmann.dhs.org

Re: lifecycle of a packet

[Joel Newkirk]

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

Re: lifecycle of a packet

[Oskar Andreasson]

On Fri, 10 Jan 2003, Anders Fugmann wrote:

> > 
> > 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?
> Yes. Take a look at Oskar Andreasson's excellent tutorial at:
> http://people.unix-fu.org/andreasson/iptables-tutorial/iptables-tutorial.html
> Esp. look at the section named: "Traversing of tables and chains"

*shudder* that's an old version/site:). However, I have had so many
problems with different hosts the last half year, I am not surprised
people give out those old links. All of that was, hopefully, fixed when I 
moved to my own domain, so here it is:

http://iptables-tutorial.frozentux.net/iptables-tutorial.html

Just to let everyone know:) 

> 
> Hope it helps.
> Anders Fugmann
> 
> --
> Author of FIAIF
> FIAIF is an intelligent firewall
> http://fiaif.fugmann.dhs.org
> 
> 
> 
> 

-- 
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

Re: lifecycle of a packet (OT)

[Anders Fugmann]

Oskar Andreasson wrote:
> *shudder* that's an old version/site:). However, I have had so many
> problems with different hosts the last half year, I am not surprised
> people give out those old links. All of that was, hopefully, fixed when I 
> moved to my own domain, so here it is:
> 
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html

As old version are still spread all over the net, I would suggest that 
you somehow try and get owners of old versions to remove these, or at 
least give link to the original version. I do remember that you made a 
post of the whereabouts of the new tutorial, but thats several hundres 
emails ago.

Btw. Thanks for a great tutorial. Keep up the good work.

Regards
Anders Fugmann

Re: lifecycle of a packet (OT)

[tony]

Quoting Anders Fugmann <afu@fugmann.dhs.org>:
> Btw. Thanks for a great tutorial. Keep up the good work.

Yes, that tutorial really helps, thanks Oskar.  I think it should be
given some sort of "Official" status on the netfilter web site, and they
should definately link to yours instead of hosting an old version.

Just a few suggestions for the tutorial (take 'em or leave 'em ;):

General:
- it would be useful if the guide referred to the versions of
iptables/kernel for which it it is known to be valid

Traversing of tables and chains section:
- the version on netfilter.org is old, doesn't link to the original, and
has broken links (the rc.test-iptables.txt script, for example)
- might benefit from mentioning that EST/REL packets don't traverse the
NAT chain, and why
- as a newbie to iptables and the kernel network stack, I find it
easiest to think in context of an actual connection that I can test.  As
such, it might benefit from using example connections to illustrate,
such as in my original post, ie:
   masq client -> firewall
   masq client -> external
   firewall -> external
   firewall -> firewall  (thanks Joel Newkirk!)


Thanks Oskar, Joel, and Anders!

Re: lifecycle of a packet (OT)

[Tony Clayton]

Quoting Anders Fugmann <afu@fugmann.dhs.org>:
> Btw. Thanks for a great tutorial. Keep up the good work.

Yes, that tutorial really helps, thanks Oskar.  I think it should be
given some sort of "Official" status on the netfilter web site, and they
should definately link to yours instead of hosting an old version.

Just a few suggestions for the tutorial (take 'em or leave 'em ;):

General:
- it would be useful if the guide referred to the versions of
iptables/kernel for which it it is known to be valid

Traversing of tables and chains section:
- the version on netfilter.org is old, doesn't link to the original, and
has broken links (the rc.test-iptables.txt script, for example)
- might benefit from mentioning that EST/REL packets don't traverse the
NAT chain, and why
- as a newbie to iptables and the kernel network stack, I find it
easiest to think in context of an actual connection that I can test.  As
such, it might benefit from using example connections to illustrate,
such as in my original post, ie:
   masq client -> firewall
   masq client -> external
   firewall -> external
   firewall -> firewall  (thanks Joel Newkirk!)


Thanks Oskar, Joel, and Anders!

Re: lifecycle of a packet (OT)

[Oskar Andreasson]

Hi Anders,

Sorry for rather late reply... I'm still trying to catch up to all of 
these damn mails unfortunately. I will try to be a little bit more 
responsive in the future.

On Fri, 10 Jan 2003, Anders Fugmann wrote:

> Oskar Andreasson wrote:
> > *shudder* that's an old version/site:). However, I have had so many
> > problems with different hosts the last half year, I am not surprised
> > people give out those old links. All of that was, hopefully, fixed when I 
> > moved to my own domain, so here it is:
> > 
> > http://iptables-tutorial.frozentux.net/iptables-tutorial.html
> 
> As old version are still spread all over the net, I would suggest that 
> you somehow try and get owners of old versions to remove these, or at 
> least give link to the original version. I do remember that you made a 
> post of the whereabouts of the new tutorial, but thats several hundres 
> emails ago.

Definitely agreed, the only problem is that some people just throw the 
tutorial up on a page, and don't tell me about it. And others again simply 
ignore it when I try to contact them. For example, I've tried making 
netfilter.org changing their links for the last 3-4 months without any 
replies. It's very unfortunate:/. 

I will make a little bit of an effort right now to make people provide 
links to the "official" site straight away though, we'll see what they 
say.

> 
> Btw. Thanks for a great tutorial. Keep up the good work.

Ah.. no problem really, just trying to do my part for the greater good:)

> 
> Regards
> Anders Fugmann
> 
> 
> 

-- 
----
Oskar Andreasson
http://www.frozentux.net
http://iptables-tutorial.frozentux.net
http://ipsysctl-tutorial.frozentux.net
mailto:blueflux@koffein.net

Re: lifecycle of a packet (OT)

[Kevin McConnell]

--- Oskar Andreasson <blueflux@koffein.net> wrote:
 
> Definitely agreed, the only problem is that some
> people just throw the 
> tutorial up on a page, and don't tell me about it.
> And others again simply 
> ignore it when I try to contact them. For example,
> I've tried making 
> netfilter.org changing their links for the last 3-4
> months without any 
> replies. It's very unfortunate:/. 

How about filing it in bugzilla? Have you tried that
yet?

> Ah.. no problem really, just trying to do my part
> for the greater good:)

Yes, thank you for putting all this stuff into terms
that the rest of us can read.


=====
Kevin C. McConnell --RHCE-- <Red Hat Certified Engineer>

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com