Ah ok that makes more sense. The same ebtables rule should apply to tomato, of course maybe just flash openwrt on that device? 
That wont work tho, it's a Asus RT-N16U and i also have a RT-N66U (currently not used)...
From what i read they dont go well with OpenWRT 
edit: u think ebtables -A FORWARD --logical-in br-guest -j DROP should work with Tomato ?
If it works it should be ebtables -A FORWARD --logical-in br1 -j DROP as br1 is the guest Network...
I'll give it a try 
Tomato is dual band also? The same ebtables rule should work, assuming it's installed on tomato
RT-N16 is single band and ebtables should be installed in the Tomato build which i'm using...
I'm not 100% sure tho but i used this firmware and ebtabes to isolate clients in router mode and it worked so i guess ebtables are included.
With "ebtables -A FORWARD --logical-in br1 -j DROP" i dont recieve an IP adress anymore via Wifi.
LAN works fine tho...
All Traffic seems to get routed over eth0 and eth1, br0 and br1 only have a few Kib worth of Traffic.
I'm gonne try to upgrade my RT-N66U to freshtomato MIPS fork.
Seems to be the latest one out there and I'm pretty sure ebtables is avalible within this build.
Right, on the tomato you get DHCP from openwrt so you can't block bridging with ebtables it is needed for basic functions. Hmmm.
You can perhaps put more specific ebtables rule, prevent sending out wlan0 if comes in wlan0. And prevent wired to wireless bridging except on the trunk port back to openwrt.
Three rules should work, if it comes in on trunk, allow, if it goes out on trunk, allow, otherwise logical in on bridge disallow.
Uhm, to be honest i don't know how i would get that done. I'm really no ip/ebtables expert... 
I've tried the following rules (using my RT-N66U@ fresh Tomato (2018.1.066-beta):
wl -i wl0 ap_isolate 1
wl -i wl1 ap_isolate 1ebtables -I FORWARD -i wl0 -o wl0 -j DROP
ebtables -I FORWARD -i wl1 -o wl1 -j DROP
ebtables -I FORWARD -i wl1 -o wl0 -j DROP
ebtables -I FORWARD -i wl0 -o wl1 -j DROPiptables -I INPUT -i br1 -m state --state NEW -j DROP
iptables -I INPUT -i br1 -p udp -m multiport --dports 53,67 -j ACCEPT
But they doesn't have any impact. I can still Ping and discover devices connected to Tomato Guest AP's.
So you are saying is that i need more specific ebtable rules in OpenWRT to fix this issue ?
I never thought that it would be so hard to have another isolated AP run together with my OpenWRT one...
No openwrt is all set, you need ebtables in the tomato. The ones you propose seem reasonable, are you sure they were applied?
I can't tell you for sure but i think they get applied, if i set "ebtables -A FORWARD --logical-in br1 -j DROP" i'm not able to recieve an IP anymore (via Wifi).
These rules worked for sure when the Tomato Router was in actual Routing Mode but they don't seem to work anymore for whatever reason with my current setup.
I'm thinking about to buy a decent Managed switch but i could save the money if get it done with my Tomato router...
I think these should work:
ebtables -I FORWARD -i ! eth0.3 -o eth0.3 -j ACCEPT
ebtables -I FORWARD -i eth0.3 -o ! eth0.3 -j ACCEPT
ebtables -I FORWARD --logical-in br1 -j DROP
They let anyone connected to tomato send to or from the OpenWRT, but nothing hairpining back to tomato
please modify if I've got the names of interfaces wrong, like if it's supposed to be eth1 or br2 or whatever.
I've just applied those 3 rules and replaced eth0.3 with eth1 and rebooted.
Again i'm not able to recieve an IP anymore (wifi).
br1 is defently my Guest Network within Tomato (IP 192.168.55.2 = Tomato, 192.168.55.1 = OpenWRT)
and my guest AP is bridged to eth1.... I'm not sure what's wrong here.
Do i have to replace eth1 with wl0 ?
ifconfig Tomato (after reboot):
root@TomatoAP:/tmp/home/root# ifconfig -a
br0 Link encap:Ethernet HWaddr
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1052 errors:0 dropped:0 overruns:0 frame:0
TX packets:454 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:89055 (86.9 KiB) TX bytes:377448 (368.6 KiB)
br1 Link encap:Ethernet HWaddr
inet addr:192.168.55.2 Bcast:192.168.55.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:627 errors:0 dropped:0 overruns:0 frame:0
TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:69290 (67.6 KiB) TX bytes:7600 (7.4 KiB)
eth0 Link encap:Ethernet HWaddr
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1280 errors:0 dropped:0 overruns:0 frame:0
TX packets:454 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:129282 (126.2 KiB) TX bytes:379264 (370.3 KiB)
Interrupt:4 Base address:0x2000
eth1 Link encap:Ethernet HWaddr
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:368 errors:0 dropped:0 overruns:0 frame:28515
TX packets:301 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:53870 (52.6 KiB) TX bytes:54864 (53.5 KiB)
Interrupt:3 Base address:0x1000
imq0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
imq1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:30
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:154 errors:0 dropped:0 overruns:0 frame:0
TX packets:154 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:24690 (24.1 KiB) TX bytes:24690 (24.1 KiB)
vlan1 Link encap:Ethernet HWaddr
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:1054 errors:0 dropped:0 overruns:0 frame:0
TX packets:454 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:93405 (91.2 KiB) TX bytes:379264 (370.3 KiB)
vlan2 Link encap:Ethernet HWaddr
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
vlan3 Link encap:Ethernet HWaddr
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:226 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12837 (12.5 KiB) TX bytes:0 (0.0 B)
I'm gonne try it with my RT-N66U@freshtomato now, maybe the ebtable version of the Tomato firmware running on my RT-N16 is too old (firmware is from 2015)....
edit: tried with wl0 and vlan3 instead of eth1 but same result, i can't recieve an IP adress anymore via Wifi...
I'm gonne test it with my N66U now.
Same result with my N66U @ freshtomato.
With ebtables -I FORWARD --logical-in br1 -j DROP i'm not able to recieve an IP adress anymore...
edit: iIve tried to reverse the ebtable order...
ebtables -I FORWARD --logical-in br1 -j DROP
ebtables -I FORWARD -i wl0 -o wl0 -j DROP
ebtables -I FORWARD -i ! eth1 -o eth1 -j ACCEPT
ebtables -I FORWARD -i eth1 -o ! eth1 -j ACCEPT
I was able to receive an IP address again but when probing the Tomato guest network i was again able to see all the devices connected to it.
It seems to be impossible... 
edit: I've found something at the linksysinfo.org forum...
#enable wifi guest isolation (for wifi clients only, not lan)
wl -i wl0.1 ap_isolate 1
#block lan access too
ebtables -I FORWARD 1 -d Broadcast -j ACCEPT
ebtables -I FORWARD 1 -s xx:xx:xx:xx:xx:xx -j ACCEPT
ebtables -I FORWARD 1 -d xx:xx:xx:xx:xx:xx -j ACCEPT
ebtables -I FORWARD 4 -i wl0.1 -j DROP
ebtables -I FORWARD 4 -o wl0.1 -j DROP
Where xxx... is mac of upstream lan.
Source: http://www.linksysinfo.org/index.php?threads/wifi-access-point-with-isolated-guest-ssid.70966/#post-292455
Not sure if i understand it correctly but i'll give it a try tomorrow.
If it works i would just find a solution for my Guest-LAN clients....
aha, sorry, -I inserts at the head of the chain, you want -A append if you give it in the order I gave you (thats what I get for doing it on the fly from my phone).
AHA thanks for giving me the ifconfig, I guess on tomato the vlan1,vlan2,vlan3 interfaces are what I was assuming was called eth0.3 etc.
ebtables -A FORWARD -i ! vlan3 -o vlan3 -j ACCEPT
ebtables -A FORWARD -i vlan3 -o ! vlan3 -j ACCEPT
ebtables -A FORWARD --logical-in br1 -j DROP
We have to remember to clear out ebtables before inserting/appending things. you probably should look at your ebtables rules, it shouldn't have any older leftover ones...
I think this should work.
1 Like
I couldn't resist and tested the rules from the linksysinfo post and they seem to work !
But it only works when setting up another virtual AP (wl0.1).
I couldn't get it to work with wl0 (no IP address again)...
Now i only need to figure out the right commands to block Access from my (Tomato) guest LAN clients to my (Tomato) Guest Wifi clients.
EDIT: I've tested the provided ebtable rules (dlakelan) again and they also work !!
Now i would only need the right rule(s) to block Guest LAN (Tomato) >> to Guest Wifi (Tomato).
Tomato-Guest Wifi clients are not able to see each other anymore but my Tomato-Guest LAN client still comes up when probing the (Tomato) Guest Network via Port Authority...
Big big thanks² dlakelan, you really helped me alot already !!
1 Like
I just don't know much about Tomato, and it's on some ancient kernel right? 2.6 series or something? but if it has "ip" can you do:
ip link show
which will list all your links by kernel name, including the wifi links, and hopefully will show the bridge relationships as well, that will help me understand why my rules don't work for you probing wifi to wired
Linux kernel 2.6.22.19... 
root@TomatoAP:/tmp/home/root# ip link show
1: lo: <LOOPBACK,MULTICAST,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
4: vlan1@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,10000> mtu 1500 qdisc noqueue
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: vlan2@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
6: vlan3@eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,10000> mtu 1500 qdisc noqueue
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
8: wl0.1: <BROADCAST,MULTICAST,ALLMULTI,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
9: br1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
10: imq0: <NOARP> mtu 1500 qdisc noop qlen 30
link/void
11: imq1: <NOARP> mtu 1500 qdisc noop qlen 30
link/void
Yeah i know.... maybe i should try and run OpenWRT on my RT-N16 but Tomato runs pretty well on that old device and the Wifi performance is quite good, to be honest it's way better than my WRT3200acm@ 2.4ghz (hopefully that will change in the future). 
yeah, ancient version of ip as well. doesn't list the info I want, such as for example from OpenWRT:
12: wlan1-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-guest state UP mode DEFAULT group default qlen 1000
link/ether 00:25:9c:13:e4:aa brd ff:ff:ff:ff:ff:ff
which clearly shows that wlan1-1 is part of br-guest for example.
so, here's the question you need to answer to understand why the ebtables rule doesn't work (try some kind of "brctl" or "bridge" commands to find out the info)
are vlan3, and wl0.1 both in the br1 and is there anything else in br1, such as eth0 for example or eth1 by itself... the only thing in this bridge should be vlan3 and wl0.1
also it seems like maybe you've been posting a mishmash of two different tomato configs on two different routers?
In the end you want stuff to come in to your bridge from openwrt on vlan3 or go out to openwrt on vlan3 but you don't want anything to go local wifi to wired or wifi to wifi or wired to wifi...
if you want guests to access the guest network by wired... you need to add those ports to a separate vlan, say vlan4 and place those ports untagged into vlan4 and put vlan4 in the bridge along with vlan3 and wl0.1 that will isolate them properly.
Also, you need iptables rules on tomato that prevent routing between traffic on br1 and any other location such as your main LAN on vlan1, or your "wan" port on vlan2
I'm now at the point where the next set of wifi devices I buy will probably be someone's enterprise APs. My routers and managed switches are where all the sophistication is needed, and the enterprise APs work with VLANs... At the low end there's:
https://www.amazon.com/TP-Link-EAP225-V3-Wireless-Supports/dp/B0781YXFBT
It's not zero dollars, but it's pretty inexpensive compared to wasting time with 2.6 era kernels (first released in 2003 !!)
Though I can't promise it will isolate all clients within the AP (like across the two bands etc)
I'm only using my RT-N16 for now, so the configs are only from this device.
I'll try to find the right iptable rules...
root@TomatoAP:/tmp/home/root# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 8 packets, 1186 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * vlan2 0.0.0.0/0 0.0.0.0/0
4 232 SNAT all -- * br0 192.168.1.0/24 192.168.1.0/24 to:192.168.1.2
0 0 SNAT all -- * br1 192.168.55.0/24 192.168.55.0/24 to:192.168.55.2
I was thinking to buy one of those (to be on the safe side with vlan's aso):
But i have to say Tomato isn't a bad firmware, it's a bit messed up codewise and the kernel is "very ancient" but i had some good times with my Tomato Routers.
And ppl still like to use Tomato on their Routers but mostly because OpenWRT isn't avalible for their devices or wifi isn't working aso... 