Re: How do you correctly interpret the FORWARD chain interface options?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Richard,

Thanks for clearing that up.


2010/2/9 Покотиленко Костик <casper@xxxxxxxxxxxx>:
> В Вто, 09/02/2010 в 15:50 +0000, paddy joesoap пишет:
>> On Tue, Feb 9, 2010 at 3:23 PM, paddy joesoap <paddyjoesoap@xxxxxxxxx> wrote:
>> > On Tue, Feb 9, 2010 at 1:25 PM, Richard Horton <arimus.uk@xxxxxxxxxxxxxx> wrote:
>> >> On 9 February 2010 13:17, paddy joesoap <paddyjoesoap@xxxxxxxxx> wrote:
>> >>> Hi All,
>> >>>
>> >>> How should one interpret the inbound ("-i") and outbound ("-o") of the
>> >>> FORWARD chain.
>> >>>
>> >>
>> >>
>> >> -i refers to the interface the packet is received on.
>> >> -o refers to the interface the packet is routed out on.
>> >>
>> >>
>> >
>>
>> Ignore last email (spotted an error in the example rules).
>>
>> I think I get what Richard is saying now.
>>
>> The following two rules-set are equivalent, it just depends where you
>> decide to filter.
>>
>> Am I correct?
>>

Thanks Richard. I'm slow to catch on ;-)

This leads me to a new question about how the default policy is executed.

Lets suppose I only examine the inbound "-i" option, that is, allow
inbound external-traffic and allow inbound internal-traffic.
 # Client Request
iptables -A FORWARD -i eth0 -p tcp -s 0/0 -d webServIP --dport 80 -j ACCEPT
# Server Response
iptables -A FORWARD -i eth1 -p tcp -s webServIP --sport 80 -d 0/0 -j ACCEPT

Presumably since the default FORWARD policy is DROP and because I have
not *explicitly* defined what should happen in the "-o" of both, then
packets will be dropped. That is, FORWARD rules always require a
counterpart for bi-directional communication.

So would it be wise to write a generic outbound "-o" rules that trusts
how the firewall treats outbound traffic in all cases.

iptables -A FORWARD -o eth0 -j ACCEPT
iptables -A FORWARD -o eth1 -j ACCEPT

Then I only have to focus on one direction regarding the FORWARD
rule-set. Its just a way of reducing the number of rules I would have
to read or analyse. Perhaps this is a ridiculous thing to do!



>>  iptables -A FORWARD -i eth0 -p tcp -s 0/0 -d webServIP --dport 80 -j ACCEPT
>>  iptables -A FORWARD -o eth0 -p tcp -s webServIP --sport 80 -d 0/0 -j ACCEPT
>>
>>  iptables -A FORWARD -o eth1 -p tcp -s 0/0 -d webServIP --dport 80 -j ACCEPT
>>  iptables -A FORWARD -i eth1 -p tcp -s webServIP --sport 80 -d 0/0 -j ACCEPT
>>
>> In some sense writing the 4 rules leads to duplication, in that,
>> applying just two will suffice.
>
> This is correct.
>
>> > Does this mean that both versions below are equivalent or at least do
>> > the same job?
>> >
>> > (1)
>> >
>> > iptables -A FORWARD -i eth0 -p tcp -d webServIP -j ACCEPT
>> > iptables -A FORWARD -o eth1 -p tcp -s webServIP -j ACCEPT
>> >
>> > Because a packet will enter eth0 for internal network and a packet
>> > will leave eth1 (pushed towards eth0).
>> >
>> > (2)
>> >
>> > iptables -A FORWARD -i eth0 -p tcp -d webServIP -j ACCEPT
>> > iptables -A FORWARD -o eth0 -p tcp -s webServIP -j ACCEPT
>> >
>> > Because a packet will enter eth0 to be forwarded internally and a
>> > packet will also enter eth0 when leaving the network.
>> >
>> >
>> >>
>> >> --
>> >> Richard Horton
>> >> Users are like a virus: Each causing a thousand tiny crises until the
>> >> host finally dies.
>> >> http://www.solstans.co.uk - Solstans Japanese Bobtails and Norwegian Forest Cats
>> >> http://www.pbase.com/arimus - My online photogallery
>> >>
>> >
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> Покотиленко Костик <casper@xxxxxxxxxxxx>
>
>
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux