Possible IPTables bug in INPUT interface filtering?

Possible IPTables bug in INPUT interface filtering?

[John Engelke]

Hello IPFilter Guru World,

I've encountered some strangeness in filtering on a multihomed Linux
box, CentOS 5, x86_64, 2.6.18-164.15.1.el5, where using the interface
flag (-i) does not work.

So this box has two interfaces on the local subnet, eth0 and eth1. I
would like to restrict VNC to only one of the interfaces, eth1. At the
start, VNC does not work. So I add this:

-A INPUT -i eth1 -p tcp -m multiport --port 5900 -j ACCEPT

Then, VNC starts working on eth0 AND eth1. Since I know the address of
eth1, I then put it in explicitly as:

-A INPUT -i eth1 -p tcp -d 192.168.1.34 -m multiport --port 5900 -j ACCEPT

Amazingly, this works and now VNC traffic is only allowed on eth1
(address 192.168.1.34). So I believe I am concluding correctly that
interface filtering *does not work* for INPUT statements in multihomed
machines. I also wonder if it does not work at all for any interface.

This is with IPTables 1.3.5. It is a real PITA since I have to rewrite
all my rules for specific IPs and then bind my adapters to those IPs.
Any meaninful comments are appreciated, even if I am really off base
here.

Thanks!

-- IngyHere

Re: Possible IPTables bug in INPUT interface filtering?

[Pascal Hambourg]

Hello,

John Engelke a écrit :
> Hello IPFilter Guru World,

This list is about Netfilter, not IPFilter.

> I've encountered some strangeness in filtering on a multihomed Linux
> box, CentOS 5, x86_64, 2.6.18-164.15.1.el5, where using the interface
> flag (-i) does not work.
> 
> So this box has two interfaces on the local subnet, eth0 and eth1.

Are both interfaces connected to the same subnet ? If so, I don't call
this "multihomed".

> I
> would like to restrict VNC to only one of the interfaces, eth1. At the
> start, VNC does not work. So I add this:
> 
> -A INPUT -i eth1 -p tcp -m multiport --port 5900 -j ACCEPT
> 
> Then, VNC starts working on eth0 AND eth1.

Are you sure ? How do you know ?

> Since I know the address of eth1, I then put it in explicitly as:
> 
> -A INPUT -i eth1 -p tcp -d 192.168.1.34 -m multiport --port 5900 -j ACCEPT
> 
> Amazingly, this works and now VNC traffic is only allowed on eth1
> (address 192.168.1.34). So I believe I am concluding correctly that
> interface filtering *does not work* for INPUT statements in multihomed
> machines. I also wonder if it does not work at all for any interface.

It works for lots of people - including myself - who run multihomed
boxes such as routers.

If both interfaces are connected to the same subnet, by default your box
accepts packets destined to any local non-loopback address on any
interface, including packets destined to the address assigned to eth1 on
eth0 and vice versa. This is because Linux enforces the "weak" host model.

Re: Possible IPTables bug in INPUT interface filtering?

[John Engelke]

On Fri, Apr 16, 2010 at 8:23 AM, Pascal Hambourg <pascal.mail@nnnnnn.org> wrote:
> Hello,
>
> John Engelke a écrit :
>> Hello IPFilter Guru World,
>
> This list is about Netfilter, not IPFilter.

Right. Well filters and tables aside this message is about IPTables. I
believe that this is the right list, please correct me if it is not.

>
>> I've encountered some strangeness in filtering on a multihomed Linux
>> box, CentOS 5, x86_64, 2.6.18-164.15.1.el5, where using the interface
>> flag (-i) does not work.
>>
>> So this box has two interfaces on the local subnet, eth0 and eth1.
>
> Are both interfaces connected to the same subnet ? If so, I don't call
> this "multihomed".

According to the link at http://en.wikipedia.org/wiki/Multihoming ,
this setup can be described as "Multiple Interfaces, Single IP address
per interface". So I'm actually trying to limit load on one interface
using IPTables, which is a little different but nonetheless a variant
on the concept.

>
>> I
>> would like to restrict VNC to only one of the interfaces, eth1. At the
>> start, VNC does not work. So I add this:
>>
>> -A INPUT -i eth1 -p tcp -m multiport --port 5900 -j ACCEPT
>>
>> Then, VNC starts working on eth0 AND eth1.
>
> Are you sure ? How do you know ?

Well I know because I added the line to the iptables rules file in
/etc/sysconfig and restarted the service. It didn't work before I
added the line and restarted. I tested both IPs before and after.

>
>> Since I know the address of eth1, I then put it in explicitly as:
>>
>> -A INPUT -i eth1 -p tcp -d 192.168.1.34 -m multiport --port 5900 -j ACCEPT
>>
>> Amazingly, this works and now VNC traffic is only allowed on eth1
>> (address 192.168.1.34). So I believe I am concluding correctly that
>> interface filtering *does not work* for INPUT statements in multihomed
>> machines. I also wonder if it does not work at all for any interface.
>
> It works for lots of people - including myself - who run multihomed
> boxes such as routers.

So are you stating that without providing the IP address that you are
able to filter solely on the interface name (i.e. -i eth0 or -i eth1)?
I bet there is something else different like subnet addressing, but I
really don't think that should matter, anyway.

>
> If both interfaces are connected to the same subnet, by default your box
> accepts packets destined to any local non-loopback address on any
> interface, including packets destined to the address assigned to eth1 on
> eth0 and vice versa. This is because Linux enforces the "weak" host model.

Okay, fine. But I don't see anything in either the man pages for
IPTables nor in the examples linked from netfilter.org to indicate
this. If the '-i' interface flag only works under certain conditions
the documentation ought to state those conditions. I RTFM for this
one. Bottom line is interface filtering doesn't really work when it
requires IP/subnet parameters too. Bug or not it's unexpected
behavior.

Re: Possible IPTables bug in INPUT interface filtering?

[Pascal Hambourg]

John Engelke a écrit :
>>
>>> So this box has two interfaces on the local subnet, eth0 and eth1.
>> Are both interfaces connected to the same subnet ? If so, I don't call
>> this "multihomed".
> 
> According to the link at http://en.wikipedia.org/wiki/Multihoming ,
> this setup can be described as "Multiple Interfaces, Single IP address
> per interface". So I'm actually trying to limit load on one interface
> using IPTables, which is a little different but nonetheless a variant
> on the concept.

You did not clearly answer my question : are both interfaces connected
to the same subnet ? Please detail your network setup.

>>> I would like to restrict VNC to only one of the interfaces, eth1. At
>>> the start, VNC does not work. So I add this:
>>>
>>> -A INPUT -i eth1 -p tcp -m multiport --port 5900 -j ACCEPT
>>>
>>> Then, VNC starts working on eth0 AND eth1.
>> Are you sure ? How do you know ?
> 
> Well I know because I added the line to the iptables rules file in
> /etc/sysconfig and restarted the service. It didn't work before I
> added the line and restarted. I tested both IPs before and after.

This is not proof. As I wrote, either IP address may be used on either
interface. Proof would be some packet capture or iptables log on eth0.

> So are you stating that without providing the IP address that you are
> able to filter solely on the interface name (i.e. -i eth0 or -i eth1)?

Yes, if I want to filter only on the interface. Again, when doing so any
(non loopback) address assigned to any interface is reachable through
that interface, not only the specific address assigned to it.

>> If both interfaces are connected to the same subnet, by default your box
>> accepts packets destined to any local non-loopback address on any
>> interface, including packets destined to the address assigned to eth1 on
>> eth0 and vice versa. This is because Linux enforces the "weak" host model.
> 
> Okay, fine. But I don't see anything in either the man pages for
> IPTables nor in the examples linked from netfilter.org to indicate
> this. If the '-i' interface flag only works under certain conditions
> the documentation ought to state those conditions. I RTFM for this
> one.

I don't see why this needs to be indicated there. This is not related to
netfilter or iptables.

> Bottom line is interface filtering doesn't really work when it
> requires IP/subnet parameters too. Bug or not it's unexpected
> behavior.

It is just unexpected to you because packets don't flow the way you
think. Packets for a given address may arrive on any interface.
Addresses and interfaces are mostly independent.

Re: Possible IPTables bug in INPUT interface filtering?

[Narendra Choyal]

Hello,

  I am new in iptables but I know well about it.

I my suggenstion,

Here,

x.x.x.10 <== eth0
x.x.x.20 <== eth1   <---> If we want to deny/restrict this ethernet card.


#iptables -I INPUT -p tcp --dport 5900 -d x.x.x.20 -j DROP
#iptables -I OUTPUT -p tcp --sport 5900 -s x.x.x.20 j DROP

*** Default Policies of INPUT and OUTPUT must be ACCEPT

NOTE :
-i also not work when we have two virtual IPs like eth0 and eth0:1 .
In this case first rule will be applied whatever the interface is
written i.e eth0 or eth0:1 .

Re: Possible IPTables bug in INPUT interface filtering?

[Richard Horton]

On 21 April 2010 19:27, Narendra Choyal <narendrachoyal@gmail.com> wrote:

> NOTE :
> -i also not work when we have two virtual IPs like eth0 and eth0:1 .
> In this case first rule will be applied whatever the interface is
> written i.e eth0 or eth0:1 .

Might be totally off base but have vague memories that the virtual
interface can't be filtered using -i / -o.

I've got a fairly complex rule setup using both in and out filters
using wildcards such that alot of rules are of the following kind
(these are for example only, exact port numbers and match criteria
vary)

-A INPUT -i eth+ -p udp -j ACCEPT
-A OUTPUT ! -o sl+ -p tcp -j DROP  (We don't want tcp traffic going
over very low bandwidth slip links!)
-A OUTPUT -o eth+ -p icmp -j ACCEPT
-A OUTPUT -o sl+ -p icmp <<hash limit match>> -j ACCEPT

Not encountered a problem where the io interface flag isn't working as
expected, but with the exception of one or two rules all the rules
using io flags are using wildcard matches.


-- 
Richard Horton
Users are like a virus: Each causing a thousand tiny crises until the
host finally dies.
http://www.pbase.com/arimus - My online photogallery
http://www.topcashback.co.uk/ref/rhorton

Re: Possible IPTables bug in INPUT interface filtering?

[Jan Engelhardt]

On Wednesday 2010-04-21 23:30, Richard Horton wrote:

>On 21 April 2010 19:27, Narendra Choyal <narendrachoyal@gmail.com> wrote:
>
>> NOTE :
>> -i also not work when we have two virtual IPs like eth0 and eth0:1 .
>> In this case first rule will be applied whatever the interface is
>> written i.e eth0 or eth0:1 .
>
>Might be totally off base but have vague memories that the virtual
>interface can't be filtered using -i / -o.

Because they are _NOT_ interfaces. Please, stop using tools like 
ifconfig. Their ioctls don't deal with multiple addresses and thus use 
fugly hacks like making up interfaces that are not really there and 
confusing the hell outta users.
(Use iproute2 instead.)