Hi everyone, thanks for sharing, I put this setup in the routerboard, it works, but it doesn’t find the Sonos soundbar, it only finds all the chromecasts. any suggestions?
EDIT: Before going down the route below try the PIM-SM method 1st. http://forum.mikrotik.com/t/igmp-pim-with-sonos/166259/1
Have a look at the end of this: https://sonos.svrooij.io/sonos-communication Sonos uses SSDP not mDNS. I don’t have a Sonos to test this on but you could try add the line BEFORE the drop (so after the “Allow mDNS”). Here be dragons though, SSDP has issues concerning security and broadcast amplification. I expect the risk is low on a properly firewalled network.
/interface bridge filter
add action=accept chain=forward comment="Forward SSDP" dst-address=239.255.255.250/32 \
dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF dst-port=1900 \
ip-protocol=udp mac-protocol=ip out-bridge=BridgemDNS
Also add a NAT rule to for the SSDP packets:
/interface bridge nat
add action=src-nat chain=srcnat dst-mac-address=\
01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF to-src-mac-address=48:A9:8A:EF:61:03 \
comment="Use your primary bridge MAC address here"
From my other post about sending mDNS and SSDP over Wireguard I found that I had to make firewall rules to srcnat and dstnat the IP address to fool my SSDP device, MythTV, as it didn’t accept SSDP discovery traffic from subnets it wasn’t on for security reasons.
Thanks for replay but nor PIM-SM nor your filter rule solved my problem.
Plus i have noticed that bridge nat (mdns) has 0 Packets, is it normal?
EDIT:
My Bad! The app sonos is working, but i cannot discover the device from spotify, any help?
bridge nat rule is not working… here my firwall config.
Thanks
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment=\
"ONLY allow trusted subnet full access to router services" \
src-address-list=net_casa
add action=accept chain=input comment=PiHole dst-port=53,123 in-interface-list=\
LAN protocol=udp
add action=accept chain=input comment=PiHole dst-port=53 in-interface-list=LAN \
protocol=tcp
add action=drop chain=input comment="DROP ALL ELSE"
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=accept chain=forward comment="allow access to ALL DomusNET from LAN" \
dst-address-list=net_domus src-address-list=net_casa
add action=accept chain=forward comment=\
"allow access to ALL ControlNET from LAN" dst-address-list=net_control \
src-address-list=net_casa
add action=accept chain=forward comment=\
"allow access to ALL CasaNET from DOMUS" dst-address-list=net_casa \
src-address-list=net_domus
add action=accept chain=forward comment="allow access to PiHOLE" dst-address=\
192.168.55.55 in-interface-list=LAN
add action=drop chain=forward comment="BLOCK DOT and DOH" dst-address-list=\
DNS-DOH dst-port=443,853 protocol=udp src-address-list=filtered
add action=drop chain=forward comment="BLOCK DOT and DOH" dst-address-list=\
DNS-DOH dst-port=443,853 protocol=tcp src-address-list=filtered
add action=accept chain=forward comment="internet traffic" in-interface-list=\
LAN out-interface-list=WAN src-address-list=!net_control
add action=accept chain=forward comment="port forwarding" connection-nat-state=\
dstnat
add action=drop chain=forward comment="DROP ALL ELSE"
EDIT2:
HAPPY EASTER!
Has anyone managed to get spotify connect to work? Sonos and Chromecast apps work great. Thank you!
This says it uses mDNS.
https://developer.spotify.com/documentation/commercial-hardware/implementation/guides/zeroconf
Hi, I’m so sorry to bother you. I deleted everything and redid everything from the beginning. The filter and nat rules show packets now, so they are working. But I don’t have any discovery between vlans. Can you guide me where I can look to understand why it doesn’t work?
For your NAT rules what have you put as the SRCMAC address? Is the the MAC of the main VLAN filtered bridge?
Mine is 48:A9:8A:EF:61:03 as per the example. You must change this to yours.
Thanks for the reply, sorry if I cause you problems.
These are the configurations, BR-Capsman is my main filter bridge. In NAT rules put the MAC of the main bridge.
/interface/bridge/filter/ print
0 ;;; Allow mDNS only
chain=forward action=accept in-bridge=BR-mDNS out-bridge=BR-mDNS
dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF mac-protocol=ip
dst-address=224.0.0.251/32 src-port=5353 dst-port=5353 ip-protocol=udp
log=no log-prefix=""
1 ;;; Forward SSDP
chain=forward action=accept in-bridge=BR-mDNS out-bridge=BR-mDNS
dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF mac-protocol=ip
dst-address=239.255.255.250/32 dst-port=1900 ip-protocol=udp log=no
log-prefix=""
2 ;;; Drop all other L2 traffic
chain=forward action=drop in-bridge=BR-mDNS out-bridge=BR-mDN
/interface/bridge/nat/ print
0 ;;; mDNS - SNAT to Primary VLAN bridge
chain=srcnat action=src-nat to-src-mac-address=48:A9:8A:59:75:CC
dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF log=no
log-prefix=""
1 ;;; SSDP - SNAT to Primary VLAN bridge
chain=srcnat action=src-nat to-src-mac-address=48:A9:8A:59:75:CC
dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF log=no
log-prefix=""
/interface/macvlan/print
0 R macvlan100 1480 100-Casa BA:C9:E8:55:EE:D8 private
1 R macvlan400 1480 400-Domus C2:AB:7F:29:3C:40 private
/interface/bridge/port> print
0 H sfp-sfpplus1 BR-Capsman yes 1 0x80 10 10 none
1 IH ether8 BR-Capsman yes 1 0x80 10 10 none
2 veth-pihole BR-PiHole 1 0x80 10 10 none
3 macvlan100 BR-mDNS 1 0x80 none
4 macvlan400 BR-mDNS 1 0x80 none
/interface/bridge/ print
0 R ;;; Capsman
name="BR-Capsman" mtu=auto actual-mtu=1500 l2mtu=1514 arp=enabled
arp-timeout=auto mac-address=48:A9:8A:59:75:CC protocol-mode=rstp
fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m
priority=0x6000 max-message-age=20s forward-delay=15s
transmit-hold-count=6 vlan-filtering=yes ether-type=0x8100 pvid=1
frame-types=admit-all ingress-filtering=yes dhcp-snooping=no
port-cost-mode=short
1 R ;;; PiHole
name="BR-PiHole" mtu=auto actual-mtu=1500 l2mtu=65535 arp=enabled
arp-timeout=auto mac-address=5A:1A:EE:6D:F7:68 protocol-mode=rstp
fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m
priority=0x8000 max-message-age=20s forward-delay=15s
transmit-hold-count=6 vlan-filtering=no dhcp-snooping=no
port-cost-mode=short
2 R ;;; -mDNS
name="BR-mDNS" mtu=auto actual-mtu=1480 l2mtu=65535 arp=enabled
arp-timeout=auto mac-address=BA:C9:E8:55:EE:D8 protocol-mode=none
fast-forward=yes igmp-snooping=no auto-mac=yes ageing-time=5m
vlan-filtering=no dhcp-snooping=no port-cost-mode=long
In devices supporting l2hw for VLAN filterig, using bridge rules disables l2hw. Depending on the device and network topology, this might be an issue or not.
For simple setups were it is only about getting mDNS and/or UPnP passed between two different L3 routed VLANs, switch rules also work and are HW based, working with enabled l2hw on supported devices.
An example for RB5009, with ether5 and ether6 as untagged members of different VLANS (L3 routing with firewalling on CPU, isolated on L2)
/interface/ethernet/switch/rule add comment=mDNS copy-to-cpu=yes dst-address=224.0.0.251/32 dst-mac-address=01:00:5E:7F:FF:FB/FF:FF:FF:FF:FF:FF dst-port=5353 mac-protocol=ip new-dst-ports=ether5,ether6 ports=ether5,ether6 protocol=udp switch=switch1
This forwards mDNS messages on L2. Multicast address range 224.0.0.x is linklocal and is explicitly not meant to be routed on L3. So some L3 services rightfully do not forward them, even if configured to do so.
It is less flexible than the solutions above and only works for certain setups and devices supporting switch rules. It also might be obscure as it is only visible in switch rules and nowhere else.
But where it is good enough, its simple and fully HW based.
That’s a good point on this approach, you could do this in a switch rule for L2HW.
Now the obscurity is more that requires understanding BOTH the bowels of multicast & also low-level details of L2HW offloading … than config location 
.
in log ho NAT Rules i have this:
Hello again!
In log of NAT Rules i have this:
NAT mdns srcnat: in:(unknown 0) out:macvlan400, connection-state:invalid src-mac MAC DEVICE, dst-mac 01:00:5e:00:00:fb, eth-proto 0800, UDP, 192.168.0.60:5353->224.0.0.251:5353, len 121
NAT mdns srcnat: in:(unknown 0) out:sfp-sfpplus1, connection-state:invalid src-mac 48:a9:8a:59:75:cc, dst-mac 01:00:5e:00:00:fb, eth-proto 0800, UDP, 192.168.0.60:5353->224.0.0.251:5353, len 121
NAT ssdp srcnat: in:(unknown 0) out:macvlan400, connection-state:invalid src-mac MAC DEVICE, dst-mac 01:00:5e:7f:ff:fa, eth-proto 0800, UDP, 192.168.0.10:49012->239.255.255.250:1900, len 129
NAT ssdp srcnat: in:(unknown 0) out:sfp-sfpplus1, connection-state:invalid src-mac 48:a9:8a:59:75:cc, dst-mac 01:00:5e:7f:ff:fa, eth-proto 0800, UDP, 192.168.0.10:49012->239.255.255.250:1900, len 129
Vlan100 has dhcp 192.168.0.1/24
Vlan400 has dhcp 192.168.240.1/24
Is this the problem?
Thanks
EDIT:
I noticed that if I have this rule in the firewall filter (along with the two (SSDP NAT and FORWARD SSDP):
chain=forward action=accept connection-state=invalid src-address-list=vlan400 dst-address-list=vlan100 log=no log-prefix=“”
Sonos APP works, if i disable it sonos app stop working (sonos devices are in vlan400), control device is in vlan100
Thanks so much for posting your experience.
I’ve been wanting to tackle this for a year. This week I started developing a routing daemon in Rust to solve this specifically for MikroTik via containers. I made some progress with my daemon, but multicast programming seemed opaque to a sockets newbie like me and I see why the Go codebase mentioned in this thread just used a PCAP library rather than fussing with multicast routing on Linux interfaces.
The MACVLAN approach was going to be fewer lines of config without even considering Docker storage and building a daemon, so I tried your approach and got the kinks worked out (forgot L2 nat at first). One of my devices appears sluggish to show up in as an AirPlay sink, but it sure works now and the inter-vlan DJ battles will begin 
Thanks again!
Thanks so much for posting your experience.
No problem. It always bugged me that there might be a way with bridge filtering but I didn’t really try it until I needed it. It’s always been possible so long as the VLAN interfaces didn’t have an IP address assigned so you’d have to run it on a 2nd Mikrotik ROS device apart from the main router. The addition of MACVLAN interfaces now completes the solution and is probably an unintended benefit.
Mikrotik may come out with an mDNS repeater of some kind in the future. It could possibly be done in PIM-SM by allowing the mDNS subnet to be relayed by PIM-SM (it seems to be deliberately excluded) but that’d probably cause some blood vessels to burst in some foreheads. I can’t see any downsides with this bridge method apart from maybe needing some GUI sugar. You can use the extra bridge rule options to rate limit the mDNS packets, enforce time of day enabling and using the SRC MAC address only allow some devices on the other side of the bridge to have their response to mDNS queries get back to the queriers VLAN.
I have my jellyfin server running on a pc, and I’d like to get it to stream its media content to my smartTV which has no jelly app, but just a basic dlna client. The server and the tv are on different VLANs
As far as you know, which of the above setups would make my jellyfin server communicate with the client?
Thanks
I have my jellyfin server running on a pc, and I’d like to get it to stream its media content to my smartTV which has no jelly app, but just a basic dlna client. The server and the tv are on different VLANs
With DLNA that’d likely be SSDP, so try the SSDP forward rules along with (or instead of if you don’t need it) the mDNS rule. Just be mindful that some DLNA systems may not work if any communications come from a subnet they aren’t a member of - you’ll have to add some NAT rules in the firewall to handle it. I had to do this for MythTV to work. See my other posts about getting mDNS working over Wireguard and EoIP.
Please, let me check if I got it right.
Do I need to create another Bridge first, then set this up?
/interface bridge
add name=BridgemDNS protocol-mode=none
/interface macvlan
add interface=VLAN100 name=macvlan100
add interface=VLAN101 name=macvlan101
/interface bridge filter
add action=accept chain=forward comment="Allow mDNS only" 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 in-bridge=BridgemDNS ip-protocol=udp \
mac-protocol=ip out-bridge=BridgemDNS src-port=5353
add action=drop chain=forward in-bridge=BridgemDNS comment="Drop all other L2 traffic" \
out-bridge=BridgemDNS
/interface bridge filter
add action=accept chain=forward comment="Forward SSDP" dst-address=239.255.255.250/32 \
dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF dst-port=1900 \
ip-protocol=udp mac-protocol=ip out-bridge=BridgemDNS
/interface bridge nat
add action=src-nat chain=srcnat dst-mac-address=\
01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF to-src-mac-address=48:A9:8A:EF:61:03 \
comment="Use your primary bridge MAC address here"
/interface bridge nat
add action=src-nat chain=srcnat dst-mac-address=\
01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF to-src-mac-address=48:A9:8A:EF:61:03 \
comment="Use your primary bridge MAC address here"
A couple of things if you don’t mind?
Where does 01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF come from?
Is 48:A9:8A:EF:61:03 the mac address of the first bridge?
Thanks again
You do need to create a 2nd bridge for reflecting the mDNS and SSDP frames between VLANs.
\
Where does 01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF come from?
This is the SSDP multicast frame.
Is 48:A9:8A:EF:61:03 the mac address of the first bridge?
Yes, that address is MY bridge here so you need to replace that with YOUR main bridge MAC address. What happens with the SRCNAT is that the multicast frame when it’s essentially copied onto the new VLAN it must have a MAC that exists on that VLAN which can be the main bridge. The device that emitted the original frame doesn’t exist on that new VLAN.
I gave it a try, but it didn’t work in my case
This worked perfectly for me to bridge my wifi vlan and wired vlan for mDNS on a RB4011 … that is – it probably would work if I had the latest version of routerOS.
in 7.11.2, there’s no macvlan support and I wind up with a bridge slave issue that makes it so that the two VLANs I want mDNS traffic to cross end up with broken DHCP servers