I have tested this macvlan method and it works fine for my mDNS needs. Now that Mikrotik has come out with their (so far) simplistic solution, I have been using that. I have limited my input firewall rule on my IoT VLAN (Airplay, Airprint and Roku/Samsung devices) to only those specific IP addresses and only if dst-address is 224.0.0.251. I believe this is equivalent to limiting this macvlan approach to the mac addresses of the devices, but would welcome any advice on that front.
Given that Mikrotik has a solution that works on my router, is there any good reason to use this macvlan approach or even a container solution?
My understanding is that PIM-SM, which I have working for IPv4/IPv6, does not handle mDNS traffic.
I haven’t tried the beta and the new mDNS repeater yet. Using the firewall rules to limit which devices can have their multicasts relayed across the VLANs seems perfectly fine though. PIM-SM in my testing seems to deliberately EXCLUDE mDNS packets which is the point of it as mDNS traffic is link-local meaning it’s never intended by convention to go beyond the subnet it’s broadcasting on. mDNS repeating breaks this convention but it’s really convenient in some situations.
Mikrotik could expand the scope of the repeater function and allow you to define other multicast destination IP & MAC addresses to allow other link-local multicast protocols to go beyond their subnet like SSDP and HD-Homerun as suggested above. If they don’t end up doing that you’ll need to use the MACVLAN method.
Using a container now for mDNS repeating is doing things the hard way unless the software does more than just repeating and some filtering. I saw on one YT video there are commercial mDNS repeaters that sound like they do some smarts and aggregate or proxy mDNS to keep the traffic levels down which is definitely important on large networks.
The MT mDNS proxy covers my AirPrint, Airplay, Sony TV and Roku devices.
It’s strange. With mDNs proxy turned off, my Apple Music app still shows the two Rokus. But clicking on them doesn’t make a connection. I would have thought showing up meant some protocol that can cross VLANs, but maybe a firewall issue that doesn’t allow traffic to pass in whatever direction it needs to pass to actually connect?
ROS 7.16RC onwards now supports mDNS repeating with the option in the DNS command - eg:
Look in the DNS section of Winbox (which shows it is an option in the DNS command, not a distinct command by itself - /ip/dns set mdns-repeat-ifaces=VLAN191,VLAN200,… etc)
It’s not documented as of writing so might change a bit. So for basic mDNS repeating you don’t need a container or this bridge method. For now if you want to filter certain mDNS MAC addresses or you want to repeat other link-local protocols like SSDP then bridge filtering is a good option.
I think same “regular NAT” /ip/firewall/nat may be a little simpler - you should be able change to port to 65001 from the example. Cannot say it will work for HDHomerun, but easy thing to try.
7.16rc4 was released on 2024-Aug-30, about roughly a week ago… i can’t wait to see 7.16 come out to check it out. I have all my smarthome devices (including Home Assistant server and all ESPHome nodes) in a dedicated vlan, and if this works, then the “Visit” function of ESPHome web ui will be usable. Currently i dig up IP address of the sensor if i need to.
LG TV seems to use both mDNS and SSDP. For the YouTube discovery to work between VLANs (phone on vlan_x, tv on vlan_y), macvlan trick kinda works: I don’t need any bridge NATs, and I also don’t need mDNS. SSDP accept is enough. With a single accept rule for SSDP, my phone on vlan_x can discover tv on vlan_y.
BUT! TV wants to “join” my phone (vlan_y → vlan_x) which is by default I wish to keep disabled. TV uses randomized UDP ports (both src, and dst).
With a generic vlan_y → vlan_x drop, the phone can’t even discover the TV.
One more addition (still, phone and tv are on different VLANs, and goal is to cast YT from phone to TV, while generic communication is disabled from TV to phone).
Complete flow looks like this:
Phone=P
TV=T
Step1
P: SSDP, M-SEARCH* to 239.255.255.250
10ms delay
Step2
T: UDP, T->P, random ports, TV sends some metadata with its location: http://a.b.c.d:1898/ to the Phone
10ms delay
Step3
P: TCP, P->T, dstport==1898, get more info
Now, step2’s traffic is wished to be dropped in general: in case I drop it, Phone will have no idea where to go in step3, so step3 would never reached. In case I don’t drop it, casting works as intended.
Just wanted to thank you @UpRunTech for your guide. I have this now working on my home hAP ax3, being able to cast/stream from my phone on VLAN 1 to my TV (Chromecast) and AV receiver (Airplay) on VLAN 2.
I’ll include my configuration for anyone else who is trying to get Chromecast and Airplay to work.
# Create bridge
/interface bridge add name=bridge_mdns protocol-mode=none vlan-filtering=no
# Create bridge ports
/interface bridge port add bridge=bridge-mdns interface=macvlan_2
/interface bridge port add bridge=bridge-mdns interface=macvlan_1
# Create MACVLAN interfaces
/interface macvlan add interface=vlan_2 name=macvlan_2
/interface macvlan add interface=vlan_1 name=macvlan_1
# Bridge filters
# Only allow mDNS traffic from TV
/interface bridge filter add action=accept chain=forward in-bridge=bridge_mdns in-interface=macvlan_2 src-port=5353 src-mac-address=<MAC address TV>/FF:FF:FF:FF:FF:FF out-bridge=bridge_mdns dst-address=224.0.0.251/32 dst-port=5353 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF ip-protocol=udp mac-protocol=ip comment="accept mDNS traffic from MACVLAN 2 - TV"
# Only allow mDNS traffic from AV receiver
/interface bridge filter add action=accept chain=forward in-bridge=bridge_mdns in-interface=macvlan_2 src-port=5353 src-mac-address=<MAC address AV receiver>/FF:FF:FF:FF:FF:FF out-bridge=bridge_mdns dst-address=224.0.0.251/32 dst-port=5353 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF ip-protocol=udp mac-protocol=ip comment="accept mDNS traffic from MACVLAN 2 - AV receiver"
# Allow mDNS traffic from phone (required, else AirPlay will not work)
/interface bridge filter add action=accept chain=forward in-bridge=bridge_mdns in-interface=macvlan_1 src-port=5353 src-mac-address=<MAC address phone>/FF:FF:FF:FF:FF:FF out-bridge=bridge_mdns dst-address=224.0.0.251/32 dst-port=5353 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF ip-protocol=udp mac-protocol=ip comment="accept mDNS traffic from MACVLAN 1 - Phone"
# Drop other mDNS traffic
/interface bridge filter add chain=forward action=drop in-bridge=bridge_mdns out-bridge=bridge_mdns comment="drop all"
# NAT between bridges
/interface bridge nat add chain=srcnat action=src-nat dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF to-src-mac-address=<MAC address of main brige> comment="NAT traffic between mDNS bridge and main bridge"
# Allow connection state "new" from VLAN 1 to VLAN 2 TV (required, else mDNS will not work)
/ip firewall filter add chain=forward action=accept connection-state=new in-interface=vlan_1 out-interface=vlan_2 dst-address=<IP address of TV> comment="accept new traffic from VLAN 1 to VLAN 2 - TV"
# Allow connection state "new" from VLAN 1 to VLAN 2 AV receiver (required, else mDNS will not work)
/ip firewall filter add chain=forward action=accept connection-state=new in-interface=vlan_1 out-interface=vlan_2 dst-address=<IP address of AV receiver> comment="accept new traffic from VLAN 1 to VLAN 2 - AV receiver"
No worries. Just remember the next release of ROS has a mDNS repeater built in via IP->DNS so you don’t need this bridge filter stuff for mDNS. I am using it at some sites and it seems to work just fine. BUT if you need certain frames repeated between VLANs that are NOT mDNS or can’t be relayed by PIM-SM this method is your, um, man.
This domain still feels like black magic for the most part for me, so please pardon my ignorance. I’m looking at 2 scenarios, and am wondering if this is the solution for me. This is for a home network with multiple VLANs. I should also say I don’t particularly care about mDNS specifically, as I run and use internal DNS. Heavy IoT user though.
Part 1: A general reflector
I have a trusted VLAN on which I host our computers, tablets, phones, tv, etc. I would like all Bonjour/zeroconf/etc. traffic to be reflected from that VLAN into the IoT network (or even better: specifically to the Home Assistant host!) so that Home Assistant can auto-discover things and interact. For a solution, I could set up an avahi reflector container. But I’m wondering if the config listed a few posts higher can be adapted to fill this requirement. I’m guessing everything above ‘bridge filters’ is needed, but beyond that I get lost.
Part 2: A specific reflector
I also have a guest VLAN where guests connect their mobile devices when they visit us. I would like those clients to be able to stream AirPlay and use our printer. For this, I have already setup this Bonjour reflector which does indeed reflect messages from the trusted into the main VLAN but I’m struggling getting it to work. I went the route of poking IP holes in my firewall for everything I found in the Bonjour messages, but it is still not working. I’m pretty sure again this setup can be used for my use case, but I am not sure how this would all work.
I’m sorry if this is a bit general. Happy to provide further details, but not sure what would make sense … and don’t want a 3-page post that nobody reads!
I think that the setup with MACVLANs could be used to realise your scenarios. In my mind it could look something like this.
Scenario 1
Create 2 MACVLANs: one for the home VLAN and one for the IoT VLAN.
You want to reflect the mDNS from the home MACVLAN to the IoT MACVLAN, which means you need to add a bridge filter to allow mDNS traffic from the home MACVLAN onto the IoT MACVLAN.
Add firewall filters to the main bridge to allow “new” connection states between the VLANs.
Draft of possible configuration:
# Create bridge
/interface bridge add name=bridge_mdns protocol-mode=none vlan-filtering=no
# Create bridge ports
/interface bridge port add bridge=bridge-mdns interface=macvlan_iot
/interface bridge port add bridge=bridge-mdns interface=macvlan_home
# Create MACVLAN interfaces
/interface macvlan add interface=vlan_iot name=macvlan_iot
/interface macvlan add interface=vlan_home name=macvlan_home
# Bridge filters
# Allow mDNS traffic
/interface bridge filter add action=accept chain=forward in-bridge=bridge_mdns src-port=5353 out-bridge=bridge_mdns dst-address=224.0.0.251/32 dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF dst-port=5353 ip-protocol=udp mac-protocol=ip comment="accept mDNS only"
# Drop other mDNS traffic
/interface bridge filter add chain=forward action=drop in-bridge=bridge_mdns out-bridge=bridge_mdns comment="drop all"
# NAT between bridges
/interface bridge nat add chain=srcnat action=src-nat dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF to-src-mac-address=<MAC address of main bridge> comment="NAT traffic between mDNS bridge and main bridge"
# Allow connection state "new" from VLAN IoT to VLAN home (required, else mDNS will not work)
/ip firewall filter add chain=forward action=accept connection-state=new in-interface=vlan_iot out-interface=vlan_home comment="accept new traffic from VLAN IoT to VLAN Home"
If this works, then you can consider finetuning the bridge filters to only allow mDNS traffic from certain devices (similar to the configuration that I shared a few posts earlier).
Scenario 2
This scenario is similar to scenario 1. As far as security goes, I don’t know if you would want to add the required bridge filters to the same mDNS bridge or create another mDNS bridge to isolate the traffic.
Thanks for sharing the configuration. Please allow me to ask a few questions to better my understanding:
I don’t really understand why this mixes both layer 2 and layer 3 stuff. Is this purely because the interfaces and bridge do not have an IP address and thus layer 2 becomes the way source and destination is defined? Or is there a different reason for it? But then also, why can’t this happen at the layer 3 level? Does multicast require layer 2 to work at all?
What are the security implications? At the moment, I do allow new home → IoT connections but not the reverse. I assume this setup does not create an alternative route through the new bridge where traffic can seep through other than whatever I add using accept bridge filters?
I just learned mDNS is not just to resolve hostname.local to an IP address but in fact all the messages I see when I run avahi-browse are collectively called mDNS!!?
Is the proposed setup here something that can be generically looked at for other zeroconf setups, and for example SSDP can also be implemented? I ask, because in my configuration this may be important to support as well as I split my devices off into multiple VLANs.
Thanks everyone for your patience with these undoubtedly silly questions for those more knowledgeable. As I said … this is all sorcery for me!
I have the 7.16 mDNS repeater working fine on my router. Does anyone know if it will work with IPv6? In my MDB table (PIM SM set up) I show my VLANs with ff02::fb entries, but I can’t figure out the proper firewall wall rules to get any packets to go through.
In IPv4 I have input firewall rules for source port 5353, udp, dst address 224.0.0.251 and my VLAN/IP addresses that I want to have access to mDNS and it works very well.
I tried similar rules in IPv6 but with dst address ff02::fb.
No packets come through.
IPv6 otherwise seems to be working well for me - I am not an IT guy, but have worked through the forum and other sources to get a decent Mikrotik configuration set up.
