From: "Jørn Andre" <jornandr@stud.ntnu.no>
To: netfilter-devel@lists.netfilter.org
Subject: Re: The big Picture of all the tables ...
Date: Sun, 05 Jun 2005 12:08:16 +0200 [thread overview]
Message-ID: <42A2CF10.2020201@stud.ntnu.no> (raw)
In-Reply-To: <42A22703.5090000@outerspace.dyndns.org>
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-----
>
>
next prev parent reply other threads:[~2005-06-05 10:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-04 18:10 The big Picture of all the tables Robert de Bath
2005-06-04 20:50 ` Jonas Berlin
2005-06-04 21:30 ` Matthew Strait
2005-06-06 21:08 ` Andy Furniss
2005-06-04 21:10 ` Jonas Berlin
2005-06-04 21:47 ` Alexander Samad
2005-06-04 21:49 ` Robert de Bath
2005-06-04 22:11 ` Jonas Berlin
2005-06-05 10:08 ` Jørn Andre [this message]
2005-06-05 21:48 ` Henrik Nordstrom
2005-06-06 8:00 ` Cedric de Launois
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42A2CF10.2020201@stud.ntnu.no \
--to=jornandr@stud.ntnu.no \
--cc=netfilter-devel@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.