AFAIK (but I may be wrong) traffic between two wireless clients of same radio (i.e. same wifi interface) is handled by wireless driver. While technically they are handled by CPU (because whole wireless driver runs on CPU), they don’t pass bridge logic handled by CPU.
So the traffic between client1 and client2 goes like this (when forwarding=yes):
client1 -> air -> wireless chip -> wireless driver -> wireless chip -> air -> client2
If you want bridge to interfere with traffic, it would have to go like this:
client1 -> air -> wireless chip -> wireless driver -> bridge port A -> bridge (on CPU) -> bridge port A -> wireless driver -> wireless chip -> air -> client 2
which, AFAIK, doesn’t happen. If wireless interface was configured with forwarding=no, then frames would follow the above path from left to the point bridge (on CPU) but would not proceed to point bridge port A (the right one).
With forwarding=yes, Enabled Bridge firewall was working just fine between 2 wireless clients on the same radio…
I could allow or drop traffic between those hosts…
Edit: On different device with not the same wireless chip ( as my first test ), Bridge firewall is not working on the wireless interface…
Maybe they use different driver and behave differently ?
It does work for other interfaces though e.g from wireless to some physical port …
First i have to apologize for capturing this thread. But it is about the RB4011 and VLAN so it is perfect for my purposes.
HELP! Please Help!
I thougt i understand the basic concept about VLAN and on my previous router (Turris MOX) the VLAN setup was a no-brainer. But for the RB4011 and/or Router OS (6.48.4) it seems i am just too dumb.
I want/need
ether1 for WAN (default)
ether2, ether3, ether4, ether5 and 5GHz WLAN for VLAN “Office”
– PIV 30, 10.10.30.1/24, Lease room 10.10.30.10 - 10.10.30.250
ether6, ether7, ether8, ether9 and ether10 VLAN for “Fun”
– PIV 50, 10.10.50.1/24, Lease room 10.10.50.10 - 10.10.50.250
sfp-sfplus1 is disabled as i currently have no use for it.
I read pcunite’s and sindy’s article Using RouterOS to VLAN your network and RouterOS bridge mysteries explained (i really appreciate your work!), studied the different examples and tried them - and i tried some things on my own. But no matter what i tried, after turning VLAN on (/interface bridge set bridge vlan-filtering=yes) the connection to the router had been cut and i had to reset the router (I wish it had a power button). And the “Safe Mode” is not really working, is it?
Below my currently used configuration - with no VLAN setup at all. Beside the DHCP and WLAN settings it is pretty default but i hope to use it as starting point. I read that only one Bridge is neccessary for VLAN but a bridge for each DHCP-Server seems more… eem… smooth(?) to me.
—>>>
Edit: cut the configuration settings. As it is not longer relevant it seems useful to spare space.
<<<—
Sorry for that but I can not attach files.
I would be most happy and gradeful if someone has a hint or a push in the right directio - or a configuration file.
I am almost certain that i just miss some small but most vital point. But meanwhile i tried too many variantions and i just lost overview and focus.
Thanks to all reading my text and trying to help!
I started over with pcunite’s RouterSwitchAP configuration and sadly VLAN still not working (cross VLAN communication and access is possible). However, beside this the network is running and i do not lose contact to the router. The solution for not working VLAN i guess is to find in the ip filter options so i will go there.
There is considerable confusion as to what is meant by ‘private VLAN’, so let me clarify.
Private VLANs are defined in RFC 5517 and are implemented on many brands of switches, most notably Cisco, so they are not unusual.
It is possible to implement a private VLAN on MikroTik routers, but there’s a catch. The following example shows how.
Let ether2 be a promiscuous port, ether6 an isolated host port, and ether7 and ether8 community host ports. VLAN 100 is the primary VLAN, VLAN 200 is an isolated secondary VLAN, and VLAN 300 is a community secondary VLAN.
The following commands implement the private VLAN.
So, what’s the catch? Because the last command activates independent VLAN learning (IVL), the MAC addresses of the hosts connected to ether6, ether7, and ether8 don’t appear in the MAC forwarding table for VLAN 100. Consequently, the promiscuous port broadcasts to all three host ports. This consumes bandwidth and reduces security.
Implementing shared VLAN learning (SVL) would fix the problem, but MikroTik seems to be dumbing down its switches by eliminating many of the commands under /interface ethernet switch. (Compare the CRS3xx/5xx series switches with the CRS1xx/2xx series switches, which appear to be being phased out.) Consequently, this catch is unlikely to go away.