Wow what a rollercoaster... Your bet was 100% correct, it actually works !!!
And such a shame that i didn't even had ebtables installed.
Now i need to reconfigure all my other stuff but luckily it's not that much (Adblock, dnscrypt-proxy, sqm-qos, dyndns and a few port forwardings).
Big thanks to all, especialy dlakelan for being so patient with me ! <3
Hopefully this will help someone in the future...
Yeah, we should really get this into the guide to setting up guest networks on the wiki, at least to link to this thread and the other thread for those who want guests on multiple bands or the like.
perhaps you can figure out where in the wiki this should go and put in a few links?
You are right, it should be noted somewhere...
And imho it's really essential to completely "isolate clients" in a guest network.
I've just tested a LAN client connected to the guest network and it's also working for my LAN clients. Awesome !
I think it depends on the use you're putting the guest network to. For example, if you want your guests to be able to come to your gaming festival and connect up and play LAN games together, it obviously won't work. But if you are assuming the guests are all independent people who have nothing to do with each other at a coffee shop, or a library, or bus station... then your assumption is probably safest.
What is the point of bridging when you disable it afterwards with ebtables?
Why not put each guest wifi (interface) in a own zone and setup forwarding/firewall rules accordingly?
Also i think wifi client isolation will not prevent anyone on the same wifi network to sniff traffic from each other?
If you want real isolation you need something like radius with authentication per user ?
The point of the bridging is you can roam between the two radios without losing your connections.
All the ebtables rule does is check to see if the packet came IN on any port in this bridge, and if it did, don't let it be bridged to any other port on this bridge... That keeps two clients on the same bridge from talking to each other... but it doesn't keep your device from using either one of the bridge ports... in this case the ports are wlan radios, so a client can start say close to the AP, connected to high speed 5ghz and as it moves farther away from the AP potentially switch over to 2.4 ghz which usually has longer range... and still stay connected with the same IP address and continue all of its ongoing TCP connections etc.
Are you sure that the connections don't get dropped?
Because the clients still have to reauthenticate when they switch over from 2.4ghz to 5ghz?
And when im correct op wants that regardless if guest-lan ,guest2.4ghz, guest5ghz
Clients should not be able to talk to each other, i think the bridge can be removed.
As already posted here, put all interfaces in the same zone and then disable forwarding in that zone.
For the communication between the clients on wifi, as already posted, client isolation can be used.
But for the guest-lan i dont know?
Well, I've roamed between access points in my home while having VOIP conversations. I suppose it's possible tcp connections drop but UDP are ok. in general though, even if TCP resets occur, it's a lot more useful to roam between multiple APs on the same ESSID vs just sticking to the one ESSID until you actually can't communicate anymore and then seeing if anyone else you know how to connect to is available once you really do drop, and then connecting to that, doing a DHCP for a new IP address, and then starting all over again. Connection droppage is certainly shorter with the bridge, as you don't need to do DHCP. This is particularly true when you have several APs in different physical locations, bridging them all into the same LAN with the same ESSID is the way to go, not "myhouse-frontroom" on 192.168.1.0/24 and "myhouse-backroom" on 192.168.2.0/24 and "myhouse-garage" on 192.168.3.0/24 and "myhouse-guest-frontroom" on 192.168.4.0/24 and "myhouse-guest-backroom" on 192.168.5.0/24 .... etc, it makes much more sense to do "myhouse" and "myhouse-guest". This is the point of ESSID (extended service set ID they identify an extended service set... multiple APs that are on the same network).
Yes it makes no sense to split everything into different sub networks.
But i think the clients will do dhcp request everytime it switches the ap even when its on the same (sub)network.
Maybe use 802.11r (fast roaming)?
I run 802.11r over multiple APs and across both bands. For clients that use it, the typical 1.5-second authentication time drops to nothing but a momentary glitch in audio or FaceTime. With the APs appropriately bridged, there is no DHCP request, nor re-routing when the roaming occurs.
no even without fast roaming I don't think that happens. Fast roaming just speeds up the roam, it doesn't change the basic fact that you're roaming. The whole point of ESSIDs is that they should indicate that the client is on the same network and so the client knows that it's still going to use the same IP address, the same DNS, the same routes, etc. Wikipedia has an accurate description under Extended Service Sets, even if it's a little pedantic https://en.wikipedia.org/wiki/Service_set_(802.11_network)
I just streamed a live NASA stream on YouTube while walking around my house, watching the output of "watch iwconfig" and saw a transition between APs with no important glitch in streaming (I assume there's some buffering involved, but whatever, the transition was fast enough that buffering made it irrelevant even without 802.11r)
I do think with VOIP I get a 500ms to 2 second audio drop if 802.11r doesn't work. But after that the udp packets arrive at their appropriate spot and the audio returns...
I can confirm that roaming works quite well in my case, haven't tested voip but video playback was still working fine when going out of the range of 5ghz...
I've only got one last problem but i think it's not directly related to OpenWRT.
I'm running another Guest AP with Tomato fw (vlan3, IP: 192.168.55.2).
Connecting to this AP works totaly fine and i do get an IP via DHCP of my OpenWRT guest network.
But when connected to my tomato Guest AP im able to ping clients connected to my OpenWRT Guest Network and vice versa.
I would be quite happy if someone have a solution for this problem, i'm not sure that it can be fixed, but hopefully it can be fixed somehow.
So I'm running the following fw rules on my Tomato Router to isolate clients and deny the access to each other:
wl -i wl0 ap_isolate 1
ebtables -I FORWARD -i wl0 -o wl0 -j DROP
iptables -I FORWARD -i br1 -d 192.168.0.0/16 -j DROP
iptables -I FORWARD -i br1 -d 172.16.0.0/12 -j DROP
iptables -I FORWARD -i br1 -d 10.0.0.0/8 -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
Tomato VLAN config:
Tomato Basic config:
OpenWRT VLAN config:
I didnt know that roam/bridge/nodhcp thing.
Good to know.
I assume your tomato router is wired into your openwrt router? If so, is the eth0.3 interface in the bridge? If so, I don't know why it shouldn't be isolated by the ebtables rule. If eth0.3 is not in the bridge, then it seems like it will route and that'd be a problem. Make sure it's in the bridge.
Yes its wired into my OpenWRT router (OpenWRT Lan port 1 >> Tomato Lan Port 1) and eth0.3 is bridged to my guest network.
What could be the problem here ?
I'm not sure about the openwrt to tomato direction, but connections coming in on eth0.3 from tomato should not bridge to other interfaces in the bridge. And devices connected to openwrt shouldn't be able to bridge to tomato... Unless ebtables isn't working
I guess ebtables are working fine as the one ebable rule fixed my client isolation problem...
But i dont know if everything is correctly set up on my Tomato AP.
Probably most of my fw rules are not making much sense as the Tomato router is only serves as a vlan capable switch with Wifi AP.
The weird part is that i blocked access to my Modem IP bridged to the wan interface and clients connected to my Tomato guest AP are not able to access the web gui or ping my modem, same as my clients connected to my OpenWRT guest AP... I dont understand why these Tomato Guest AP clients are able to see and ping my OpenWRT guest clients. 
Does it go both ways tomato to openwrt and also vice versa?
Just realised that it only goes from Tomato >> to >> OpenWRT.
Tomato >> to >> Tomato does go as well (pingable + discover devices connected to Tomato guest AP)
OpenWRT >> to >> Tomato seems to get blocked like it should be...
So the problem has to lay within the Tomato AP ?
EDIT: Another test showed me that it doesn't even go Tomato >> OpenWRT.
It just goes Tomato >> Tomato.
**And it doesn't matter if it's Tomato Guest LAN >> Tomato Guest WIFI or Tomato Guest WIFI >> Tomato Guest WIFI...
At the end its just my Tomato AP/Switch which is leaking, not OpenWRT.
The question is how do i get this solved ?
Do i have to buy another AP which is capable of running OpenWRT and replace my Tomato AP ? 
You have to have eth0.3 in the bridge not just in the same firewall zone... If it really is in the bridge... I don't get it. Because packets come in on eth0.3 from tomato and to get to openwrt clients it has to bridge. Perhaps this is something to do with vlans... Maybe the input iFace is eth0 in which case you could also add ebtables rules to block bridging packets coming in eth0...?
