OpenWrt Forum Archive

Topic: Filter traffic between two wireless clients within one AP

The content of this topic has been archived on 18 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Is it possible to filter traffic between two wireless clients which are connected to the same AP?

What I am looking for, is to filter out rogue DHCP servers which are in wireless side of the AP.

Client MACs and real DHCP servers IP/MAC addresses are unknown, but the servers are on the LAN side.

eth0 and eth1 are bridged, filtering between those is of course possible.

the answeris no, as far i know it would be the equifilent of  ip filtering on a low end switch.

Unless I'm not understanding this... why not?

The WRT is a "switch with netfilter on it"...

Just block (reject) anything coming from the WLAN with port 67 / 68 ? Add some checks for MAC addresses if you wish. Pretty much anything is possible with iptables!

Jannes

i think the problem is that the connection between two wireless clients happens at the data-link layer, so netfilter never sees it.

ebtables ?

ill just try to explain:

The WRT is a "switch with netfilter on it"...

yes but, the traffic does not go through the router's tcp/ip stack to go from one computer to the other on the same subnet.

Just block (reject) anything coming from the WLAN with port 67 / 68

that is not possible with a switch because tcp and udp are on layer 4, ive only seen layer 3 switches that can do vlan tagging(just like the switch chipset in the wrt54g), that can route between subnets.

here is a link the the osi reference model

http://www2.rad.com/networks/1994/osi/layers.htm

josh

Unless I'm not understanding this... why not?

The WRT is a "switch with netfilter on it"...

Just block (reject) anything coming from the WLAN with port 67 / 68 ? Add some checks for MAC addresses if you wish. Pretty much anything is possible with iptables!

The ebtables or bridge-nf patch might do it. Not that I have tried this at all.. Anyway, here is some more info: http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html.

An unpatched 2.4 kernel will not filter bridged frames. In 2.6, these two packages are part of the kernel.

/Hans

...of course I had to try it, after all.

Turns out that the Linksys version of the kernel is already patched with ebtables. The only thing missing from openwrt is the modules from buildroot/build_mipsel/WRT54GS/release/src/linux/linux/net/bridge/netfilter and the userspace tool that you get from the ebtables sourceforge page (you'll have to cross-compile it for mipsel, of course). You also need to install /etc/ethertypes from the ebtables package.

Now, this does work. The only problem is that the Linux kernel isn't actually bridging traffic on the WLAN, and it doesn't bridge the traffic on the switch ports, either. So this only has an effect on traffic between the WLAN and the switch ports. (someone please correct me if this is wrong - it seems reasonable and it seems to work that way when i test it)

You can of course split the switch into four separate interfaces and do software bridging between all the ports (right, someone?), but that will still not help you with traffic between WLAN clients.

/Hans

the answeris no, as far i know it would be the equifilent of  ip filtering on a low end switch.


It is possible with latest (or last two) Linksys firmware. There is an "AP client isolation" option which prohibits direct communication between wireless clients.

It is possible with latest (or last two) Linksys firmware. There is an "AP client isolation" option which prohibits direct communication between wireless clients.

Yes, the wlconf from the 2.09.1 firmware handles the wl0_ap_isolate nvram var. I've extracted the wlconf binary and will test it under openwrt tonight, if possible.

/Hans

It is possible with latest (or last two) Linksys firmware. There is an "AP client isolation" option which prohibits direct communication between wireless clients.

Yes, the wlconf from the 2.09.1 firmware handles the wl0_ap_isolate nvram var. I've extracted the wlconf binary and will test it under openwrt tonight, if possible.

/Hans

will that also need a newer wl.o kernel module as based on what I saw in wlconf.c, it just pass that on to ioctl and let the kernel module does the job.

http://openwrt.org/forum/viewtopic.php?t=466

2.04.3 and 2.09.1 contain the newer wireless driver which is capable of the isolate, but the pieces required for the traditional wireless-tools support are missing. It's possible that pieces from previous drivers could be mix/matched but I have yet to try and have doubts as to the stability of such.

will that also need a newer wl.o kernel module as based on what I saw in wlconf.c, it just pass that on to ioctl and let the kernel module does the job.

Yes, you are right.

http://openwrt.org/forum/viewtopic.php?t=466

2.04.3 and 2.09.1 contain the newer wireless driver which is capable of the isolate, but the pieces required for the traditional wireless-tools support are missing. It's possible that pieces from previous drivers could be mix/matched but I have yet to try and have doubts as to the stability of such.

Thanks for the pointer! And no, it didn't work, of course.

/H

So what does wl0_ap_isolate control, exactly?  I guess it's telling the new driver to behave a certain way.  So this feature happens at the radio firmware level?  It's not part of 802.11b or Linux?  So AP Isolation is controlling the Ethernet (Link) layer somehow?
I'm interested in this because it would make using Frottle a lot easier - all clients associated to a Frottle-controlled AP need to send their data via that AP (actually, the router or PC connected to the AP).  I'd be interested to see if this AP_Isolation feature could be enabled on the wired ethernet ports - probably not I'm thinking, but worth pondering. wink

For the wired ports, you only need to use admcfg to add each port to a different vlan, but the problem is that then all the local traffic would go trough the processor, and the communication will get sloooowww (not sure how slow, maybe it isn't that much), but you will be able to filter traffic on wired.

For the wireless, the only thing I can come out is: VPN, create a VPN link for each wireless client, and then you can isolate them as you wich.

Maybe using different networks for each client, and then use iptables.  Off course, if one of your clients have airsnort, he could pick a IP from other network, and/or spy other clients, but I think it is better than nothing.

The discussion might have continued from here.