chains in the same table

chains in the same table

[Jee J.Z.]

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?

Thank you,
Jee

Re: chains in the same table

[Klemen Kecman]

----- Original Message -----
From: "Jee J.Z." <jz105@york.ac.uk>
To: <netfilter@lists.netfilter.org>
Sent: Thursday, May 06, 2004 11:48 AM
Subject: chains in the same table


> 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?
>
> Thank you,
> Jee

I think .. no, it will just accept it. Packet traverses current rules.
Please correct me if I'm wrong.

Re: chains in the same table

[Antony Stone]

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.

Re: chains in the same table

[Jee J.Z.]

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.
>
>
>

Re: chains in the same table

[Antony Stone]

On Thursday 06 May 2004 11:55 pm, Jee J.Z. wrote:

> 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

The three chains are totally independent of each other.

The default policy on INPUT has no bearing whatsoever on how packets will get 
processed by FORWARD (and vice versa, etc...)

>, 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?

PREROUTING happens (as you might guess from the name) before the routing 
decision, and it is the routing decison which determines whether a packet is 
destined for:
a) the local machine, or
b) somewhere else.

If the answer is (a), then the packet goes through the INPUT chain, and does 
not go through the FORWARD chain.

If the answer is (b), then the packet goes through the FORWARD chain, and does 
not go through the INPUT chain.

The thing which determines whether a particular packet goes through INPUT or 
FORWARD is its destination address at the point where it hits the routing 
decision (which is the standard routing mechanism in the Linux kernel, not 
really anything to do with netfilter).   The only way in which netfilter can 
affect this is by changing the destination address in the PREROUTING chain.

Hope this helps?

Regards,

Antony.

-- 
"Note: Windows 98, Windows 98SE and Windows 95 are not affected by [MS
Blaster].   However, these products are no longer supported.   Users of these
products are strongly encouraged to upgrade to later versions."

(which *are* affected by MS Blaster...)

http://www.microsoft.com/security/security_bulletins/ms03-026.asp

                                                     Please reply to the list;
                                                           please don't CC me.

Re: chains in the same table

[Jee J.Z.]

Hi Daniel, Antony and Dick,

You are quite right. I got things wrong and I understand now. Thank you for
your explainations.

Regards,
Jee

> Jee J.Z. writes:
> > 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?
>
> You have the order wrong.  Of the tables you add rules to, your packet
> hits the nat PREROUTING chain first.  In that chain your packet to PC2
> gets DNAT'd to 192.168.0.2 and is then no longer a packet to PC2, so
> routing sends it to the FORWARD chain.
>
> A way to help avoid mistakes is to fill tables in the order in which
> packets see them:
>
> iptables -t nat -A PREROUTING -i eth0 -j DNAT --to 192.168.0.2
> (routing happens here)
> iptables -I FORWARD -j QUEUE
> iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to global_ip_2
>
> These rules unconditionally DNAT all packets to 192.168.0.2, so they
> all go to the FORWARD chain and your QUEUE.  You can avoid having
> packets sent to PC2 from reaching your QUEUE simply by selecting
> against them in your DNAT rule:
>
> iptables -t nat -A PREROUTING -i eth0 ! -d global_ip_2 -j DNAT --to
192.168.0.2
>
> Then packets to PC2 will remain packets to PC2 and routing will send
> them to the INPUT chain rather than the FORWARD chain.
>
> --
> Dick St.Peters, stpeters@NetHeaven.com
>

Re: chains in the same table

[Frank Gruellich]

* Jee J.Z. <jz105@york.ac.uk>  6. May 04:
> Hi all,

Hello,

> 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?

No.  Any packets will traverse exactly one of INPUT, OUTPUT or FORWARD,
indepentent of policies.

HTH,
 regards, Frank.
-- 
Sigmentation fault

RE: chains in the same table

[Daniel Chemko]

Jee J.Z. wrote:
> 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?
> 

When sending a packet from Machine A to Machine B through Machine C, the
following rules apply:

Machine A
OUTPUT
POSTROUTING

Machine B
PREROUTING
INPUT

Machine C
PREROUTING
FORWARD
POSTROUTING

Note: Each table inside each chain is traversed. So, in the first
example, the Machine A would really look like this:

Machine A
Application
OUTPUT mangle
OUTPUT filter
OUTPUT nat
OUTPUT raw
Routing Decision
POSTROUTING
Routing Decision (if needed)

> 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.