By design, client-to-client forwarding sends traffic between to devices on the same AP so we never see it at the bridge. Therefore they can communicate with each other unrestricted.

If we switch off client-to-client forwarding then irrespective of if I switch off STP, by design traffic can't leave a bridge through the port it entered and therefore the two clients are entirely blocked from communicating except via some form of hairpin.

There's a thread from 10 years ago where someone described the same problem viewtopic.php?t=79006 we now are able to perform NAT on MAC addresses so perhaps it's now possible. I can't find very many other relevant threads. With IOT devices it's often nescessary to allow some limited traffic between devices that are likely on the same AP due to their proximity, so I'm a little stuck.

Has anyone else had a similar problem or found any solutions?

Kind Regards, Keir

On my network I use VLAN tagging depending on MAC address. Could use WPA2-EAP but IoT devices usually do not support it.
So I have setup MAC-authentication (and accounting) via RADIUS, installed user-manager and made user entries for each MAC address, and created User Groups with the appropriate Attributes to tag the traffic from that user in a specific VLAN.
Like this:
/user-manager user group
add attributes="Mikrotik-Wireless-Forward:1,Mikrotik-Wireless-VLANIDtype:0,Mikrotik-Wireless-VLANID:20" name=WiFi-IoT

With this, you can add many small groups of WiFi users in a more scalable way (i.e. not create a new SSID for everything).

This works fine, but only on the OLD wireless. The new wifiwave2 (or whatever it is called in 7.13 and later) does not yet support that.
Hopefully it will be added soon.

Yep, this is essentially what we've already got. Everything delivered through the same SSID then using CAPsMAN Access List.

Are you suggesting that by putting two devices that need to talk to each other but in a controlled way on different VLAN's, then "shorting" the VLAN's would create a hairpin as the bridge would be happy to see the same packet return back through the same port so long as its VLAN has changed?

I'll have a play.

Kind Regards, Keir

Well, yes. Say you want to have all your LED lamps with their controller in a network where they can talk to eachother and to internet, but not to your PC or TV or whatever, then you put all those devices in a VLAN and just have forwarding (between WiFi devices) enabled.
Then there is no need for bridge firewall rules. You can use IP firewall rules to prevent them from locally talking to other VLANs and still have routing to internet when you want that.
I have 4 VLANs for this and put each device in the appropriate VLAN. For that, I have VLAN subinterfaces attached to the bridge, each with a different IP address/subnet, and a DHCP server instance. The wireless interface tags the packet according to the user manager (or access list) entry.

It all works very nicely, but unfortunately not on the new WiFi drivers.

I recently asked a similar question on reddit. I judge by the answers that this feature is not very common.

---

Well, yes. Say you want to have all your LED lamps with their controller in a network where they can talk to eachother and to internet, but not to your PC or TV or whatever, then you put all those devices in a VLAN and just have forwarding (between WiFi devices) enabled.

You'd also want a virtual AP for that too

@pe1chl you mention that new drivers don't support that. Do you mean they do not support multiple VLANs per AP?

The reason I configured it as above is that I do not want a virtual AP for every usage. That just doesn't scale. Every extra virtual AP takes radio time sending beacons at the lowest rate.
My solution uses only a single AP, and tags each client with a different VLAN tag so they remain separated in the firewall.
But the new drivers do not support that. They do not even support tagging a WiFi interface with a fixed VLAN tag, let alone tagging each client differently.

What about separate VLANs for the main and virtual APs, does the new driver support that?

The new driver doesn't care about VLAN tags, so it's critically important to attach wifi interfaces (master and slaves) to vlan-enabled bridge as ports with pvid set (or play games with ugly workarounds in case bridge is not vlan-enabled). But this rules out any fancy setups (such as VID set in access lists or by RADIUS).

Well, yes. Say you want to have all your LED lamps with their controller in a network where they can talk to eachother and to internet, but not to your PC or TV or whatever, then you put all those devices in a VLAN and just have forwarding (between WiFi devices) enabled.
Then there is no need for bridge firewall rules. You can use IP firewall rules to prevent them from locally talking to other VLANs and still have routing to internet when you want that.
I have 4 VLANs for this and put each device in the appropriate VLAN. For that, I have VLAN subinterfaces attached to the bridge, each with a different IP address/subnet, and a DHCP server instance. The wireless interface tags the packet according to the user manager (or access list) entry.

It all works very nicely, but unfortunately not on the new WiFi drivers.

Ip firewall rules only manage L3 traffic and IP at that.

If your use case us to enable discovery protocols that operate on L2 - even a UDP broadcast is L2 for practical purposes because its staying on the same subnet.

Not sure what you mean by WiFi drivers. My setup uses a Hex S as the router and Cap AC's as access points. So the Hex S has no wireless interfaces but CAPsMAN adds the remote access points to the bridge.

Not sure what you mean by WiFi drivers

wifiwave2 (new) and wireless (legacy) in Mikrotik’s terminology. Each has its own submenu for configuration and, iirc, are mutually exclusive.

Not sure what you mean by WiFi drivers

wifiwave2 (new) and wireless (legacy) in Mikrotik’s terminology. Each has its own submenu for configuration and, iirc, are mutually exclusive.

Okay, yeah that's for WPA3 etc. Our APs are cAP AC which I don't think meet the requirements for that anyway.

I just want to get a hairpin somehow. I've tired using L2 NAT but it's not working, I think I'm going to have to do it on another router which translates the packets and sends them back. Either that or a managed switch which would be faster.

Our APs are cAP AC which I don't think meet the requirements for that anyway.

Support is/was added in ROS 7.13.

To my best knowledge the only approach is to split them into dedicated broadcast domains and then proxy broadcasts when necessary (e.g. mDNS repeater for mDNS).

Please report back if you find a solution to keep the WiFi clients in the same broadcasta domain while being able to filter traffic.

By design, client-to-client forwarding sends traffic between to devices on the same AP so we never see it at the bridge. Therefore they can communicate with each other unrestricted.

If I understand correctly, on an AP the wireless devices seem to share a private bridge where client-client communication happens. It's distinct from the main type of ROS bridges so you can't get access to it and mangle/filter traffic with the bridge filter which is a shame. I had asked Mikrotik earlier this year if they could have an option to force all client traffic through a ROS bridge for user manipulation, which would be handy for all traffic !local-forwarded to a common bridge on a CAPSMAN controller.

The reply was "Unfortunately, we can't say for certain at this time. This is something we would like to implement, but at this stage, it's unclear, if or when it could happen."

This was with regards to the standard Wifi package, not WW2.

I have in the past gotten around this and joined two VLAN (each attached it's own SSID) ports on a common bridge so that Wifi clients on each VLAN can communicate but I was able to use the bridge filter to strip certain frames out.

I've not had that much time to play recently. But a few things i've found:

1) shorting different VLANS kinda works but isn't reliable. I think [but i might be wrong] there's loop problems going on and because the packets are being relabled it's confusing STP.
2) in any case if it's on the same VLAN and it's local on the same AP then I think the AP's internal switch has it's own ARP table and won't send packets down - promiscuously - to the CAPMAN.

What I might try and do is use a spare rasberry pi and write something as a kernel module driving sk_buff directly to be an L2 NAT as a kind of hairpin - it will create a shadow device for everything on a particular VLAN that will allow it to hairpin.