mDNS between VLANs with just bridge filters - Look Mum, no containers!

UpRunTech · Thu Feb 01, 2024 10:54 pm

[EDIT this was my initial version but is superseded by the MACVLAN version below]

I had an issue on a site where I needed devices on VLAN2 to see Chromecasts, AppleTV's and Airprint on VLAN1. Taking some ideas I had while formulating the post about mDNS on Wireguard I tried it out. Apparently Mikrotik have a solution for mDNS in ROS they are still cooking up so we'll have to wait; until then...

I have a CRS354 switch on site doing IGMP snooping and a router doing PIM-SM and of course this doesn't help for mDNS between VLANs. I also have some hEX's acting as managed switches (using VLAN-filtering) in some rooms so I tried this on a hEX:

* hEX has a VLAN-filtered bridge with VLAN1 and VLAN2 with these tagged on Eth1 and untagged on the other ports as needed.
* Created a new bridge called BridgemDNS.
* Create 2 VLAN interfaces (VLAN1 and VLAN2) whose parent is the main VLAN filtered bridge.
* Put the ports for the VLANs onto the new bridge and do some filtering.

/interface bridge
add name=BridgemDNS protocol-mode=none

/interface bridge port
add bridge=BridgemDNS frame-types=admit-only-untagged-and-priority-tagged \
    interface=VLAN1 pvid=1001
add bridge=BridgemDNS frame-types=admit-only-untagged-and-priority-tagged \
    interface=VLAN2 pvid=1001

/interface bridge vlan
add bridge=BridgemDNS untagged=VLAN1,VLAN2 vlan-ids=1001

/interface bridge filter
add action=accept chain=forward comment="Allow 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 in-bridge=BridgemDNS ip-protocol=udp \
    mac-protocol=ip out-bridge=BridgemDNS src-port=5353
add action=drop chain=forward in-bridge=BridgemDNS \
    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=CC:2D:E0:14:64:AD

So you can see in the 1st part the new bridge is created and VLAN ports set up to join it using a PVID of 1001. This way the layer 2 traffic from VLAN1 and VLAN2 will be connected. It's vitally important that the drop filter rule is there to block all the L2 traffic flowing both ways which would create havoc. The rule before the drop is the magic one that lets mDNS traffic through only, after that the drop rule blocks all other traffic.

Nothing seemed to happen at this point until I did a SRCNAT on the MAC address of frames being sent out using the MAC address (CC:2D:E0:14:64:AD) of the main VLAN-filtered bridge (not the mDNS bridge). I think has to do with IGMP snooping and traffic flooding egress on ports and making sure the MAC is known on that network.

So this seemed to work and mDNS broadcast traffic flowed both ways. The network through the main router allows traffic initiated from VLAN2 to go to VLAN1 so Airplay worked when I connect a Macbook on VLAN2 to an AppleTV on VLAN1.

I did another test to see if I could just allow certain mDNS traffic across.

/interface bridge filter
add action=accept chain=forward comment="Allow mDNS VLAN1" \
    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 \
    in-interface=VLAN1 ip-protocol=udp mac-protocol=ip \
    out-bridge=BridgemDNS src-mac-address=34:FD:6A:03:A1:8B/FF:FF:FF:FF:FF:FF \
    src-port=5353

add action=drop chain=forward comment="Drop all other mDNS from VLAN1" \
    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 \
    in-interface=VLAN1 ip-protocol=udp mac-protocol=ip \
    out-bridge=BridgemDNS src-port=5353
    
add action=accept chain=forward comment="Allow 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 in-bridge=BridgemDNS ip-protocol=udp \
    mac-protocol=ip out-bridge=BridgemDNS src-port=5353

add action=drop chain=forward in-bridge=BridgemDNS \
    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=CC:2D:E0:14:64:AD

* The 1st filter rule lets only mDNS traffic from VLAN1->2 across if the SRCMAC is 34:FD:6A:03:A1:8B which is a particular AppleTV.
* The next rule drops all other mDNS traffic from VLAN1->2.
* The third rule then allows any remaining mDNS traffic which will only be VLAN2->1 and finally the main drop rule to block everything else getting across either way and the MAC SRCNAT.

The Macbook at this point could then only see the one AppleTV device and the Airprint printer became unavailable.

I am still testing this out but it seems solid enough. I didn't assign any IP addresses to the VLAN interfaces. There might be unintended consequences to doing this even though the packet flow maps shows bridge packets will get handled before IP.

I'd suggest trying this out on an independent Routerboard device on your network as I have and not your main router and switches.

Amm0 · Thu Feb 01, 2024 11:37 pm

Great work! Very Cleaver. You've been at this problem for a while now

.

Very minor nit on the example. The BridgemDNS is a "dumb" switch (e.g. vlan-filtering=no). And maybe the :export does this, but the frame-types & pvid & VLAN assignment should NOT be needed (and do nothing):

/interface bridge port
add bridge=BridgemDNS frame-types=admit-only-untagged-and-priority-tagged \
interface=VLAN1 pvid=1001
add bridge=BridgemDNS frame-types=admit-only-untagged-and-priority-tagged \
interface=VLAN2 pvid=1001
/interface bridge vlan
add bridge=BridgemDNS untagged=VLAN1,VLAN2 vlan-ids=1001

But I like this approach & on a hEX... you don't have the option of containers...

UpRunTech · Thu Feb 01, 2024 11:43 pm

I always figured there was a way to do mDNS reflecting with bridge filters. Bridge filters are a really useful tool and they have solved some tricky problems for me before.

I'll disable the VLAN 1001 stuff later and see what happens. As you say, could be vestigial at this point and removed.

I will add that enabling a bridge filter may well disable any hardware switching so be warned! It's not an issue for a device like a hEX which usually is doing everything in software anyway. I think there are low complexity cases on a hEX where the bridge is happy to let the switch chip do the leg work.

UpRunTech · Tue Feb 13, 2024 10:05 pm

I was tooling through the Help as it likes to change unannounced from time to time and I noticed and read about MACVLAN. Of course it's been around a few months as a tab in Winbox but I never looked into it. This interface solves the problem of being able to do this bridge filtering technique BUT ON YOUR MAIN ROUTER. No offsider router like I used in the OP.

The cool thing about MACVLAN it it gives you another MAC address and interface endpoint hanging off an existing ethernet or VLAN interface. This is just awesome because until now you couldn't add another VLAN interface to a bridge with the same VLAN ID.

My main VLAN is 100 and a test VLAN is 101. I joined MACVLAN interfaces to each VLAN interface and added an mDNS bridge from above. Voila, it works. My phone on 101 can now see the Chromecast on 100 and control it.

* I have VLAN100 and VLAN101 interfaces with their subnet IP addresses and normal L3 routing and filtering - this is where all the main traffic goes between a device and the CC after discovery. I had to disable the DROP rule I had that blocked traffic non-established and related traffic between 101 -> 100.
* I added MACVLANs to each VLAN and joined them on a common (non-VLANed) bridge with bridge filtering. Bridge NAT will make sure the source MAC address is valid on that segment.
* Just to be clear, my main bridge which the VLAN interfaces hang off is VLAN-filtered.

/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 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"

* The thing about this technique is you don't need a container running some reflector like Avahi and it'll work even on the puniest SMIPS device.
* You can make bridge filter rules that block certain MAC addresses (so you can just allow the mDNS ads from only a printer and not your other gadgets for example).
* Technically it's more efficient than a container as you obviously don't need the resources of a container, but mainly all the packet management is done in kernel space rather than user space.

Can you add more VLANs into the mix? It's untested but why not? All you need to do is add another MACVLAN interface to the additional VLANs. If you're keen you can make certain ACCEPT/DROP rules that only allow particular MACs to traverse between particular VLANs by adding rules with in-interface and out-interface.

qqflexx · Sun Mar 03, 2024 11:26 am

I was tooling through the Help as it likes to change unannounced from time to time and I noticed and read about MACVLAN. Of course it's been around a few months as a tab in Winbox but I never looked into it. This interface solves the problem of being able to do this bridge filtering technique BUT ON YOUR MAIN ROUTER. No offsider router like I used in the OP.

This really works. Very eloquently elegant compared to container (no dependency on third-party software). Thank you!

/interface macvlan add interface=vlan10 name=macvlan10
/interface macvlan add interface=vlan80 name=macvlan80

/interface bridge add name=bridge-mdns protocol-mode=none
/interface bridge port add bridge=bridge-mdns interface=macvlan10
/interface bridge port add bridge=bridge-mdns interface=macvlan80

/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=bridge-mdns ip-protocol=udp mac-protocol=ip out-bridge=bridge-mdns src-port=5353
/interface bridge filter add action=drop chain=forward in-bridge=bridge-mdns out-bridge=bridge-mdns comment="Drop all other L2 traffic"

/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=[/interface bridge get [find name="bridge"] mac-address] comment="SNAT to Primary VLAN bridge"

Is there any (unintended?) downside doing it this way?

UpRunTech · Sun Mar 03, 2024 1:12 pm

Is there any (unintended?) downside doing it this way?

So far I don't think so, I am happy to hear arguments against doing it this way though. I can only think of a misconfiguration or getting the last drop rule wrong (or disabled) causing issues.

DarkNate · Sun Mar 03, 2024 2:40 pm

Looks hacky to me. Why not just use PIM-SM? I've shared PIM-SM config sample on this forum a few times, works on ROS v7 latest stable.

S8T8 · Sun Mar 03, 2024 3:21 pm

Hi DarkNate, I tested your suggestion about PIM-SM but was not working with printers, Chomecast, etc…
Support said that we need multicast repeater (will paste their answer if needed).
It should work for you?

DarkNate · Sun Mar 03, 2024 5:58 pm

Hi DarkNate, I tested your suggestion about PIM-SM but was not working with printers, Chomecast, etc…
Support said that we need multicast repeater (will paste their answer if needed).
It should work for you?

Share support's full reply. I don't know MikroTik multicast inter-VLAN routing is so messy.

S8T8 · Sun Mar 03, 2024 9:59 pm

...

/routing pimsm instance add name="PIM-SM" disabled=no [+ Bridge set multicast-querier=no]
/routing pimsm interface-template add instance="PIM-SM" interfaces=LAN-VLAN,IoT-VLAN source-addresses=10.0.3.60

are those two lines of code enough to find the printer connected in IoT-VLAN with IP 10.0.3.60 from LAN-VLAN ?

mDNS cannot be routed between networks using IGMP proxy or PIM, because it uses link-local (non-routable) multicast destination IP address.
And RouterOS natively does not support mDNS proxy, unfortunately.

UpRunTech · Sun Mar 03, 2024 10:34 pm

Looks hacky to me. Why not just use PIM-SM? I've shared PIM-SM config sample on this forum a few times, works on ROS v7 latest stable.

PIM-SM won't pass IPv4 mDNS. Lord knows I have tried to force it to no avail. PIM-SM works fine for a Chromecast as it uses mDNS and discovery compatible with PIM-SM but I could not get other devices discovered like such as a printer and Airplay. I have had PIM-SM working on VLAN systems and across Wireguard and Zerotier links. In all cases unless I set up something with bridge filtering like my other Wireguard/EoIP example and now this with MACVLANS the IPv4 mDNS traffic can't get across.

Is it hacky? I don't think so for small situations at least with only a handful of VLANs which let's face it, is 90%+ of interested users here. I would be very wary of using it on larger sites with large volumes of mDNS traffic without being selective with MAC filtering and rate limiting in the bridge filter rules.

Until Mikrotik spins up something in ROS that does mDNS repeating this is all there is unless you start to get containers involved which is only limited to ARM and x86 devices.

DarkNate · Mon Mar 04, 2024 2:24 pm

Anyone played with this?

https://help.mikrotik.com/docs/display/ ... t+Protocol

UpRunTech · Mon Mar 04, 2024 10:35 pm

Anyone played with this?

https://help.mikrotik.com/docs/display/ ... t+Protocol

Thanks for your suggestion. 224.0.0.0/24 doesn't appear to work even when added to GMP probably due to the 2nd paragraph in https://www.iana.org/assignments/multic ... sses.xhtml.

I could be in error, not the 1st time. You're the protocol expert in this forum though. Tell me what I am doing wrong.

DarkNate · Tue Mar 05, 2024 9:10 am

Haha, I'm not an expert, unlike other wannabe-experts in this forum or industry in general, I'm just a guy who loves to play with networks.

I'm not sure why it works or doesn't work, yet, haven't had time to deep dive into multicast routing. But I do hope, someone with time can properly build a “clean” solution for inter-VLAN multicast routing and “clean” way to do mDNS/link-local multicast across VLANs.

Or maybe, mDNS/multicast discovery IPv6 specs could be updated through the IETF in the future, to allow an official inter-VLAN routing flag or procedure with proper security measures in place at the protocol level. To my knowledge, such a thing doesn't exist yet.

UpRunTech · Tue Mar 05, 2024 12:04 pm

I put 224.0.0.251 into GMP and it does not show up in the MDB table in the switch.

I put 224.0.1.251, 224.1.1.251 and 224.1.0.251 into GMP at the same time and they *do* show up in the MDB table in the switch.

I am pretty sure Mikrotik are following convention and not allowing 224.0.0.0/24 to work with the PIM-SM and IGMP protocols. I did ask them to break convention and have a flag to allow it with PIM-SM and got no reply yet.

The scope of the experiments I have done with mDNS and the bridge filter technique only covers IPv4, not IPv6 (and it's ff02::fb address) as most people, including myself, seem to be eschewing IPv6 routing for now and most mDNS is still on IPv4.

I suspect any luck you have had with PIM-SM and mDNS is that you are routing IPv6 and ff02:fb is working for you and your devices that use IPv6 for mDNS.

As for the bridge filter technique, the most basic version here should reflect mDNS between member ports on the mDNS bridge and in effect really isn't different to some of the user space programs like https://github.com/Gandem/bonjour-reflector/ that just copy the packets between VLANs on a single ethernet interface.

I am no Go expert but on reading the code Bonjour-reflector (B-R) project checks the DNS QR flag in the body of the packet and floods it to all the known device origin VLANs in the .toml file. If the QR flag is not set it will check the SRC MAC of the packet and flood it only to valid VLANS defined for a valid device MAC.

Bridge-filter (B-F) cannot check for this QR flag and will flood all interfaces in the bridge with an mDNS packet.
B-R can only deal with VLANs but B-F will work with any kind of interface that can be a port member of a bridge, not just VLANs.
B-F can also be fine grained by only allowing certain SRCMACs to get though and (untested) possibly only allow SRCMACs out on limited bridge ports using interface lists.

B-R also rewrites the source MAC address of the packet to that of the ethernet interface it's being reflected out on. The bridge filter technique does the same by SRCNATing the packet with the MAC address of the *main* bridge (not the mDNS bridge).

Looking at the ROS bridge filter options you could make it more fine grained too by setting filter rules that allow or deny based on:
* Traffic between particular interfaces with In and Out Bridge List (using interface lists)
* SRC MAC addresses
* Packet marks
and by the looks of it be able to control the rate too which B-R can't do.

What I am getting at is the B-F method can do the same thing as B-R with some additional rules but without the headache of containers and it's ROS native.

DarkNate · Tue Mar 05, 2024 2:00 pm

I suspect any luck you have had with PIM-SM and mDNS is that you are routing IPv6 and ff02:fb is working for you and your devices that use IPv6 for mDNS.

Yes, all my home networks/devices and production network are 100% IPv6-enabled/deployed/only/mostly.

I stopped wasting my time on legacy IPv4 years ago. I would suggest you play with IPv6 multicast routing going forward. IPv4 should, one day, be removed from the network stack.

mozerd · Tue Mar 05, 2024 2:06 pm

I stopped wasting my time on legacy IPv4 years ago. I would suggest you play with IPv6 multicast routing going forward. IPv4 should, one day, be removed from the network stack.

While I agree with your sentiments wholeheartedly MANY ISP's still do not support ipv6 .... very sad to say .... My old ISP [Rogers] did suuport ipv6 but my new ISP [Bell] does not so far. I am hopefull the my new ISP will have a change of heart considering the fact that the US Gov has mandated that all of its communications will be ipv6 by 2025.

DarkNate · Wed Mar 06, 2024 8:32 am

mDNS uses link-local IPv6…

donkeyKong · Tue Mar 12, 2024 12:20 am

Just tested it with my home setup. 3 different VLANs and it works perfectly. I got rid of a small VM running Avahi to do the same thing.

jlpedrosa · Tue Mar 19, 2024 4:06 am

@UpRunTech

you mention: "Just to be clear, my main bridge which the VLAN interfaces hang off is VLAN-filtered."

What do you mean by "my main bridge", I have a router with multiple interfaces and each interface goes to a switch, I don't have any other bridge. Not sure if you could lend me a hand. I tried using your aproach with a single bridge, but.... No Way Jose.

Thanks in advance

Kataius · Sat Mar 30, 2024 9:34 pm

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?

UpRunTech · Sat Mar 30, 2024 10:06 pm

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. viewtopic.php?t=195714

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.

Kataius · Sat Mar 30, 2024 11:18 pm

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!

Kataius · Thu Apr 04, 2024 3:35 pm

Has anyone managed to get spotify connect to work? Sonos and Chromecast apps work great. Thank you!

UpRunTech · Sun Apr 07, 2024 6:51 am

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/documenta ... s/zeroconf

Kataius · Sun Apr 07, 2024 9:50 am

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?

UpRunTech · Sun Apr 07, 2024 11:41 am

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.

Kataius · Sun Apr 07, 2024 12:25 pm

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

jbl42 · Sun Apr 07, 2024 2:23 pm

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.

Amm0 · Sun Apr 07, 2024 5:39 pm

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

.

Kataius · Mon Apr 08, 2024 4:33 pm

in log ho NAT Rules i have this:

Kataius · Mon Apr 08, 2024 4:44 pm

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

evergreen · Sun Apr 14, 2024 11:03 pm

I was tooling through the Help as it likes to change unannounced from time to time and I noticed and read about MACVLAN. ... This interface solves the problem of being able to do this bridge filtering technique BUT ON YOUR MAIN ROUTER. ...

@UpRunTech

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!

UpRunTech · Mon Apr 15, 2024 3:00 am

@UpRunTech

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.

broderick · Tue Apr 30, 2024 9:45 pm

@UpRunTech

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

UpRunTech · Tue Apr 30, 2024 11:40 pm

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.

broderick · Wed May 01, 2024 1:17 pm

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

UpRunTech · Wed May 01, 2024 1:39 pm

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.

broderick · Wed May 01, 2024 3:55 pm

I gave it a try, but it didn't work in my case

virmaior · Tue May 07, 2024 1:50 pm

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

sulyak · Tue May 07, 2024 6:17 pm

This setup sounds interesting, but I'm having trouble setting up the basics even before the MAC VLANs. I'm quite new. How would I set up my tagged/untagged ports if I want to be able to use mDNS and SSDP between VLAN 40 and VLAN 1400? In my setup, I need a DHCP server on VLAN 40 and VLAN 1400 is a DHCP client that has a DHCP server on the main router that I do not control, but I know I receive mDNS and SSDP packets from it. I got it working by adding yet another RouterBoard running OpenWrt with Avahi-daemon and SMCRoute, but SMCRoute has not shown to be reliable.

I tried setting this up but ended up locking myself out when enabling VLAN filtering on the main bridge. What can I do from now? Is it possible to set up this with my situation with this second router that is not mine?

Kentzo · Tue May 07, 2024 8:43 pm

RouterOS really needs an mDNS solution out of the box (both as multicast and Wide Area Bonjour). These hacks that pop time to time are ridiculous, traps and troubles for novices that tarnish Mikrotik's reputation…

Simonej · Tue May 07, 2024 9:10 pm

This comment above should be pasted on every mDNS related topic.

Amm0 · Tue May 07, 2024 9:28 pm

RouterOS really needs an mDNS solution out of the box (both as multicast and Wide Area Bonjour).

Well the DNS-SD part could have been done by simply allowing a PTR RR in the /ip/dns/static YEARS ago. Being able to statically configure mDNS be useful, but cannot even do that. Frustrating.

Tue May 07, 2024 11:35 pm

RouterOS really needs an mDNS solution out of the box (both as multicast and Wide Area Bonjour). These hacks that pop time to time are ridiculous, traps and troubles for novices that tarnish Mikrotik's reputation…

100%

UpRunTech · Fri May 10, 2024 12:01 am

RouterOS really needs an mDNS solution out of the box (both as multicast and Wide Area Bonjour). These hacks that pop time to time are ridiculous, traps and troubles for novices that tarnish Mikrotik's reputation…

Sure. Of course no-one would look for ways to do this with containers or bridge-filter rules if there was a built in utility. As for hackiness the bridge-filter method is literally doing exactly what a user space program would do anyway (and probably run faster as it happens in kernel space) but you get to make this sausage yourself. Nothing wrong with that. Making your own sausages is what Mikrotik is about vs going to the supermarket and buying some ready made fancy looking overpriced red wine and garlic sausage that just ends up being full of gristle and repeating on you all day leaving you wondering just WTF is in it.

One quick way Mikrotik could make it work is to allow 224.0.0.251 to be relayed in PIM-SM. I have tried addresses 224.0.0.250 and 224.0.0.252 as static GMPs and they show up on the other routers UIB tables but not 224.0.0.251 - it's deliberately excluded by the looks of things. Allowing PIM-SM to deal with it may or may not work and probably would make some users here very, very angry (which we'd know about as they'd tell everyone) because it breaks some kind of standard.

Anyway, Mikrotik have mentioned somewhere a new DNS application is in the works and may have mDNS repeating in it - I am sure I saw it posted while ago. Until then...

Amm0 · Fri May 10, 2024 12:42 am

LOL re sausage analogy. I tend to agree your filter approach is doing what something in user space would do. So other than being more confusing than making a French Soufflé... it arguably faster than some built-in thing.

I have tried addresses 224.0.0.250 and 224.0.0.252 as static GMPs and they show up on the other routers UIB tables but not 224.0.0.251 - it's deliberately excluded by the looks of things. Allowing PIM-SM to deal with it may or may not work and probably would make some users here very, very angry (which we'd know about as they'd tell everyone) because it breaks some kind of standard.

That's actually odd that .250 and .252 show up. If one is pandemic about the specs, it's the entire 224.0.0 subnet that shouldn't be forwarded per the spec.
e.g. RFC-5771 says

4. Local Network Control Block (224.0.0/24)

Addresses in the Local Network Control Block are used for protocol
control traffic that is not forwarded off link. Examples of this
type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].

Kentzo · Fri May 10, 2024 12:47 am

IMHO Application-level problems need application-level solutions. I did not look into the mDNS spec sufficiently, but I would not take for granted that reflection does not involve some alteration of the packet under certain circumstances.

UpRunTech · Fri May 10, 2024 12:59 am

IMHO Application-level problems need application-level solutions. I did not look into the mDNS spec sufficiently, but I would not take for granted that reflection does not involve some alteration of the packet under certain circumstances.

Not all the user space mDNS repeaters do the same thing - some are pretty basic like AVAHI and other other one on Github I looked at does a SCRNAT modification on the MAC address too but it also inspects the packet to see if it's an originator or a replier which you can't do with Mikrotik bridge rules. I repeat myself, you can also use the bridge filter rules to only allow certain MACs to be repeated as well as rate limit and time-of-day limit them.

I think it's great you can make something like an mDNS repeater in Mikrotik from rules and interfaces. It's what all the levers and knobs are for and it'll work on any ROS device.

Amm0 · Fri May 10, 2024 1:06 am

I think it's great you can make something like an mDNS repeater in Mikrotik from rules. It's what all the levers and knobs are for.

True. But should still be built-in to /ip/dns stuff... And Mikrotik @normis said they're working on it & "be a while"... so we're 1 year into that, perhaps 2025 we'll see it

.

Kentzo · Fri May 10, 2024 1:52 am

As a SOHO user for almost a decade all deviations I saw were almost exclusively to circumvent RouterOS's mishaps. To that extent it's great that the OS allows for that. However, I personally want it to be easily configure to follow the RFC specs and best practices as precisely as possible.

For whistles you can always run a linux box and do your sockets raw.

Kataius · Tue Jun 11, 2024 5:01 pm

Hi, I managed to get everything working and it's great! Just one thing, I can't detect a device from one vlan to another with the device app...

if I go to the device's IP (192.168.240.161) I can easily access it, but if I try from its app it doesn't work...

I found this guide for other routers:
https://community.ui.com/questions/Howt ... b8f?page=1

as far as I understand it is enough to do a nat and mdns, but it doesn't work... who can help me?

my rules as well as macvlan are:

add action=dst-nat chain=dstnat comment=HDHomeRUN disabled=yes dst-port=65001 in-interface-list=LAN protocol=udp \
    src-address-list=net_casa to-addresses=192.168.240.161 to-ports=65001
add action=dst-nat chain=dstnat comment=HDHomeRUN disabled=yes dst-port=65001 in-interface-list=LAN protocol=tcp \
    src-address-list=net_casa to-addresses=192.168.240.161 to-ports=65001

Wed Jun 12, 2024 2:48 am

I think it's great you can make something like an mDNS repeater in Mikrotik from rules. It's what all the levers and knobs are for.
True. But should still be built-in to /ip/dns stuff... And Mikrotik @normis said they're working on it & "be a while"... so we're 1 year into that, perhaps 2025 we'll see it .

I suspect this will happen within the next few months.

UpRunTech · Thu Jul 04, 2024 12:08 am

Looks like you have been divining the tea leaves.

7.16 beta3 how has a shiny new mDNS repeater. Dunno if it's as choice as the bridge method.

*) dns - added support for mDNS proxy (CLI only);

Amm0 · Thu Jul 04, 2024 12:35 am

At present it seems bi-directional between all /ip/dns mDNS interfaces. So you can essentially create one mDNS zone for all specified interfaces. See viewtopic.php?t=208937&sid=84e0a0d1a322 ... 6cd1da7eef

So if you want to get fine grained in what's allowed or not allowed, that's not possible today. With bridge filters, you can get down to the MAC address of what's allowed or not.

Kataius · Sat Jul 06, 2024 3:06 pm

Hi everyone, I'm trying to set up an device with this method,

I found a guide in this forum, for a non-mikrotik device:
https://community.ui.com/questions/Howt ... b8f?page=1

But I think I didn't understand anything about how to set the rules with bridge filter...

Can someone either explain to me how to construct the rules or tell me where I'm going wrong?

I created the following rules:

/interface/bridge/filter/ print
Flags: X - disabled, I - invalid, D - dynamic 
 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="forward MDNS" 

 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="forward SSDP" 

 2  ;;; Forward HDHomeRun
     chain=forward action=accept in-bridge=BR-mDNS out-bridge=BR-mDNS 
     dst-mac-address=00:18:DD:25:15:2E/FF:FF:FF:FF:FF:FF mac-protocol=ip dst-address=255.255.255.255/32 
     dst-port=65001 ip-protocol=udp log=no log-prefix="forward HDHomeRun" 

 3  ;;; Forward HDHomeRun
     chain=forward action=accept in-bridge=BR-mDNS out-bridge=BR-mDNS 
     dst-mac-address=00:18:DD:25:15:2E/FF:FF:FF:FF:FF:FF mac-protocol=ip dst-address=192.168.0.255/32 dst-port=65001 
     ip-protocol=udp log=no log-prefix="forward HDHomeRun" 

 4   ;;; Drop all other L2 traffic
     chain=forward action=drop in-bridge=BR-mDNS out-bridge=BR-mDNS log=no log-prefix=""

/interface/bridge/nat/ print      
Flags: X - disabled, I - invalid, D - dynamic 
 0   ;;; mDNS - SNAT to Primary VLAN bridge
     chain=srcnat action=src-nat to-src-mac-address=F6:2C:EA:E2:08:97 
     dst-mac-address=01:00:5E:00:00:FB/FF:FF:FF:FF:FF:FF log=no log-prefix="NAT mdns" 

 1 X ;;; HDHomeRun- SNAT to Primary VLAN bridge
     chain=srcnat action=src-nat to-src-mac-address=F6:2C:EA:E2:08:97 
     dst-mac-address=00:18:DD:25:15:2E/FF:FF:FF:FF:FF:FF log=no log-prefix="NAT HDHomeRun" 

 2   ;;; SSDP - SNAT to Primary VLAN bridge
     chain=srcnat action=src-nat to-src-mac-address=F6:2C:EA:E2:08:97 
     dst-mac-address=01:00:5E:7F:FF:FA/FF:FF:FF:FF:FF:FF log=no log-prefix="NAT ssdp"

/ip/firewall/filter/ print
 8   ;;; HDHomeRun
      chain=input action=accept protocol=udp src-address=192.168.240.161 dst-port=65001 log=no log-prefix="" 

19   ;;; HDHomerun broadcasts
      chain=forward action=accept protocol=udp dst-address=192.168.0.255 dst-port=65001 log=no log-prefix="" 

20   ;;; HDHomerun broadcasts
      chain=forward action=accept protocol=udp dst-address=255.255.255.255 dst-port=65001 log=no log-prefix=""

00:18:DD:25:15:2E is the MAC of the device
192.168.240.161 is the IP of the device
192.168.240.0/24 is the vlan of the device
192.168.0.0/24 is the vlan where i'm and where i want to controll the device.

mDNS and SSDP are working good but HDHomeRun isn't working, i also try mdns repeater from beta, but if i disable this method nothing works in mDNS

Thanks

UpRunTech · Sun Jul 07, 2024 3:57 am

Edit Dupe.

UpRunTech · Sun Jul 07, 2024 3:58 am

mDNS and SSDP are working good but HDHomeRun isn't working, i also try mdns repeater from beta, but if i disable this method nothing works in mDNS

Thanks

I don't have a HDHomerun but it looks like it broadcasts as opposed to multicasts on UDP:65001. I'd try add these 2 lines. You mustn't forget to MAC SRCNAT any frames being emitted by this technique otherwise it won't work. You don't need to accept HDHR on the input chain. Just disable or delete them. This is untested, I am just doing come copying and pasting here.

/interface/bridge/filter/
chain=forward action=accept in-bridge=BR-mDNS out-bridge=BR-mDNS
dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF mac-protocol=ip dst-address=255.255.255.255/32
dst-port=65001 ip-protocol=udp log=no log-prefix="forward HDHR"

/interface/bridge/nat/
chain=srcnat action=src-nat to-src-mac-address=F6:2C:EA:E2:08:97
dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF log=no log-prefix="NAT HDHR"

elemental · Sun Jul 07, 2024 4:39 am

Does anybody have a working setup with two interfaces in different VRFs?
It doesn't work for me (C52iG-5HaxD2HaxD). I tried to add macvlan, ether-interface (not in the main VRF) to the mDNS-bridge. There are no frames/packets hit the bridge filter rules.

I also tried to upgrade to 7.16beta4 with new mDNS proxy feature. The same story.

Kataius · Tue Jul 09, 2024 2:52 pm

/interface/bridge/filter/
chain=forward action=accept in-bridge=BR-mDNS out-bridge=BR-mDNS
dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF mac-protocol=ip dst-address=255.255.255.255/32
dst-port=65001 ip-protocol=udp log=no log-prefix="forward HDHR"

/interface/bridge/nat/
chain=srcnat action=src-nat to-src-mac-address=F6:2C:EA:E2:08:97
dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF log=no log-prefix="NAT HDHR"

Hello,
thank you so much for your reply, you are very kind. Unfortunately this method doesn't work... But...

The first rule:

/interface/bridge/filter/
     chain=forward action=accept in-bridge=BR-mDNS out-bridge=BR-mDNS 
     dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF mac-protocol=ip dst-address=255.255.255.255/32 
     dst-port=65001 ip-protocol=udp log=no log-prefix="forward HDHR"

It seems to work well (I see that if I try to use the HdHomeRun's app the rule runs the packages)

While the second one in my opinion is not exactly the right one...

/interface/bridge/nat/
     chain=srcnat action=src-nat to-src-mac-address=F6:2C:EA:E2:08:97 
     dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF log=no log-prefix="NAT HDHR"

The rule continually has packages running (also if i don't do call to HdHomeRun)

Any other advice?

pfturner · Mon Jul 22, 2024 9:24 pm

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.

Thanks in advance.

UpRunTech · Tue Jul 23, 2024 11:24 pm

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.

pfturner · Wed Jul 24, 2024 4:09 am

Thanks for your reply.

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?

UpRunTech · Mon Aug 19, 2024 11:03 pm

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.

eddieb · Tue Aug 20, 2024 9:17 am

That is a nice feature !
Indeed on my test devices runnning rc2 it is visible
Waiting for the final so I can implement this on my networks

Amm0 · Wed Aug 21, 2024 7:40 pm

mDNS and SSDP are working good but HDHomeRun isn't working, i also try mdns repeater from beta, but if i disable this method nothing works in mDNS

Thanks
I don't have a HDHomerun but it looks like it broadcasts as opposed to multicasts on UDP:65001.

IP broadcasts are NOT same as multicast. And HDHomerun using broadcast address for it's discovery protocol (as noted above).

I was reading this post: viewtopic.php?t=210244#p1092534
and thought the HDHomerun issue since it's come up a few times in the forum

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.

szpeter80 · Sun Sep 08, 2024 1:43 pm

Looks like you have been divining the tea leaves.

7.16 beta3 how has a shiny new mDNS repeater. Dunno if it's as choice as the bridge method.

*) dns - added support for mDNS proxy (CLI only);

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.

danergo · Sat Sep 14, 2024 12:13 pm

I was tooling through the Help as it likes to change unannounced from time to time and I noticed and read about MACVLAN. Of course it's been around a few months as a tab in Winbox but I never looked into it. This interface solves the problem of being able to do this bridge filtering technique BUT ON YOUR MAIN ROUTER. No offsider router like I used in the OP.

Hello. I'm in a similar situation as you:

Main router defines VLANs
CAP (managed by CapsMan on main) broadcasts wifi with vlan100
vlan100: network for phone (via cap wifi)
vlan101: network for TV (via main router)
I wish to allow Spotify and YouTube on my phone to cast to the TV

So I quickly followed your macvlan solution:

/interface/macvlan
add interface="vlan100 - phones" name="macvlan100"
add interface="vlan101 - tvs" name="macvlan101"

/interface/bridge
add name=bridgemdns protocol-mode=none

/interface/bridge/port
add bridge=bridgemdns interface=macvlan100
add bridge=bridgemdns interface=macvlan101

/interface/bridge/filter
add action=accept chain=forward comment="Allow 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 in-bridge=bridgemdns ip-protocol=udp mac-protocol=ip out-bridge=bridgemdns src-port=5353
add action=drop chain=forward in-bridge=bridgemdns out-bridge=bridgemdns comment="Drop all other"

/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=[/interface/bridge/get [find name="bridge"] mac-address] comment="SNAT"

I enabled logging for both the accept filter, and the snat rule. Strange thing? All logs are showing the connection-state: invalid.

Although, neither Spotify nor YouTube on the phone can't find the TV (which used to work before separating them with VLANs).

What would you suggest?

danergo · Sun Sep 15, 2024 1:42 pm

Folks, getting some progress:

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.

Did anyone see this behavior?

danergo · Sun Sep 15, 2024 2:50 pm

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.

mvdh · Thu Sep 19, 2024 11:23 pm

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"

UpRunTech · Fri Sep 20, 2024 12:42 am

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.

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.

mvdh · Fri Sep 20, 2024 7:55 am

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.

Indeed. Once 7.16 stable has been released, I’ll switch to the mDNS functionality provided by RouterOS.

Thanks again.

robdejonge · Fri Sep 20, 2024 8:24 am

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!

mvdh · Fri Sep 20, 2024 12:13 pm

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!

Goedemorgen, Rob.

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.

robdejonge · Sat Sep 21, 2024 5:39 am

Goeiemorgen, m! Ook in Bangkok??

Thanks for sharing the configuration. Please allow me to ask a few questions to better my understanding:

1) 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?

2) 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?

3) 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!!?

4) 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!

djfraz · Mon Sep 23, 2024 9:57 am

.

/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 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"

Disregard my previous text

Kataius · Tue Sep 24, 2024 3:19 pm

I don't have a HDHomerun but it looks like it broadcasts as opposed to multicasts on UDP:65001.
IP broadcasts are NOT same as multicast. And HDHomerun using broadcast address for it's discovery protocol (as noted above).

I was reading this post: viewtopic.php?t=210244#p1092534
and thought the HDHomerun issue since it's come up a few times in the forum

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.

SOLVED:

with three rules:

/ip/firewall/filter/

25    ;;; allow access from HDHomeRun
      chain=forward action=accept protocol=udp src-address=192.168.240.161 dst-address-type=unicast dst-address-list=net_lan src-port=65001 log=no log-prefix=""

/interface/bridge/filter/

2   ;;; Forward HDHR
     chain=forward action=accept in-bridge=BR-mDNS out-bridge=BR-mDNS dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF mac-protocol=ip dst-address=255.255.255.255/32 dst-port=65001 ip-protocol=udp log=no log-prefix="forward HDHR"

/interface/bridge/nat

 2   ;;; HDHR- SNAT to Primary VLAN bridge
     chain=srcnat action=src-nat to-src-mac-address=F6:2C:EA:E2:08:97 dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF log=no log-prefix="NAT HDHR"

Kanzler · Tue Sep 24, 2024 3:32 pm

7.16 stable with mDNS proxy released

pfturner · Sat Sep 28, 2024 10:18 pm

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.

TIA

Who is online