The big Picture of all the tables ...

The big Picture of all the tables ...

[Robert de Bath]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 708 bytes --]

Hi all,

I _think_ the attached picture shows all the predefined chains in all
the tables that the kernel uses in the order that it uses them (except
for the raw table).

1) Is anything wrong?
2) Where does the raw table fit?
3) What happens if you use NOTRACK.
4) Is there anything else that can make a packet deviate (cf: DROP)

This seems the best place to get a real answer. There are lots of answers 
on google, but they all seem to be partial or even (occasionally) wrong. :-(

Even the netfilter website doesn't seem to have a BIG picture ... does it?

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                              <http://www.debath.co.uk/>

[-- Attachment #2: Type: IMAGE/PNG, Size: 8859 bytes --]

Re: The big Picture of all the tables ...

[Jonas Berlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Robert de Bath on 2005-06-04 18:10 UTC:

> I _think_ the attached picture shows all the predefined chains in all
> the tables that the kernel uses in the order that it uses them (except
> for the raw table).
> 
> 1) Is anything wrong?
> 2) Where does the raw table fit?
> 3) What happens if you use NOTRACK.
> 4) Is there anything else that can make a packet deviate (cf: DROP)

You might be interested in a picture I drew, with some help of Steven
Van Acker:

http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png

> This seems the best place to get a real answer. There are lots of
> answers on google, but they all seem to be partial or even
> (occasionally) wrong. :-(

Yeah, this is the place :)

> Even the netfilter website doesn't seem to have a BIG picture ... does it?

No.. but I usually paste my picture to people on #netfilter on freenode
ircnet. :)

I agree some picture should be on the netfilter page for reference..

- --
- - xkr47
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCohQVxyF48ZTvn+4RAugeAJ9S2u5aNhglz0n1NzB0/mZSgJN8TgCfWVX7
NlNHJGT07tv5Nf56swNHX9Q=
=G7mB
-----END PGP SIGNATURE-----

Re: The big Picture of all the tables ...

[Jonas Berlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Robert de Bath on 2005-06-04 18:10 UTC:

Oops, forgot to answer a few questions :)

> 3) What happens if you use NOTRACK.

If you look at my pic, NOTRACK makes the packet skip all the green boxes.

> 4) Is there anything else that can make a packet deviate (cf: DROP)

Well there is QUEUE but I guess it continues from where it left off..
I'm not really sure.

- --
- - xkr47
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCohi2xyF48ZTvn+4RAss4AJ0VTdRgawFQaxWfcGKU1fJ3ylhjsgCffOBr
LQNhu3f7ZWgfRDlUHCWR470=
=pn7z
-----END PGP SIGNATURE-----

Re: The big Picture of all the tables ...

[Matthew Strait]

> You might be interested in a picture I drew, with some help of Steven
> Van Acker:
>
> http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png
>
>> This seems the best place to get a real answer. There are lots of
>> answers on google, but they all seem to be partial or even
>> (occasionally) wrong. :-(

There's also http://l7-filter.sourceforge.net/PacketFlow.png .  (It's on 
my website, but I didn't make it.  Credit goes to josh@imagestream.com, 
but it doesn't seem to be on that site anymore, which is why I posted it 
on mine.)

-matthew

Re: The big Picture of all the tables ...

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

Do any othem include the ipsec paths,  I believe packets get re in
jected into the begining once they are un ecapsulated

A

On Sat, Jun 04, 2005 at 09:10:16PM +0000, Jonas Berlin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Quoting Robert de Bath on 2005-06-04 18:10 UTC:
> 
> Oops, forgot to answer a few questions :)
> 
> > 3) What happens if you use NOTRACK.
> 
> If you look at my pic, NOTRACK makes the packet skip all the green boxes.
> 
> > 4) Is there anything else that can make a packet deviate (cf: DROP)
> 
> Well there is QUEUE but I guess it continues from where it left off..
> I'm not really sure.
> 
> - --
> - - xkr47
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFCohi2xyF48ZTvn+4RAss4AJ0VTdRgawFQaxWfcGKU1fJ3ylhjsgCffOBr
> LQNhu3f7ZWgfRDlUHCWR470=
> =pn7z
> -----END PGP SIGNATURE-----
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: The big Picture of all the tables ...

[Robert de Bath]

On Sat, 4 Jun 2005, Jonas Berlin wrote:

> Quoting Robert de Bath on 2005-06-04 18:10 UTC:
>
>> I _think_ the attached picture shows all the predefined chains in all
>> the tables that the kernel uses in the order that it uses them (except
>> for the raw table).
>
> You might be interested in a picture I drew, with some help of Steven
> Van Acker:
>
> http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png
Yes, that's exactly it.

>> Even the netfilter website doesn't seem to have a BIG picture ... does it?
>
> No.. but I usually paste my picture to people on #netfilter on freenode
> ircnet. :)
>
> I agree some picture should be on the netfilter page for reference..

On Sat, 4 Jun 2005, Jonas Berlin wrote:

>> 3) What happens if you use NOTRACK.
>
> If you look at my pic, NOTRACK makes the packet skip all the green boxes.
But what about the pink boxes (NAT), they can't do anything without
connection tracking but do they try?

>> 4) Is there anything else that can make a packet deviate (cf: DROP)
>
> Well there is QUEUE but I guess it continues from where it left off..
> I'm not really sure.

Hmmm, QUEUE ... :-/

-- 
Rob.                          (Robert de Bath <robert$ @ debath.co.uk>)
                                              <http://www.debath.co.uk/>

Re: The big Picture of all the tables ...

[Jonas Berlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Robert de Bath on 2005-06-04 21:49 UTC:
>>> 3) What happens if you use NOTRACK.
>>
>> If you look at my pic, NOTRACK makes the packet skip all the green boxes.
> 
> But what about the pink boxes (NAT), they can't do anything without
> connection tracking but do they try?

Yeah, I'm 99% sure nat isn't traversed either, nat afaik requires
connection tracking..

>>> 4) Is there anything else that can make a packet deviate (cf: DROP)
>>
>> Well there is QUEUE but I guess it continues from where it left off..
>> I'm not really sure.
> 
> Hmmm, QUEUE ... :-/

I mean

  iptables ... -j QUEUE

I don't know where in the chain it should/can go..

- --
- - xkr47
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCoicBxyF48ZTvn+4RAvE2AKDmyW8VVf1rwtgwAcP7lC2Z/9u9YQCfZJm7
ySFngQVolJnutrFFFln4IzE=
=q2uT
-----END PGP SIGNATURE-----

Re: The big Picture of all the tables ...

[Jørn Andre]

Jonas Berlin wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Quoting Robert de Bath on 2005-06-04 21:49 UTC:
>  
>
>>>>3) What happens if you use NOTRACK.
>>>>        
>>>>
>>>If you look at my pic, NOTRACK makes the packet skip all the green boxes.
>>>      
>>>
>>But what about the pink boxes (NAT), they can't do anything without
>>connection tracking but do they try?
>>    
>>
>
>Yeah, I'm 99% sure nat isn't traversed either, nat afaik requires
>connection tracking..
>
>  
>
>>>>4) Is there anything else that can make a packet deviate (cf: DROP)
>>>>        
>>>>
>>>Well there is QUEUE but I guess it continues from where it left off..
>>>I'm not really sure.
>>>      
>>>
>>Hmmm, QUEUE ... :-/
>>    
>>
>
>I mean
>
>  iptables ... -j QUEUE
>
>I don't know where in the chain it should/can go..
>  
>
I've made an app that uses -j QUEUE and inserted the rule into mangle 
PREROUTING on one host and OUTPUT on another.
This is to change destination on a packet to make sure all packets are 
routed between them.
The conntrack module is hooked into PREROUTING and OUTPUT also, but with a
high priority (-200, see <linux/netfilter_ipv4.h>) such that every 
user-inserted  rule with iptables get below it, i.e -j QUEUE -t mangle
This means packet mangling (in case src/dst IP change) wont be noticed 
by conntrack and will not work. I have made my own NAT'ing
for now, but the best solution would be an integration to the existing 
conntrack. If anyone has a suggestion....

With QUEUE you can accept/drop/change packets. QUEUE is able to be 
inserted into any chain it seems.

Picture of the iptables flow? Take a look at  
https://lists.netfilter.org/pipermail/netfilter/2004-March/051131.html
[ googling: iptables flow chart]

>- --
>- - xkr47
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>
>iD8DBQFCoicBxyF48ZTvn+4RAvE2AKDmyW8VVf1rwtgwAcP7lC2Z/9u9YQCfZJm7
>ySFngQVolJnutrFFFln4IzE=
>=q2uT
>-----END PGP SIGNATURE-----
>  
>

Re: The big Picture of all the tables ...

[Henrik Nordstrom]

On Sat, 4 Jun 2005, Jonas Berlin wrote:

> I mean
>
>  iptables ... -j QUEUE
>
> I don't know where in the chain it should/can go..

NF_QUEUE (aka -j QUEUE in iptables) can be returned by any netfilter 
hook handler, and terminates that handler/table.

When the packet returns from the queue it continues at the next 
handler/table in the same hook or leaves the hook as usual if there is no 
more to process in this hook.

Note: this is not limited to iptables. The above applies to any netfilter 
modules as QUEUE is a core netfilter function, not an iptables function.

Regards
Henrik

Re: The big Picture of all the tables ...

[Cedric de Launois]

Le samedi 04 juin 2005 à 19:10 +0100, Robert de Bath a écrit :
> Hi all,
> 
> I _think_ the attached picture shows all the predefined chains in all
> the tables that the kernel uses in the order that it uses them (except
> for the raw table).

> 4) Is there anything else that can make a packet deviate (cf: DROP)

The ROUTE target (in pom) was initially designed to directly send a
packet on the wire, on a given interface. In such case, the target is
put on the mangle PREROUTING chain, and the packet that matches the
ROUTE target is re-injected _after_ the mangle POSTROUTING chain (so
that conntrack is not confused by strangely routed packets).

If the --continue option of the ROUTE target is used, then the packet is
routed by the target, and continues its journey through the rules. In
your figure, it should now become obvious to beginners why the use of
the --continue option is most useful in mangle POSTROUTING, and useless
on the PREROUTING chain...

Cedric

Re: The big Picture of all the tables ...

[Andy Furniss]

Jonas Berlin wrote:

> You might be interested in a picture I drew, with some help of Steven
> Van Acker:
> 
> http://xkr47.outerspace.dyndns.org/netfilter/packet_flow/packet_flow9.png

AIUI on recent kernels the Qos ingress box is only after PREROUTING if 
the kernel option packet action (CONFIG_NET_CLS_ACT) is not selected - 
if it is selected then ingress policers are before PREROUTING.

Andy.