From: "Jee J.Z." <jz105@york.ac.uk>
To: netfilter@lists.netfilter.org
Subject: Re: chains in the same table
Date: Thu, 6 May 2004 23:55:30 +0100 [thread overview]
Message-ID: <006001c433bd$3b278de0$68892090@grouse> (raw)
In-Reply-To: 200405061147.35201.Antony@Soft-Solutions.co.uk
Hi Antony, Amit, Frank, and Klemen,
Thank you all for your replies. Your answer actually is what I was expected.
However, I did an experiment which seems to show it is not the case, and
therefore I got confused.
My network structure is as follows:
PC1
(eth0:global_ip_1)
|
|
(eth0:global_ip_2)
PC2
(eth1:192.168.0.1)
|
|
(eth1:192.168.0.2)
PC3
I put the following rules on the PC2:
iptables -F
iptables -F -t nat
iptables -I FORWARD -j QUEUE
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to global_ip_2
iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 192.168.0.2
echo '1' >/proc/sys/net/ipv4/ip_forward
Since I didn't put in the rules like "iptables -P INPUT DROP" and
"iptables -P OUTPUT DROP", I expect traffics that addressed to PC2 will not
be passed on to the FORWARD chain, and therefore they will not be queued to
userspace. However, it seems not the case. When I ftp or ping from PC1 to
PC2 (addressed to PC2), all the packets are queued to userspace and if
accepted from userspace are then DNATed to PC3. Could you explain this to
me? Or am I missing something obvious?
Cheers,
Jee
> On Thursday 06 May 2004 10:48 am, Jee J.Z. wrote:
>
> > Hi all,
> >
> > I'm asking a basic question that in the same table (for example, the
filter
> > table), if a packet hit the INPUT chain while no rules are in the INPUT
> > chain and the default policy is ACCEPT, will the packet be passed on to
the
> > FORWARD chain? If accepted again, be passed on to the OUTPUT chain?
>
> Any single packet only traverses one of the above chains.
>
> If it's addressed *to* the machine, it goes through INPUT only.
>
> If it's addressed *from* the machine, it goes through OUTPUT only.
>
> If it's going *from* somewhere else *to* somewhere else (ie: being
routed), it
> goes through FORWARD only.
>
> (I guess there's an exception that loopback packets will go through both
> OUTPUT and INPUT, but that's unusual.)
>
> Regards,
>
> Antony.
>
> --
> Ramdisk is not an installation procedure.
>
> Please reply to the
list;
> please don't CC
me.
>
>
>
next prev parent reply other threads:[~2004-05-06 22:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-06 9:48 chains in the same table Jee J.Z.
2004-05-06 10:22 ` Klemen Kecman
2004-05-06 10:47 ` Antony Stone
2004-05-06 22:55 ` Jee J.Z. [this message]
2004-05-06 23:07 ` Antony Stone
[not found] ` <16539.37073.149335.706385@saint.heaven.net>
2004-05-07 14:01 ` Jee J.Z.
2004-05-06 10:50 ` Frank Gruellich
-- strict thread matches above, loose matches on Subject: below --
2004-05-06 23:10 Daniel Chemko
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='006001c433bd$3b278de0$68892090@grouse' \
--to=jz105@york.ac.uk \
--cc=netfilter@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.