Re: How do you correctly interpret the FORWARD chain interface options? From: Покотиленко Костик <casper@meteor.dp.ua> X-Virus-Status: Clean Sender: netfilter-owner@vger.kernel.org X-Mailing-List:

[Mart Frauenlob <mart.frauenlob@chello.at>]

On 09.02.2010 16:58, netfilter-owner@vger.kernel.org wrote:
> В Вто, 09/02/2010 в 15:23 +0000, paddy joesoap пишет:
>> On Tue, Feb 9, 2010 at 1:25 PM, Richard Horton <arimus.uk@googlemail.com> wrote:
>>> On 9 February 2010 13:17, paddy joesoap <paddyjoesoap@gmail.com> 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.
>>>
>>>
>>
>> Does this mean that both versions below are equivalent or at least do
>> the same job?
> 
> Not at all.
> 
>> (1)
>>
>> iptables -A FORWARD -i eth0 -p tcp -d webServIP -j ACCEPT
> 
> This rule will match packets sent from "client" to a webServIP.
> 
>> iptables -A FORWARD -o eth1 -p tcp -s webServIP -j ACCEPT
> 
> Considering that webServIP located in network connected to eth1, this
> rule will not match because packets sent out to eth1 cannot have
> webServIP as source address.
> 
>> 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
> 
> This rule will match packets sent from "client" to a webServIP.
> 
>> iptables -A FORWARD -o eth0 -p tcp -s webServIP -j ACCEPT
> 
> This rule will match packets sent from webServIP to "client".
> 
>> Because a packet will enter eth0 to be forwarded internally and a
>> packet will also enter eth0 when leaving the network.
> 
> When packet enters and leaves one interface (eth0) it isn't actually a
> routing.
> 
> Considering that webServIP located in network connected to eth1 and
> clients talking to the server located in network connected to eth0 you
> can use those rules:
> 
> iptables -A FORWARD -i eth0 -p tcp -d webServIP -j ACCEPT
> iptables -A FORWARD -o eth1 -p tcp -d webServIP -j ACCEPT
> iptables -A FORWARD -i eth0 -o eth1 -p tcp -d webServIP -j ACCEPT
> 
> Those 3 rules will do the same job each, you can use either of them.
> They will match packets sent from "clients" to "server".
> 
> iptables -A FORWARD -i eth1 -p tcp -s webServIP -j ACCEPT
> iptables -A FORWARD -o eth0 -p tcp -s webServIP -j ACCEPT
> iptables -A FORWARD -i eth1 -o eth0 -p tcp -s webServIP -j ACCEPT
> 
> This 3 rules will do the same job each, you can use either of them. They
> will match packets sent from "servers" to "clients".
> 
> As you probaly already know each connection of client to server sends
> packets in both direction regardless of what you are doing, downloading
> or uploading.
> 
> For example if you want to only allow web traffic (port 80) from
> "clients" for "server" you would have to use rules like this:
> 
> iptables -A FORWARD -i eth0 -o eth1 -d webServIP -p tcp --dport 80 -j
> ACCEPT
> iptables -A FORWARD -i eth1 -o eth0 -s webServIP -p tcp --sport 80 -j
> ACCEPT
> 
Hello,

taking the provided scenario (web-server), it's most likely not wise not
to use the features of conntrack. actually if you do not use conntrack
for the webserver, it would be advisable to set those packets to NOTRACK
in the raw table, thus saving system resources.

Now if one decides to use conntrack, place a rule (on top) into the
FORWARD chain allowing established (most likely also RELATED) traffic.

To allow the webserver traffic, all one has to do is, allow state NEW
traffic with destination IP of the web-server.

Now what interface to use within the rule?
Well for a firewall/router with one external and one internal (dmz)
interface, one might specify a match using both interfaces:
-i external_nic -o internal_nic

that will perfectly match the desired packets.
But if the network extends, you may have to rewrite those rules.
i.e. the network now has a second internet upstream provider and another
LAN.

For that case, one would need to duplicate those rules for every interface.

Now if you write your rules like this, they still match the desired
packets, but result in a faster and shorter rule-set:

-P FORWARD DROP
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -o $DMZ_IF -d $WEB_SERVER -m state --state NEW -p tcp --dport
80 -j ACCEPT

No matter from which external or internal interface the request/reply
came, the rules will match in a secure manner.

Best regards

Mart