not [!] rule is not working

not [!] rule is not working

[pankaj jain]

Hi,
I was trying to drop arp packets such that only specific interface
should answer the arp requests.
I added following rules in input chain.
-j DROP -i !eth1 -o * -d 10.19.1.102 --opcode 1 , pcnt=0 -- bcnt=0
-j DROP -i !eth2 -o * -d 10.19.51.102 --opcode 1 , pcnt=0 -- bcnt=0

as packet count suggests these are not matching against any packet.
when I do arping from other machine to the 10.19.1.102 (assigned to
the eth1 interface)
arp requests are responded from eth0 (ip-10.19.0.102).
why the rules are not having any effect.

-- 
Thanks
Pankaj Jain

Re: not [!] rule is not working

[Gáspár Lajos]

pankaj jain írta:
> Hi,
> I was trying to drop arp packets such that only specific interface
> should answer the arp requests.
> I added following rules in input chain.
> -j DROP -i !eth1 -o * -d 10.19.1.102 --opcode 1 , pcnt=0 -- bcnt=0
> -j DROP -i !eth2 -o * -d 10.19.51.102 --opcode 1 , pcnt=0 -- bcnt=0
>
>   
I think that this should be in THIS form:

-j DROP ! -i eth1 ....
> as packet count suggests these are not matching against any packet.
> when I do arping from other machine to the 10.19.1.102 (assigned to
> the eth1 interface)
> arp requests are responded from eth0 (ip-10.19.0.102).
> why the rules are not having any effect
Swifty

Re: not [!] rule is not working

[pankaj jain]

On 8/14/07, Gáspár Lajos <swifty@freemail.hu> wrote:
> pankaj jain írta:
> > Hi,
> > I was trying to drop arp packets such that only specific interface
> > should answer the arp requests.
> > I added following rules in input chain.
> > -j DROP -i !eth1 -o * -d 10.19.1.102 --opcode 1 , pcnt=0 -- bcnt=0
> > -j DROP -i !eth2 -o * -d 10.19.51.102 --opcode 1 , pcnt=0 -- bcnt=0
> >
> >
> I think that this should be in THIS form:
>
> -j DROP ! -i eth1 ....
> > as packet count suggests these are not matching against any packet.
> > when I do arping from other machine to the 10.19.1.102 (assigned to
> > the eth1 interface)
> > arp requests are responded from eth0 (ip-10.19.0.102).
> > why the rules are not having any effect
> Swifty
>
>

I tried
arptables -A INPUT ! -i eth1 --opcode Request -d 10.19.1.102 -j DROP
but it was not working.
when i do the "arptables -L -nvx" it shows:
-j DROP -i eth1 -o !* -d 10.19.1.102 --opcode 1 , pcnt=0 -- bcnt=0
-- 
Thanks
Pankaj Jain

Re: not [!] rule is not working

[Grant Taylor]

On 08/14/07 07:28, pankaj jain wrote:
> I tried arptables -A INPUT ! -i eth1 --opcode Request -d 10.19.1.102 
> -j DROP but it was not working.  when i do the "arptables -L -nvx" it 
> shows:
> 
> -j DROP -i eth1 -o !* -d 10.19.1.102 --opcode 1 , pcnt=0 -- bcnt=0

(I'm betting that there is a logic to syntax mapping problem that is
preventing this from working.)

Can you get the rule to work with out any interfaces defined, i.e. get
it to block on all interfaces?  If you can get this to work it should be
trivial to add the correct interface.




Grant. . . .

Re: not [!] rule is not working

[Grant Taylor]

On 08/14/07 01:45, pankaj jain wrote:
> I was trying to drop arp packets such that only specific interface 
> should answer the arp requests.

I don't know if it applies to your situation or not, but have you tried
the configurations used in the Linux Virtual Server (a.k.a. LVS) to
prevent an interface from responding to ARP requests, i.e. via /proc
settings?



Grant. . . .

Re: not [!] rule is not working

[Grant Taylor]

On 08/14/07 01:45, pankaj jain wrote:
> I was trying to drop arp packets such that only specific interface 
> should answer the arp requests.

Will you please elaborate a bit more on why you are trying to accomplish
this and what your situation is?  I feel like there is more to this
puzzle that will help us help you.  For example, do you have multiple
(VLAN) physical interfaces on the same subnet or do you have an overly
large netmask that encompasses both IPs in your post?



Grant. . . .

Re: not [!] rule is not working

[pankaj jain]

On 8/14/07, Grant Taylor <gtaylor@riverviewtech.net> wrote:
> On 08/14/07 01:45, pankaj jain wrote:
> > I was trying to drop arp packets such that only specific interface
> > should answer the arp requests.
>
> Will you please elaborate a bit more on why you are trying to accomplish
> this and what your situation is?  I feel like there is more to this
> puzzle that will help us help you.  For example, do you have multiple
> (VLAN) physical interfaces on the same subnet or do you have an overly
> large netmask that encompasses both IPs in your post?
>
>
>
> Grant. . . .
>
>

I have a machine with 3 interfaces
eth0: 10.19.0.102 mask (255.255.255.0)
eth1: 10.19.1.102 mask (255.255.255.0)
eth2: 10.29.51.102 mask (255.255.255.0)

all three are connected in a same switch (no vlans configured).
I want arp requests to be responded by the associated interface only,
and not by other interfaces.
I have added following rules.
arptables -A INPUT -i eth0 --opcode Request -d 10.19.0.102 -j ACCEPT
arptables -A INPUT -i eth1 --opcode Request -d 10.19.1.102 -j ACCEPT
arptables -A INPUT -i eth2 --opcode Request -d 10.19.51.102 -j ACCEPT
arptables -A INPUT -i !eth0 --opcode Request -d 10.19.0.102 -j DROP
arptables -A INPUT -i !eth1 --opcode Request -d 10.19.1.102 -j DROP
arptables -A INPUT -i !eth2 --opcode Request -d 10.19.51.102 -j DROP

DROP rules with [!] are not working.
but if I remove the interface part it works fine
arptables -A INPUT -i eth0 --opcode Request -d 10.19.0.102 -j ACCEPT
arptables -A INPUT -i eth1 --opcode Request -d 10.19.1.102 -j ACCEPT
arptables -A INPUT -i eth2 --opcode Request -d 10.19.51.102 -j ACCEPT
arptables -A INPUT  --opcode Request -d 10.19.0.102 -j DROP
arptables -A INPUT  --opcode Request -d 10.19.1.102 -j DROP
arptables -A INPUT  --opcode Request -d 10.19.51.102 -j DROP


-- 
Thanks
Pankaj Jain

Re: not [!] rule is not working

[Grant Taylor]

On 08/16/07 00:56, pankaj jain wrote:
> I have a machine with 3 interfaces
> eth0: 10.19.0.102 mask (255.255.255.0)
> eth1: 10.19.1.102 mask (255.255.255.0)
> eth2: 10.29.51.102 mask (255.255.255.0)

Ok,

> all three are connected in a same switch (no vlans configured).  I 
> want arp requests to be responded by the associated interface only, 
> and not by other interfaces.

Ok,

> I have added following rules.
> arptables -A INPUT -i eth0 --opcode Request -d 10.19.0.102 -j ACCEPT
> arptables -A INPUT -i eth1 --opcode Request -d 10.19.1.102 -j ACCEPT
> arptables -A INPUT -i eth2 --opcode Request -d 10.19.51.102 -j ACCEPT
> arptables -A INPUT -i !eth0 --opcode Request -d 10.19.0.102 -j DROP
> arptables -A INPUT -i !eth1 --opcode Request -d 10.19.1.102 -j DROP
> arptables -A INPUT -i !eth2 --opcode Request -d 10.19.51.102 -j DROP
> 
> DROP rules with [!] are not working.

Hum.  I would not think that you even needed the ARPTables rules to
prevent the wrong interface from responding to an ARP request for
another IP.  Are you seeing this happen?  Or is the purely preventative?

> but if I remove the interface part it works fine
> arptables -A INPUT -i eth0 --opcode Request -d 10.19.0.102 -j ACCEPT
> arptables -A INPUT -i eth1 --opcode Request -d 10.19.1.102 -j ACCEPT
> arptables -A INPUT -i eth2 --opcode Request -d 10.19.51.102 -j ACCEPT
> arptables -A INPUT  --opcode Request -d 10.19.0.102 -j DROP
> arptables -A INPUT  --opcode Request -d 10.19.1.102 -j DROP
> arptables -A INPUT  --opcode Request -d 10.19.51.102 -j DROP

In short, you are allowing the ARP request for the specific interface /
IP pair and then dropping any other ARP requests.  You really could
re-write the above as such:

arptables -A INPUT -i eth0 --opcode Request -d 10.19.0.102 -j ACCEPT
arptables -A INPUT -i eth1 --opcode Request -d 10.19.1.102 -j ACCEPT
arptables -A INPUT -i eth2 --opcode Request -d 10.19.51.102 -j ACCEPT
arptables -A INPUT --opcode Request -j DROP

Rather I think this will work, but I can not guarantee that you will not
have to take some precautions to make sure that you don't effect other
possible interfaces (loop back / dummy / etc).



Grant. . . .

Re: not [!] rule is not working

[Pascal Hambourg]

Hello,

Grant Taylor a écrit :
> On 08/16/07 00:56, pankaj jain wrote:
> 
>>I have a machine with 3 interfaces
>>eth0: 10.19.0.102 mask (255.255.255.0)
>>eth1: 10.19.1.102 mask (255.255.255.0)
>>eth2: 10.29.51.102 mask (255.255.255.0)
> >
>>all three are connected in a same switch (no vlans configured).  I 
>>want arp requests to be responded by the associated interface only, 
>>and not by other interfaces.
[...]
> Hum.  I would not think that you even needed the ARPTables rules to
> prevent the wrong interface from responding to an ARP request for
> another IP.

The default behaviour is to reply on any interface for any local 
address. It can be changed on a per-interface basis with the kernel 
parameter /proc/sys/net/ipv4/conf/<interface>/arp_ignore. Definitions 
and values are in Documentation/networking/ip-sysctl.txt :

arp_ignore - INTEGER
	Define different modes for sending replies in response to
	received ARP requests that resolve local target IP addresses:
	0 - (default): reply for any local target IP address, configured
	on any interface
	1 - reply only if the target IP address is local address
	configured on the incoming interface
	2 - reply only if the target IP address is local address
	configured on the incoming interface and both with the
	sender's IP address are part from same subnet on this interface
	3 - do not reply for local addresses configured with scope host,
	only resolutions for global and link addresses are replied
	4-7 - reserved
	8 - do not reply for all local addresses

	The max value from conf/{all,interface}/arp_ignore is used
	when ARP request is received on the {interface}

Re: not [!] rule is not working

[Grant Taylor]

On 08/16/07 10:07, Pascal Hambourg wrote:
> The default behaviour is to reply on any interface for any local
> address. It can be changed on a per-interface basis with the kernel
> parameter /proc/sys/net/ipv4/conf/<interface>/arp_ignore. Definitions
> and values are in Documentation/networking/ip-sysctl.txt :

Ok, so this can be set up, it is just something that has to be turned on
via /proc.

> arp_ignore - INTEGER
>     Define different modes for sending replies in response to
>     received ARP requests that resolve local target IP addresses:
>     0 - (default): reply for any local target IP address, configured
>     on any interface
>     1 - reply only if the target IP address is local address
>     configured on the incoming interface
>     2 - reply only if the target IP address is local address
>     configured on the incoming interface and both with the
>     sender's IP address are part from same subnet on this interface
>     3 - do not reply for local addresses configured with scope host,
>     only resolutions for global and link addresses are replied
>     4-7 - reserved
>     8 - do not reply for all local addresses
> 
>     The max value from conf/{all,interface}/arp_ignore is used
>     when ARP request is received on the {interface}

If I understand the OP and what you have provided here correctly I
believe the OP would simply want to issue the following commands:

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/eth2/arp_ignore

This should configure the interfaces to only respond to ARP requests for
their own IP address(s) (not other interfaces IP address(s)) correct?

Thus the kernel would take care of what the OP is wanting to do and the
there would be no need for ARP / IPTables, correct?

So I can correctly update my references, where did you copy and past
that documentation from?



Grant. . . .

Re: not [!] rule is not working

[Franck Joncourt]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Thu, Aug 16, 2007 at 10:27:32AM -0500, Grant Taylor wrote:
> On 08/16/07 10:07, Pascal Hambourg wrote:
> > The default behaviour is to reply on any interface for any local
> > address. It can be changed on a per-interface basis with the kernel
> > parameter /proc/sys/net/ipv4/conf/<interface>/arp_ignore. Definitions
> > and values are in Documentation/networking/ip-sysctl.txt :

[...]
> So I can correctly update my references, where did you copy and past
> that documentation from?

It comes from the kernel Documentation.

-- 
Franck Joncourt
http://www.debian.org - http://smhteam.info/wiki/
GPG server : pgpkeys.mit.edu
Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: not [!] rule is not working

[pankaj jain]

On 8/16/07, Grant Taylor <gtaylor@riverviewtech.net> wrote:
> On 08/16/07 10:07, Pascal Hambourg wrote:
> > The default behaviour is to reply on any interface for any local
> > address. It can be changed on a per-interface basis with the kernel
> > parameter /proc/sys/net/ipv4/conf/<interface>/arp_ignore. Definitions
> > and values are in Documentation/networking/ip-sysctl.txt :
>
> Ok, so this can be set up, it is just something that has to be turned on
> via /proc.
>
> > arp_ignore - INTEGER
> >     Define different modes for sending replies in response to
> >     received ARP requests that resolve local target IP addresses:
> >     0 - (default): reply for any local target IP address, configured
> >     on any interface
> >     1 - reply only if the target IP address is local address
> >     configured on the incoming interface
> >     2 - reply only if the target IP address is local address
> >     configured on the incoming interface and both with the
> >     sender's IP address are part from same subnet on this interface
> >     3 - do not reply for local addresses configured with scope host,
> >     only resolutions for global and link addresses are replied
> >     4-7 - reserved
> >     8 - do not reply for all local addresses
> >
> >     The max value from conf/{all,interface}/arp_ignore is used
> >     when ARP request is received on the {interface}
>
> If I understand the OP and what you have provided here correctly I
> believe the OP would simply want to issue the following commands:
>
> echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore
> echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_ignore
> echo 1 > /proc/sys/net/ipv4/conf/eth2/arp_ignore
>
> This should configure the interfaces to only respond to ARP requests for
> their own IP address(s) (not other interfaces IP address(s)) correct?
>
> Thus the kernel would take care of what the OP is wanting to do and the
> there would be no need for ARP / IPTables, correct?
>
> So I can correctly update my references, where did you copy and past
> that documentation from?
>
>
>
> Grant. . . .
>
>
do these rules apply for logical interfaces also?
because in my actual case I would be having 127.x.x.x ips on my
physical interfaces and actual ips on logical interfaces. for example:
eth0 - 127.2.3.4
eth0:0 - 10.19.0.102
is there any command which can turn on these flags permanently such
that I dont have to do it on every reboot of the machine?

-- 
Thanks
Pankaj Jain

Re: not [!] rule is not working

[Grant Taylor]

On 08/17/07 03:09, pankaj jain wrote:
> do these rules apply for logical interfaces also?

Logical as in aliased interfaces or logical as in VLAN interfaces?  I
don't _think_ they apply to aliased interfaces other than the fact that
the IP(s) will be different.  VLANs will need their own rules though as
they are a pseudo physical interface.

> because in my actual case I would be having 127.x.x.x ips on my 
> physical interfaces and actual ips on logical interfaces. for 
> example:
> 
> eth0 - 127.2.3.4
> eth0:0 - 10.19.0.102

Um, be careful using 127.x.y.z/8 on any thing other than the loop back
as I think there are hard coded filters in the kernel to protect the
loop back.  I don't know if it is to protect the IP range or the subnet
that is assigned to the loop back interface.  Just be aware....

> is there any command which can turn on these flags permanently such
> that I dont have to do it on every reboot of the machine?

Um, there are some config files on some distros that have this option
per say.  Rather that is to say that they read the file and set the
parameters on boot on your behalf.  As far as how to set them and not
have them be set on boot, I'm sure you could modify the kernel source.



Grant. . . .