connection tracking query

connection tracking query

[dhiraj.2.bhuyan]

1. I was reading the Iptables tutorial by Oskar Andreasson
http://iptables-tutorial.frozentux.net/iptables-tutorial.html.
It says that connection tracking in done in the PREROUTING chain or OUTPUT
chain (for locally generated packets). If connection tracking is done only
at these two chains, what happens to the packets that don't belong to an
already established connection? I understand that it will have to go through
the filter rules - before the state table is updated for a NEW/RELATED
connection. If that is the case, "conntrack" must be taking place at other
chains too (where the filter is applied). The following document
http://www.knowplace.org/netfilter/syntax.html does infact say that
"conntrack" is happening not only in the PREROUTING and the OUTPUT chain,
but also in INPUT and POSTROUTING chain. What I find strange with this is
that for a packet that goes through the "FORWARD" chain, "conntrack" is done
twice on the same packet - first in the "PREROUTING" chain and second in the
"POSTROUTING" chain. Does anyone have any explanation for this?


2. If a packet is found to belong to an already ESTABLISHED connection, does
it still have to go through the filter rules again?


Thanks,
dhiraj

Re: connection tracking query

[Oskar Andreasson]

Hi Dhiraj,

Since I wrote it.. I may as well answer it as well;). 

What I (think) I actually wrote, is this. At the PREROUTING chain all of
the actual state changes and state calculations are done. This
"material" can then be used to match packets based on their states, but
the actual states have already been calculated properly before the
PREROUTING chain already.

The actual work surrounding the connection tracking, is hence done
before the PREROUTING chain, so that we have the ability to do stateful
matching.

Hmmm.. I hope you understand what I am saying, this explanation got more
complex than the actual process is=).

As for your second question, yes, the packet _must_ go through the
filter table again. The only tables skipped, if the packet is considered
not NEW, is the nat and mangle table. 

//Oskar Andreasson

On Mon, 2003-04-07 at 11:02, dhiraj.2.bhuyan@bt.com wrote:
> 1. I was reading the Iptables tutorial by Oskar Andreasson
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html.
> It says that connection tracking in done in the PREROUTING chain or OUTPUT
> chain (for locally generated packets). If connection tracking is done only
> at these two chains, what happens to the packets that don't belong to an
> already established connection? I understand that it will have to go through
> the filter rules - before the state table is updated for a NEW/RELATED
> connection. If that is the case, "conntrack" must be taking place at other
> chains too (where the filter is applied). The following document
> http://www.knowplace.org/netfilter/syntax.html does infact say that
> "conntrack" is happening not only in the PREROUTING and the OUTPUT chain,
> but also in INPUT and POSTROUTING chain. What I find strange with this is
> that for a packet that goes through the "FORWARD" chain, "conntrack" is done
> twice on the same packet - first in the "PREROUTING" chain and second in the
> "POSTROUTING" chain. Does anyone have any explanation for this?
> 
> 
> 2. If a packet is found to belong to an already ESTABLISHED connection, does
> it still have to go through the filter rules again?
> 
> 
> Thanks,
> dhiraj
> 
> 

Re: connection tracking query

[Vincent Lim]

On Mon, 2003-04-07 at 17:02, dhiraj.2.bhuyan@bt.com wrote:

<snip rest>

> but also in INPUT and POSTROUTING chain. What I find strange with this is
> that for a packet that goes through the "FORWARD" chain, "conntrack" is done
> twice on the same packet - first in the "PREROUTING" chain and second in the
> "POSTROUTING" chain. Does anyone have any explanation for this?

I think the first packet goes thru POSTROUTING, subsequent packets
(after their routes determined) goes straight to FORWARD.
> 
> 2. If a packet is found to belong to an already ESTABLISHED connection, does
> it still have to go through the filter rules again?

I would think so. You need to explicitly have "-m state --state
ESTABLISHED, RELATED -j ACCEPT" to process those packets.

My $0.02
*awaits flame galore*
-- 
Vincent Lim <vincent.lim@nestac.com>
NESTAC Solution Sdn Bhd

Re: connection tracking query

[Cedric Blancher]

Le lun 07/04/2003 à 11:02, dhiraj.2.bhuyan@bt.com a écrit :
> 1. I was reading the Iptables tutorial by Oskar Andreasson
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html.
> It says that connection tracking in done in the PREROUTING chain or
> OUTPUT chain (for locally generated packets). If connection tracking
> is done only at these two chains, what happens to the packets that
> don't belong to an already established connection? I understand that
> it will have to go through the filter rules - before the state table
> is updated for a NEW/RELATED connection. If that is the case,
> "conntrack" must be taking place at other chains too (where the filter
> is applied). The following document
> http://www.knowplace.org/netfilter/syntax.html does infact say that
> "conntrack" is happening not only in the PREROUTING and the OUTPUT
> chain, but also in INPUT and POSTROUTING chain. What I find strange
> with this is that for a packet that goes through the "FORWARD" chain,
> "conntrack" is done twice on the same packet - first in the
> "PREROUTING" chain and second in the "POSTROUTING" chain. Does anyone
> have any explanation for this?

You're mixing two things :

        1. conntrack engine
        2. state matching

Conntrack engine is a module which is designed to recognize if a given
packet belongs or not to an existing connection, and update connection
table according to its decisions.

State matching is the ability for a rule to match a packet state,
understand the way it has been recognized by conntrack engine.

Conntrack engine has to examine packets very early. That's why it occurs
in PREROUTING for recieved packets and OUTPUT for locally generated
packets. In fact, you can see conntrack as a particular table which is
hooked on NF_IP_PRE_ROUTING and NF_IP_LOCAL_OUT with maximum precedence
(it is to be noted that conntrack also occurs on POSTROUTING and INPUT
for new connections validation, avoiding creation of connection that
would be droped by filter table).

So, once our packet is recognised, it is "flaged" with a state that can
be matched in rules with state match. and for conntrack has precedence
over any table, you can match state wherever you want to.

> 2. If a packet is found to belong to an already ESTABLISHED
> connection, does it still have to go through the filter rules again?

Yes it does. State is just a flag. It does not imply anything on packet
filtering, unless you explicitly specify decisions into your ruleset.

-- 
Cédric Blancher  <blancher@cartel-securite.fr>
IT systems and networks security - Cartel Sécurité
Phone : +33 (0)1 44 06 97 87 - Fax: +33 (0)1 44 06 97 99
PGP KeyID:157E98EE  FingerPrint:FA62226DA9E72FA8AECAA240008B480E157E98EE