Issue at Hand
If you’ve segmented your network, you may have encountered difficulty utilizing Chromecast, Airplay, or similar IoT devices that rely on mDNS / Bonjour / ZeroConf or SSDP. This is due to these protocols not being routable or filterable. Numerous individuals face this issue, and while there are several solutions out there, none are entirely foolproof from a security perspective. Issues often include bi-directional traffic reflection, lack of filter options, absence of IPv6 support, and no session tracking.
However, I’ve devised a solution I believe encompasses the best of all possible remedies. It incorporates several different strategies, all created with RouterOS in mind.
What is our Objective?
Assume we have segmented networks in the following manner:
A client network, comprising your PCs, laptops, and family smartphones.
A guest network, comprising smartphones and other devices of your visitors.
An IoT network, consisting of your Chromecast, Airplay, and other IoT devices.
The goal is to utilize our IoT devices from our client network, but only a select number of devices within the IoT network should be accessible from the guest network. We don’t want to facilitate mDNS/SSDP from the IoT network to the client or guest network. Additionally, we want to prevent guests from using mDNS/SSDP to access the client network (and vice versa).
Proposed Solution
The Bonjour-reflector I’ve developed is an upgraded version of another project, with added protocols such as SSDP.
Key features include:
Detailed control over your advertised IoT devices based on MAC-addresses. Access can be set on a per-device basis.
Protocol inspection for a better understanding of SSDP and mDNS. It can distinguish between query responses and advertisements.
Session tracking, ensuring that it tracks which ports are being used for each session and only permits traffic to flow in the appropriate direction.
IPv6 support, facilitating usage with both IPv6 and IPv4.
A single binary.
Compact size, taking up only ~8MB of space.
It should be compatible with most arm(64) + CHR Mikrotiks. For a comprehensive guide, please refer to the markdown on Github.
The setup was fairly easy, however requires a reboot to get into container mode.
Configuration might look a bit challenging, however once you got the hang of it it is straight forward.
I’ve some Apple TVs, Denon and Sonos devices configured for reflection and works really well.
It is very fast and responsive, I used the Palo Alto Networks bonjour reflector option on the firewall before, but it seems not to reflect everything (ssdp?).
When I open for example the Sonos app on my phone all Sonos devices are there within a second, before this took a while and sometime I had to kill and re-open the app.
I doubt that message appeared after the very last step in this complicated setup. It’s my bet it occurred about ¼ of the way into the process, in this step, where it sets up the VETH with bridge VLAN filtering disabled.
This shaky bet of mine is based on two facts:
Not all RouterOS devices support bridge VLAN filtering. (See the yellow caution box below the target of the prior link.) You can’t disable something that doesn’t even exist on the host platform.
Your diagnosis is vague, not even telling us details like which RouterOS device you tried this on, permitting me to speculate freely on this point.
There’s a chance I’ve nailed it by luck. If so, then I think it’s worth pulling the bridge VLAN filtering bits out of the tutorial and trying to make it work using whatever alternative VLAN filtering mechanism your device supports instead. I have no doubt that this tutorial’s basic ideas work best with hardware bridge VLAN filtering, but I doubt it’s absolutely essential.
If that doesn’t work, or if I’ve missed the mark, the way to elicit stronger guesses is to provide details to found them upon rather than rely on superior levels of mind-reading and luck than what I’ve been able to bring to bear.
You are very welcome! I learned a lot about SSDP and mDNS and packet layers in general when making this.
Sorry for this confusing error. You may simply ignore it. Is isn’t relevant for Mikrotik routers as it is not connected to a hardware port. It is only needed when directly connected to a physical NIC, so for example on a linux host. the Veth interface on RouterOS does not need this…
I will make some code to first check if its even needed to set this nic feature.
@nicob,
Thank you for the great work ! I tried on hAP ax2 (v 7.11.2). My goal is to let apple TV ( vlan10) available to vlan12 network.
The topology is: Router ↔ CRS328 ↔ hAP ax2, ether1 on ax2 is set as trunk port.
But after getting reflector running, my phone (vlan 12) still cannot see apple TV (vlan10) on the airplay. With packet sniffer, I can see packets going in but not coming out.
Could you please take a look into my config and point me to the right direction ? Thank you !
Thank you for putting the effort in in providing me with great context!
This all looks ok… If the following is true
[] 10.13.0/12/13.254 NOT in use by any other device or themikrotik. If you ping the ip on the same network as a client , you should not get a response, however, arp -a should give you the mac addresss of the veth.
[] Doublecheck the mac adress
With packet sniffer, I can see packets going in but not coming out.
This is great! Are these packets with destination 239.255.255.250:1900 or 224.0.0.251:5353 ?
If yes, now run the container with a different cmd /bonjour-reflector -verbose, then stop and start it, you should at least see in the logs with packet received:
Not sure if it is because the reflector has to be installed on Router instead of the ax2 ?
Its fine either way, I have it on my router (CCR2004), but I also could have it somewhere else. but there are two main things to keep in mind.
The router on where bonjour-reflector runs should see all the multicast traffic and upstream ports should have unknown-multicast=yes. And you should not run multiple bonjour-reflectors in the same vlans.
Sorry for my late reply… I didn’t notice this message.
I was able to replicate this when, bridge-LAN does not exists or more likely when the vlan-id is unknown to the bridge, in this case 1 . The guide assumes
It assumes you have one bridge with vlans configured
So create the vlan on the bridge by assign it to a port, then follow step 3
Thank you for putting the effort in in providing me with great context!
This all looks ok… If the following is true
[] 10.13.0/12/13.254 NOT in use by any other device or themikrotik. If you ping the ip on the same network as a client , you should not get a response, however, arp -a should give you the mac addresss of the veth.
[] Doublecheck the mac adress
With packet sniffer, I can see packets going in but not coming out.
This is great! Are these packets with destination 239.255.255.250:1900 or 224.0.0.251:5353 ?
If yes, now run the container with a different cmd /bonjour-reflector -verbose, then stop and start it, you should at least see in the logs with packet received:
#################################################################
Thank you for your reply !
#1 10.x.x.254 is NOT in use by any devices. #2 What do you mean by “double check the mac address of veth1-reflector” ? #3 yes, both 239.255.255.250:1902 and 224.0.0.251:5353 showed up in the dst. #4 some logs after running /bonjour-reflector -verbose
It finally worked if there is only one device to be available to another network.
i.e Apple TV (vlan10) can be available to network vlan12.
But when I want to add devices and add networks, it doesn’t work. The only change I made is the config.toml file. And the error message is " Could not read configuration: duplicate tables".
Toml is sometimes confusing. [devices] needs defined only once. Use https://www.toml-lint.com for fast checking. The error messages may be implying errors on the line below…
In step 3 you are actually editing vlans on the bridge to add the veth bridge port (see screenshot) to the corresponded vlans
To be aple to edit the ports, you need to have the vlan ids on the bridge.
First of all thanks for the great effort on putting this all together!
I encountered the following issue with this approach though:
Everything seem to work, I was able to successfully proxy an ikea hub / tv / chromecast speaker, but when container starts it kills the network performance.
Here is an iperf3 test from a client vlan to the outside world:
The same happens if I start a packet sniffer on the veth1-reflector or the main bridge. So it seems the problem is some sort of a global promisc mode that container enables? (I have a very vague understanding of how this all works in mikrotiks).
Switching works well though, client → client is fast.
The same happens if I start a packet sniffer on the veth1-reflector or the main bridge.
what actually when using the packet sniffer is that all hardware offload temporarily is disabled. This is the only way the mikrotik controlplane can see the packets.
And this is a good clue. My first guess is that Hardware offload is disabled when you start the container. Please see if your bridge ports have an H flag. Or click all bridge ports and see if HW offload is on (in the bottom right of the window). And if this changes when starting, stopping the container.
Today 7.12 was released with some bridge fixed, two of the fixes:
*) bridge - fixed fast-path forwarding with HW offloaded vlan-filtering (introduced in v7.11);
*) bridge - fixed vlan-filtering stability with HW and non-HW offloaded ports (introduced in v7.10);
That could be related. I would suggest to update.
btw, everything works with ingress-filtering=yes on the bridge port in my case.
That is good news! It might have been broken when I put things together, let me see if I have some time next week to do new tests in 7.11/7.12 and update the guide.
Hw. Offload. stays on when I start the container. At least the indicator is there near each bridge port except for the veth1.
Also, CPU load stays very low - 1-2%, so it does not seem that it tries to process packets in software at all.
Note, that i backed up my config to the start point
