Community discussions

MikroTik App
 
UpRunTech
Member Candidate
Member Candidate
Topic Author
Posts: 213
Joined: Fri Jul 27, 2012 12:11 pm

Bridge filtering client to client comms

Thu Aug 10, 2017 7:20 am

I am trying to set up a bridge filter for client to client comms on a common WLAN interface. I am not having much luck.
  • WLAN and ETH are ports on a common bridge.
  • Bridge Fast Path is off.
  • Default forward on - one client can ping another.
  • Default forward off - the clients can't ping each other.
  • With default forwarding on any traffic at all between clients does not show up in the bridge or WLAN using torch. Traffic leaving WLAN to a wired address does show up in torch.
  • Bridge fast path is off.
It seems like WLAN traffic between clients on the same interface doesn't even make it to the bridge and gets copied locally and isn't visible on the bridge or visible by torch.

What do I have to do to steer client frames on a common WLAN interface through the bridge for filtering?
How can I observe clients communicating to each other on a common WLAN interface using torch?
 
UpRunTech
Member Candidate
Member Candidate
Topic Author
Posts: 213
Joined: Fri Jul 27, 2012 12:11 pm

Re: Bridge filtering client to client comms

Sat Aug 12, 2017 12:06 am

Aw bugger. Looks like I need bridge hairpin which Mikrotik doesn't allow to be enabled or it's hidden somehow.

I am not the only one with this problem. Mikrotik please add this option in! Client to client filtering on a bridge is needed!

viewtopic.php?t=79006#p575595

So I guess enabling Client-to-Client or Default Forward allows some kind of hairpin in a private bridge in the WLAN interface and this data never makes it to the actual bridge interface.

The desired model for my case would be:
  • Disable client to client/default forward.
  • Enable hairpin in bridge.
  • Be able to bridge filter client to client traffic. Happy days!
I think this is a desirable case, especially in a CAPSMAN system. Given more and more devices are going Wifi the need to block or filter data for a particular IP or MAC at the bridge level is important. Not all CAPSMAN uses are for just linking clients to a hotspot.

For example, if I have an inkjet printer connected only on Wifi I might want to stop the kids wasting ink and block the MAC or IP address if their devices from talking to the printer using a bridge filter. At the moment I'd have to put the printer on it's own WLAN interface by using a special printer SSID thereby forcing the client packets through the common bridge as data went from WLAN1 interface to WLAN2 interface.

Who is online

Users browsing this forum: No registered users and 46 guests