Re: Filtering arp on vlan trunk interface

Sorry if this mail is not appearing in the thread previously started by me, as
this is just a copy from the archive @sourceforge.

> From: Grant Taylor <gtaylor@ri...> - 2007-08-30 15:00
> On 08/30/07 07:51, xerofun wrote:
>> I'm trying to filter arp broadcast packets from a specific mac
>> address (0:0e:15:33:9f:1b) on interface vlan111.
> 
> That should be simple enough to do.
> 
>> But I'm not sure if this issue is related to the item "ip/arp/etc
>> over vlan filtering" in the todo list?
> 
> I don't know and as such can not say.
> 
>> The bridge looks likes this:
>>
>> br0 0001.00e081111112 yes eth2
>> vlan111 (@eth3)
> 
> This looks simple enough. Well at least so long as there is not a loop
> between VLAN 111 and eth2.

Well, there actually is a loop (at least concerning mac conflicts), but I wanted
to keep my question as simple as possible, as there's no way to prevent the loop
in this setup, which is a bit more complex than what I was showing above. By
being able to filter out the mac address I was talking about, I could fix this
mac loop.


> 
>> When adding these rules to the INPUT and FORWARD chain, the counter
>> values raise, so it looks like packets are dropped.
>>
>> -A INPUT -p ARP --logical-in br0 --arp-mac-src 0:0e:15:33:9f:1b -j
>> DROP , pcnt = 2211 -- bcnt = 101706
>>
>> -A FORWARD -p ARP --logical-in br0 --arp-mac-src 0:0e:15:33:9f:1b -j
>> DROP , pcnt = 6876 -- bcnt = 316296
> 
> Ok...
> 
>> I also added these rules with "-i vlan111" instead of "--logical-in
>> br0".
> 
> Ok...
> 
>> Using 'brctl showmacs br0' I grep for the mac address. It's not
>> dissappearing, but instead, everytime a packet is dropped in the
>> chain (I'm running 'watch -n1 -d ebtables -L --Lc') the ageing timer
>> for that mac gets refreshed.
> 
> Well back up a moment and think about what you are doing. I'm presuming
> that you are running EBTables (verses IPTables and / or ARPTables) on
> the bridge interface br0. Thus you are filtering packets that are
> coming in to the system's higher layer network / protocol stack through
> br0. Thus the packets are already being bridged from either eth2 or
> vlan111 in to br0. Thus the MAC addresses would show up as a MAC
> address that the bridging code has bridged for you.

Yes, right, I'm running ebtables + iptables. Sorry for not mentioning this.

> 
> If you are wanting to prevent the MAC address from showing up at all,
> try your filtering as the packets enter either the eth2 or vlan111
> interface before they are bridged to br0.

The arp requests I want to filter enters vlan111 and that's where I also tried
to filtered the requests.

So thinking about your explanation, I tried the following:

Bridge chain: INPUT, entries: 20, policy: ACCEPT
-s 0:0e:15:33:9f:1b --logical-in br0 -j DROP , pcnt = 229 -- bcnt = 10534
-s 0:0e:15:33:9f:1b -i vlan111 -j DROP , pcnt = 0 -- bcnt = 0
Bridge chain: FORWARD, entries: 60, policy: ACCEPT
-s 0:0e:15:33:9f:1b --logical-in br0 -j DROP , pcnt = 36 -- bcnt = 1656
-s 0:0e:15:33:9f:1b -i vlan111 -j DROP , pcnt = 0 -- bcnt = 0

So this only matches the first rule, the counters of the second rules in every
chain are never matched/incremented. I'm definetly not trying to proof you
wrong, or maybe I just get something wrong here, but shouldn't the ARP request
be filtered by the second rule before it "reaches" br0? Following your
explanation - which sounds absolutely reasonable - this should be the way, right?


> 
>> So is this related to the todo "ip/arp/etc over vlan filtering"?
> 
> I'm not exactly sure what the "ip/arp/etc over vlan filtering" issue is
> so I can not say "No" for sure. However given the above point of view I
> going to guess "no".
> 
>> How would I be able to filter such an arp request, so that it's not
>> added to the bridge mac table?
> 
> Try using EBTables to filter the traffic before it enters the bridge by
> filtering at the lower level eth2 and / or vlan111 interfaces.
> 
> You may also want to investigate ARPTables for this.

I never used ARPtables, where does it hook into the packet flow? Before ebtables
or after ebtables? I will definetly have a look at it.

> 
>> Tcpdump also sees the arp packets coming in, this wouldn't be
>> happening if the ARP packets would have been filtered, right?
> 
> Ugh, I think this depends on what type of interface you are sniffing and
> what sniffer you are running as in where said sniffer connects to the
> interface and what capabilities the sniffer has.

This question was more about at what point tcpdump gets fed with the packet
headers. From my point of view it should happen after all filtering is done, as
it is a userspace tool and ebtables/iptables filtering happens in kernelspace,
right?

> 
>> I'm running Kernel 2.6.22.5 + Bridge + ebtables
> 
> Ok. I don't know of any problems there.
> 
>> Thanks in advance,
> 
> You are welcome.

Thanks a lot for your detailed answer.


> With {arp,ip,ip6}tables you can filter vlan encapsulated packets.

@Bart: So did you just forget "eb" in the curly brackets or did you mean that
these are the right tools to do so?

What I really want to do is to prevent mac addresses to reach the bridge mac table.


Best,

Lars




-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/