mDNS repeater feature

mafiosa · Mon Apr 12, 2021 12:02 am

Please bring mDNS repeater feature in Rosv7. It is a very important feature for home routers.

jvanhambelgium · Mon Apr 12, 2021 12:16 am

Please bring mDNS repeater feature in Rosv7. It is a very important feature for home routers.

This is only an issue if you start fiddling around with multiple LAN / VLAN's
Guess what, like 0.00001% or something of "home users" is actually toying around with that in their home setup.

Don't get your hopes up to see it integrated into RouterOS. I think similar requests are echoing through the dungeons of this forum for many years now...

infabo · Mon Apr 12, 2021 1:53 am

Made my day! :D

memelchenkov · Mon Apr 12, 2021 9:27 am

A pretty neat feature and often required here. It's usually good for sharing printers in work environment, rather than for home. However, for home could be useful too, people are just lazy now to make some complicated setups of their networks. But Mikrotik is a complicated device, it's strange they still ignore mDNS repeater. Who need "plug-and-play" device will not go Mikrotik way. Look at OpenWRT-enabled devices, there you could install any package you want. Or use your home NAS/RPi/etc. for this feature.

infabo · Mon Apr 12, 2021 7:49 pm

OpenWrt has relayd and a dedicated interface type for this task. But relayd is limited to IPv4. I once had such a setup running.

benoitc · Wed Jul 07, 2021 4:26 pm

even the edgerouter has a mdns repeater..

mafiosa · Wed Jul 07, 2021 5:18 pm

even the edgerouter has a mdns repeater..

Ever home user needs mDNS. Don't know why mikrotik keeps ignoring this.

rextended · Wed Jul 07, 2021 5:20 pm

Ever home user needs mDNS.

I am a home user and do not need it.
Why is your assumption so absolute?
It is absolute-ly false.

My 4,000 contracts (home and business), corresponding to more than 16,000 people,
do not have it and no one has ever complained about it.

Please explain which critical part of the home network does not work without mDNS.

Thanks.

mafiosa · Wed Jul 07, 2021 5:29 pm

Ever home user needs mDNS.
I'm a home user, and I do not neet that.
Why you assumption is so absolute?
Is absolute false.

My 4000 contracts (home and business), corresponding to more than 16000 person do not have that, no one single complain about that.

Please explain what critical part of home network do not function without mDNS.

Thanks.

I keep my IoT on a separate vlan, I have my smart tv and google home devices on the same IoT vlan. How do I connect the smart tv and google home from my Wifi that is on a separate vlan?

rextended · Wed Jul 07, 2021 5:35 pm

(please do not quote on useless way, use "post reply" instead)

>>>I keep my IoT on a separate vlan = VLAN of IoT devices
>>>I have my smart tv and google home devices on the same IoT vlan = TV and Google Home on same VLAN of IoT devices

>>>How do I connect the smart tv and google home from my Wifi that is on a separate vlan?
But on previous description do not are already on same VLAN of IoT devices ???
The mDNS is not the tool for do that...
Solution is extremely simple:
Create one virual wlan for other IoT devices, TV and Google Home, than work on same VLAN of IoT devices...

Do not have any sense make separate VLAN of IoT devices and then set Google and Smart TV on "main" Wi-Fi

mafiosa · Wed Jul 07, 2021 5:50 pm

Hege muchechilen sokale? na orom bhabhei chole esheychen dalali korte?

rextended · Wed Jul 07, 2021 6:13 pm

traduction:
You touch the wrong cable...

benoitc · Wed Jul 07, 2021 10:56 pm

(please do not quote on useless way, use "post reply" instead)

>>>I keep my IoT on a separate vlan = VLAN of IoT devices
>>>I have my smart tv and google home devices on the same IoT vlan = TV and Google Home on same VLAN of IoT devices

>>>How do I connect the smart tv and google home from my Wifi that is on a separate vlan?
But on previous description do not are already on same VLAN of IoT devices ???
The mDNS is not the tool for do that...
Solution is extremely simple:
Create one virual wlan for other IoT devices, TV and Google Home, than work on same VLAN of IoT devices...

Do not have any sense make separate VLAN of IoT devices and then set Google and Smart TV on "main" Wi-Fi

you may want to put your TV or your dishwasher on an IOT VLAN so it can access to internet but not other vlans, and still want make it discoverable for the familly vlan so they can start the dishwasher or lookt at the TV from their devices?

Another example is to put your printer on a vlan for the same reason, you want it upgradable/maintainable remotely . But you want also to make it discoverable easily.

rextended · Thu Jul 08, 2021 1:01 am

@benoitc why you write that quoting my post?

benoitc · Thu Jul 08, 2021 11:09 am

@benoitc why you write that quoting my post?

to reply to your "Do not have any sense make separate VLAN of IoT devices and then set Google and Smart TV on "main" Wi-Fi" . I may have misunderstood. But as I understand the principle, devices were on IOT vlan but accessed from others. And then you need an MDNS repeater

Thu Jul 08, 2021 11:22 am

To those people asking for mDNS, can you give examples where it will be useful?
Rextended provided solutions for the given examples. Maybe there are more examples?

memelchenkov · Thu Jul 08, 2021 12:14 pm

To those people asking for mDNS, can you give examples where it will be useful?

I.e. network printers in wired network shared with VLAN of wireless clients. Connections to printers are allowed by firewall, but mDNS are not routed so users must enter IP addresses rather than use auto-discovery feature.

afuchs · Thu Jul 08, 2021 12:17 pm

Hello,

it would be useful because of apple.
One of our customers had the problem, that some of his hotspot users log in and close the status site.
After some time, they want to log out and they find it to complicated to use a url with an IP in it,
so I set up a static dns entry like 'router.customer.local' and it worked for all PCs and Laptops, but the iPhone couldn't resolve it.
After some sniffing I found only mDNS requests. Google found me an article that says, that Apple devices uses mDNS by local domains.

So mDNS would be helpful in his setting.

jookraw · Thu Jul 08, 2021 2:10 pm

To those people asking for mDNS, can you give examples where it will be useful?
Rextended provided solutions for the given examples. Maybe there are more examples?

Hello normis,
Actually, he did not provide any solution.
mDNS repeater is needed in the case that you have an IoT vlan and you need to interact to those devices from your main vlan.
For e.g. A phone connected to the main vlan needs to "cast" content to a smart tv on the restricted IoT vlan. and just to avoid any "why you connect your phone to the IoT vlan?" because it is not the solution.
in 2021 mDNS Repeater is a must.

rextended · Thu Jul 08, 2021 2:16 pm

You do not catch the point, (ignore mDNS) why make separate IoT VLAN if than must be continuosly on contact with "MAIN" VLAN?
True nonsense!!!

Thu Jul 08, 2021 2:22 pm

Yes, the question is, why separate the IoT, if you don't really need to separate ?

rextended · Thu Jul 08, 2021 2:26 pm

mDNS repeater is needed in the case that you have an IoT vlan and you need to interact to those devices from your main vlan.

mDNS is not a NAT or Routing, it simply supplies an address
for work already the two VLAN must communicate to eachother and...
why formerly separated VLAN, but effectively not?

The device also MUST be compatible whit mDNS

mDNS devices do not need any mDNS "proxy" if already are on same broadcast domain

...A phone connected to the main vlan needs to "cast" content to a smart tv on the restricted IoT vlan....

All these devices are studied to be all on same wired/wireless network, not to different VLAN.
Just some users on this forum or very advanced users use VLAN in house,
99,9% do not matter if are VLAN or not, 99,8% also do not know what ia a VLAN.

mkx · Thu Jul 08, 2021 2:32 pm

It's not entire nonsense, sometimes it's not possible to do it differently.

Here's example: you have an IoT gadget. It might not need internet, so you want to block internet access for it. Fine, you can use IP firewall filter if you know gadget's IP address. The later part can be tricky with IPv6 and dynamic addresses (constructed with aide of SLAAC), but you can still filter that according to gadget's MAC address. But even that is not fail safe, Apple in particular (and others as well) started to "anonymize" MAC address ... good luck catching that.
But even if you successfully block access to internet: user might want to restrict access of device to LAN services. And that's not easy to do if all devices belong to same L2 network.

Having separate L2 network for IoT devices solves all above mentioned problems without too much fuss. But then there comes auto-discovery where many (probably most) vendors simply expect that everything attaches to same L2 network (hence need for mDNS proxying) unless gadget registers directly to some cloud. Which is probably how network looks like for 99% of home users, but those mostly are not interested in running Mikrotik gear.

Personally I couldn't care less about mDNS and all that automagical stuff. But I still find problematic attitude of Mikrotik about not implementing service, which is enforced by major players and used by home users more and more. If MT wants to stay alive in SOHO segment, then they'll have to implement those features whether they like them or not.

rextended · Thu Jul 08, 2021 2:45 pm

>>>you have an IoT gadget It might not need internet so you want to block internet access for it
Simply do not provide a gateway and DNS on lease

>>>you can use IP firewall filter if you know gadget's IP address
...no...

>>>The later part can be tricky with IPv6 and dynamic addresses...
...no... go out only know/allowed devices, if anonymize MAC, never go out

>>>but you can still filter that according to gadget's MAC address
...ok....

>>>But even that is not fail safe, Apple in particular (and others as well) started to "anonymize" MAC address...
do not buy Apple devices... or filter device with "2nd lower bit set" (000000!0) .. I do not know if is legal to change randomly the MAC (how much random?)

>>> good luck catching that.
...but on this way you still have MAC allowed to out, not a list of blocked MAC....

>>>user might want to restrict access of device to LAN services
why? what can do a device without internet to a light bulb, to a PC? etc.?.

>>>And that's not easy to do if all devices belong to same L2 network.
...really... is easy....

>>>Having separate L2 network for IoT devices solves all above mentioned problems
...yes but... still no see any problem with IoT devices on same L2 network of my PC...

jookraw · Thu Jul 08, 2021 2:47 pm

Why a separate IoT vlan? because I want it, and why have a Mikrotik router at home and use it as a stupid ISP HG(aka router)?

I want to have control of devices that I don't fully trust, those "black boxes", and having a vlan for it, I isolate it from the L2 domain.

The main reason that I have a Mikrotik at home is to do things that I cannot do using the ISP's Home Gateway, like having a separate, untrusted IoT vlan and a guest vlan.

mDNS Repeater is needed to make some services work across vlans, like printing, casting and etc.

TonyJr · Thu Jul 08, 2021 2:48 pm

To those people asking for mDNS, can you give examples where it will be useful?
Rextended provided solutions for the given examples. Maybe there are more examples?

In a business environment, wired printers can often be on their own VLAN, or one separate from Wireless devices. Without mDNS between the networks, the built in discovery tools for printing in a lot of mobile and wireless devices does not work. It prevents printing from some mobile devices to another network. Manual setup of DNS for this is long-winded and does not always work correctly (possibly wide-area bonjour).

There is also streaming to projectors and smart tvs/sticks that rely on the devices being on the same network for discovery, which is not always true in a business environment.

That is what I have seen in my experience.

rextended · Thu Jul 08, 2021 2:55 pm

mDNS Repeater is needed to make some services work across vlans, like printing, casting and etc.

You understand than mDNS do not do NAT, routing, firewall, etc. but just resolve address?
If you can comunicate between VLANs... the VLANs for this do not have any sense!
Understand?

jookraw · Thu Jul 08, 2021 2:59 pm

You do not catch the point, (ignore mDNS) why make separate IoT VLAN if than must be continuosly on contact with "MAIN" VLAN?
True nonsense!!!

nonsense is your posts, if you don't see a reason to use it, does not mean that no one can have a reason to need it.
Want a example? I want to all devices not be able to access/scan devices on my main "trusted" vlan, but still my devices on the trusted vlan be able to talk with those IoT, not backwards. Any connection started on trusted side is permitted, not the ones started on the untrusted that are not to the internet.

Ps. if you dont have a reason to post something useful, don't post, people here is just making a reasonable request for a thing that is used by all big players.

rextended · Thu Jul 08, 2021 3:00 pm

>removed, useless, see post #41<

jookraw · Thu Jul 08, 2021 3:01 pm

mDNS Repeater is needed to make some services work across vlans, like printing, casting and etc.
You understand than mDNS do not do NAT, routing, firewall, etc. but just resolve address?
If you can comunicate between VLANs... the VLANs for this do not have any sense!
Understand?

of course, I know that. I've FW rules to allow the connections in the way that I do.

rextended · Thu Jul 08, 2021 3:03 pm

Ooooh, you understand now!

jookraw · Thu Jul 08, 2021 3:04 pm

Yes, the question is, why separate the IoT, if you don't really need to separate ?

@normis, basically some users, like me, want to isolate IoT devices by the L2 domain. but still allowing some connections to start from the trusted side.
some times all this Ch***** crap you will never know...

rextended · Thu Jul 08, 2021 3:08 pm

Ok, you deserve one solution until mDNS is officially supported?

rextended · Thu Jul 08, 2021 3:23 pm

>removed, useless, see post #41<

xvo · Thu Jul 08, 2021 3:27 pm

@normis, basically some users, like me, want to isolate IoT devices by the L2 domain. but still allowing some connections to start from the trusted side.
some times all this Ch***** crap you will never know...

Perfectly valid point.

rextended · Thu Jul 08, 2021 3:39 pm

>removed, useless, see post #41<

jookraw · Thu Jul 08, 2021 3:54 pm

With that settings I give some clue & hint for someone...
Simply "copy" broadcasted mDNS/SSDP between VLANs.
No something named "mDNS proxy" required...

not in the case of using a Routerboard without a switch chip or with a limited one (like RB4011).

rextended · Thu Jul 08, 2021 3:59 pm

I do not have one 4011 to do some test, sorry :(

rextended · Thu Jul 08, 2021 4:40 pm

I think the real problem is Wireless: be always on another switch, not on RTL8367

jookraw · Thu Jul 08, 2021 5:01 pm

I don't have the wireless version. the problem is the RTL8367, it does not support anything besides the same as a $10 switch. anyway, I don't use it, just the SFP+ port.

rextended · Thu Jul 08, 2021 6:31 pm

Ok, "solved"
Install multicast separate package and configure PIM:
https://wiki.mikrotik.com/wiki/Manual:R ... _.28PIM.29

The Protocol independent multicast (PIM) can receive cast from one vlan and re-cast to another,
this forward mDNS (Apple) / SSDP (all the Others) multicast packet between VLANs and you do not need other things,
except for next step on firewall rules between VLANs connections.

mDNS: UDP packet with source as device IP, standard random port for source, destination multicast 224.0.0.251 port 5353
mDNS Query: UDP packet with source as device IP, port 10101, destination multicast 239.255.255.251 port 10101
SSDP / UPnP: UDP packet with source as device IP, standard random port for source, destination multicast 239.255.255.250 port 1900
WS-Discovery: UDP packet with source as device IP, standard random port for source, destination multicast 239.255.255.250 port 3702

All this do not change my disbelief on need separation from IoT and home private network.
(On home point of view, business/work is another thing...)

LaSepp · Thu Jul 08, 2021 7:03 pm

I'm also in the same boat, having to get mDNS accross different interfaces (not just VLANs!).

In my use case I'm running Apple Airport as audio streaming receiver at a dance studio.

Audio needs to be sent from the wired devices that are inside the office VLAN (they need to be to get access to the internal systems) and also from the teacher devices that are joined into the network via wireless. At the moment both are in the same network, but I would prefer to move the teachers that are partly contractors into an isolated network where they can get internet and do streaming but cannot connect to the other internal systems.

As a bonus it would be great to be able to use AirPrint (mDNS) enabled Printers via the VPN connection from the home office site from the iPhone / iPad of the owner.

At the moment there is a linux VM connected to multiple VLANs and bridged to the remote site via EOIP running mDNS Repeater to get this functionality. Would be great if it could just be enabled on the MT Routers.

It's by no means a must feature, but as more and more devices are switched to mobile and automagical configuration it could keep some admins sane trying not to just put everything into one big network and hope for the best....

Also about PIM:
I tried setting it up, but mDNS requests are marked as not routable, so PIM simply ignores them....
If there is a simple workaround I would like to hear it, would save me a ton of work.

Thu Jul 08, 2021 7:55 pm

By the looks of it, L2 segregation for the mentioned above cases is an illusion of safety.

I understand the reason why you would want to put IoT devices under a separate VLAN. For instance, you bought a no-name smart light bulb on eBay and you don't want it to access your NAS and upload its content to the internet. But you want to be able to turn on/off the bulb from your PC/smartphone. Then why not put your PC/smartphone under both IoT and NAS VLANs? Then PC will be able to access both IoT and NAS devices, but IoT cannot access NAS.

What you are trying to do, is to segregate the network on L2 (via VLAN), but then combine it together on L3 (via inter-VLAN routing). Without a firewall, there is no safety here, only an illusion of it. Yes, IoT devices on one VLAN cannot do neighbor discovery, but with inter-VLAN routing, nobody prevents them to scan the routed network (unless a properly configured firewall). For example, your PC VLAN 10 IP 192.168.10.1/24 accesses a spyware light bulb on VLAN 20 IP 192.168.20.31/24, then the bulb scans the source network (e.g.

nmap -sn 192.168.10.0/24

), finds a NAS at 192.168.10.75 and does nasty things with that.

Of course, you can configure the firewall to allow traffic only from VLAN ID 10 to 20, but backward - only within the established connections (btw, it won't work in case of mDNS due to multicast), but IMHO that's overcomplicated.

It is much easier to assign PC to both VLANs with IP 192.168.10.1/24 and 192.168.20.1/24 for VLAN 10 and 20 respectively and to prevent (by simply not creating) routing between 192.168.10.0/24 and 192.168.20.0/24 networks.

xvo · Thu Jul 08, 2021 8:36 pm

Of course, you can configure the firewall to allow traffic only from VLAN ID 10 to 20, but backward - only within the established connections (btw, it won't work in case of mDNS due to multicast), but IMHO that's overcomplicated.

Surely that is one of the necessary precautions.
And that's where mDNS repeater would come in handy - so you can easily make the router transparent for mDNS, leaving router's firewall to work the usual way - allowing new connections only from trusted networks to untrusted, but not vice versa.

But now I wonder if the approach with PIM that @rextended suggested will do the trick...

mafiosa · Thu Jul 08, 2021 10:39 pm

To those people asking for mDNS, can you give examples where it will be useful?
Rextended provided solutions for the given examples. Maybe there are more examples?

I have two VLANs one for LAN and one for WLAN. I want to cast my screen from the desktop in the LAN to my smart tv in WLAN. I use mikrotik because I need vlan segregation. Else would have gone with any other ASUS AC/AX router. Thats why I need MDNS.

jookraw · Fri Jul 09, 2021 6:19 pm

@rextended Thanks for the workaround idea, but, for now, there is no multicast package for the ROS 7.x.

@raimondsp I don't understand the resistance against mDNS repeater, yes could be complicated to have all of them correctly configured, but still, I don't get it. Also, putting the phone in the untrusted vlan is not an option, as, in my case, I need to use some services on it. Also, it is not only phones using mDNS, laptops too.

rextended · Fri Jul 09, 2021 6:23 pm

I do not consider RouterOS 7 until at least first stable version coming out (except 7.0.3 for Chateau LTE12 than I do not have)

benoitc · Fri Jul 09, 2021 6:44 pm

>>>you have an IoT gadget It might not need internet so you want to block internet access for it
Simply do not provide a gateway and DNS on lease

>>>you can use IP firewall filter if you know gadget's IP address
...no...

>>>The later part can be tricky with IPv6 and dynamic addresses...
...no... go out only know/allowed devices, if anonymize MAC, never go out

>>>but you can still filter that according to gadget's MAC address
...ok....

>>>But even that is not fail safe, Apple in particular (and others as well) started to "anonymize" MAC address...
do not buy Apple devices... or filter device with "2nd lower bit set" (000000!0) .. I do not know if is legal to change randomly the MAC (how much random?)

>>> good luck catching that.
...but on this way you still have MAC allowed to out, not a list of blocked MAC....

>>>user might want to restrict access of device to LAN services
why? what can do a device without internet to a light bulb, to a PC? etc.?.

>>>And that's not easy to do if all devices belong to same L2 network.
...really... is easy....

>>>Having separate L2 network for IoT devices solves all above mentioned problems
...yes but... still no see any problem with IoT devices on same L2 network of my PC...

You answer is a nonnse se as well. VLAN N allows different connections profile. Eg. You may not want to have IPV6 RA on a VLAN or use a different addressing for IOTs. You may want to only let 20Mbps throughtput to TVs. You also want IOT devices connected to the net but not allow them to discover other devices in the house. You may also want to only allows 2 VLAN to access to the same devices but let others vlans out.

There are plenty of uses cases afaik. You can't rely on mac addressing or even ips to make proper tules. In large networks this is near impossible.

As I understand you don't see any interrest to it and it may be useful you provide your own solutions to manages printers, some iot devices (like chromecast, apple tvs, ...) which can be useful for some. But afaik mDNS has some uses cases. A,nd it would be useful to have a package for it.

benoitc · Fri Jul 09, 2021 6:48 pm

It is much easier to assign PC to both VLANs with IP 192.168.10.1/24 and 192.168.20.1/24 for VLAN 10 and 20 respectively and to prevent (by simply not creating) routing between 192.168.10.0/24 and 192.168.20.0/24 networks.

I had to look, but this is apparently not something possible on an iPhone or an iPad :/

rextended · Fri Jul 09, 2021 6:54 pm

@benoitc I think you misunderstood again.
That post is not addressed to you.
I don't want discuss about that.

I just try to help to find one alternative solution UNTIL mDNS is available.

benoitc · Fri Jul 09, 2021 9:43 pm

@benoitc I think you misunderstood again.
That post is not addressed to you.
I don't want discuss about that.

I just try to help to find one alternative solution UNTIL mDNS is available.

I was just describing the utility of segregating devices none vlan while wanting to access to them from others. (eg. controlling throughput or controlling who is there before anything).

I will try your solution with PIM. The thing is that normally mDNS multicast is scoped to its subnet. so unsure how it will work when the ip is announced to the other subnet. mdns repeater are acting as proxy or such thing.

Xelanc · Sun Aug 01, 2021 2:32 am

To those people asking for mDNS, can you give examples where it will be useful?
Rextended provided solutions for the given examples. Maybe there are more examples?

Hi Thanks for asking examples , I bought the MikroTik as extra router behind the router of my provider and defined 2 subnets on it. One for IOT and one for my Home PC's. I moved the IOT devices to the IOT subnet including the Philips HUE. This is not working anymore behind the MikroTIk router. I spend ours googling and wondering why it's traffic was not routed upstreams. Then I found HUE is generating MDNS traffic, I captured some of these packets. I tried to install the igmp-proxy package and see if that would help but no success. Hopfully there can be a solution for this.

192.168.100.51 is the Hue, connected to Ether2 , Ether1 sits on the upstream router network 192.168.2.X, the upstream router 192.168.2.254 seems not to get the MDNS and Multicast packets so it cant futher route them to the internet.

(screenshot link will stop working after 14 days no view)

dgm · Fri Aug 06, 2021 10:43 am

To those people asking for mDNS, can you give examples where it will be useful?
Rextended provided solutions for the given examples. Maybe there are more examples?

On a hotspot network with 100 to 1000 or more devices on a network, one usually blocks multicast traffic, and adds client isolation. It would be handy to be able to reach AppleTV's or Chromecasts on a different VLAN, MDNS would be useful for this. This way we can still ensure proper efficiency and security on the main hotspot user VLAN, as well as give them access to the needed media services, without hotspot users being able to access each other.

kiler129 · Fri Aug 06, 2021 9:09 pm

Yes, mDNS is really a needed feature. Also, it's a VERY small and lightweight userland daemon. I run a VM with avahi and it doesn't really use any CPU while sitting in low single digits for memory usage. Additionally, it will literally need interfaces assignment and no other complex configuration.

DarkNate · Sat Aug 07, 2021 12:13 pm

Allow inter-VLAN routing, allow multi-cast routing on LAN, don't block Multicast subnets. Problem solved.

https://en.wikipedia.org/wiki/Multicast_address

rextended · Sat Aug 07, 2021 12:24 pm

@DarkNate, if for some reason you read my posts, you can notice I never suggest to use "drop bogon", except for prevent IP spoofing on WAN,
but this forum, the web, and also some mikrotik guide put 224.0.0.0/4 as bad_ipv4, like must be dropped, IGNORING THE SOURCE, or someone dies...
https://help.mikrotik.com/docs/display/ ... d+Firewall

Toom much copy&paste without know what is doing

from ros guide:

ROS HELP code

/ip firewall address-list
[...]
  add address=224.0.0.0/4 comment="defconf: multicast" list=no_forward_ipv4
[...]
/ip firewall filter
[...]
  add action=drop chain=forward src-address-list=no_forward_ipv4 comment="defconf: drop bad forward IPs"
  add action=drop chain=forward dst-address-list=no_forward_ipv4 comment="defconf: drop bad forward IPs"
[...]

But on page, you also linked:
224.0.0.251 Multicast DNS (mDNS) address, Routers must not forward these messages outside the subnet from which they originate

The IANA has reserved the range 224.0.0.0 to 224.0.0.255 for use by network protocols on a local network segment.
Packets with an address in this range are local in scope and are not forwarded by IP routers.
Packets with link local destination addresses are typically sent with a time-to-live (TTL) value of 1 and are not forwarded by a router.
Within this range, reserved link-local addresses provide network protocol functions for which they are reserved.
Network protocols use these addresses for automatic router discovery and to communicate important routing information.
For example, Open Shortest Path First (OSPF) uses the IP addresses 224.0.0.5 and 224.0.0.6 to exchange link-state information.
IANA assigns single multicast address requests for network protocols or network applications out of the 224.0.1.xxx address range.
Multicast routers forward these multicast addresses.

DarkNate · Sun Aug 08, 2021 2:03 am

@DarkNate, if for some reason you read my posts, you can notice I never suggest to use "drop bogon", except for prevent IP spoofing on WAN,
but this forum, the web, and also some mikrotik guide put 224.0.0.0/4 as bad_ipv4, like must be dropped, IGNORING THE SOURCE, or someone dies...
https://help.mikrotik.com/docs/display/ ... d+Firewall

Toom much copy&paste without know what is doing

from ros guide:
ROS HELP code
/ip firewall address-list
[...]
  add address=224.0.0.0/4 comment="defconf: multicast" list=no_forward_ipv4
[...]
/ip firewall filter
[...]
  add action=drop chain=forward src-address-list=no_forward_ipv4 comment="defconf: drop bad forward IPs"
  add action=drop chain=forward dst-address-list=no_forward_ipv4 comment="defconf: drop bad forward IPs"
[...]
But on page, you also linked:
224.0.0.251 Multicast DNS (mDNS) address, Routers must not forward these messages outside the subnet from which they originate

The IANA has reserved the range 224.0.0.0 to 224.0.0.255 for use by network protocols on a local network segment.
Packets with an address in this range are local in scope and are not forwarded by IP routers.
Packets with link local destination addresses are typically sent with a time-to-live (TTL) value of 1 and are not forwarded by a router.
Within this range, reserved link-local addresses provide network protocol functions for which they are reserved.
Network protocols use these addresses for automatic router discovery and to communicate important routing information.
For example, Open Shortest Path First (OSPF) uses the IP addresses 224.0.0.5 and 224.0.0.6 to exchange link-state information.
IANA assigns single multicast address requests for network protocols or network applications out of the 224.0.1.xxx address range.
Multicast routers forward these multicast addresses.

224.0.0.0/4 should be dropped from WAN not LAN

rextended · Sun Aug 08, 2021 2:52 am

That's the point: the MikroTik help and other "guides" incorrectly drop all regardless if are needed on LANs...

DarkNate · Sun Aug 08, 2021 11:15 am

That's the point: the MikroTik help and other "guides" incorrectly drop all regardless if are needed on LANs...

Don't know, I review every rule/config line by line from guides, no blind copy/paste, so never had broken problems before.

kiler129 · Mon Aug 09, 2021 9:28 pm

Allow inter-VLAN routing, allow multi-cast routing on LAN, don't block Multicast subnets. Problem solved.

https://en.wikipedia.org/wiki/Multicast_address

Have you actually tested it or just blindly linked the wikipedia page? mDNS traffic is marked to never cross the subnet and so that even if you forcefully forward it devices which support the protocol properly will simply ignore it. You need an mDNS proxy/router which is responsible for handling mDNS announcements between subnets.

https://networkengineering.stackexchange.com/a/72933 see that for good summary
Even IETF had a document about the issue: https://tools.ietf.org/id/draft-bhandar ... ay-00.html

jookraw · Tue Aug 10, 2021 10:42 am

Lets just remember that there is a open source implementation of it called avahi (that is actually what runs under the hood on EdgeMax routers for mDNS).

Most people here against, never used mDNS, so they didn't test it. also, there is no multicast package on 7.1 yet.
most people here for it, have used before and can't believe that this is not present on RouterOS.

vio2fi · Sun Aug 15, 2021 1:05 am

Yes, the question is, why separate the IoT, if you don't really need to separate ?

I just wanted my guest network to be able to connect to the chromecast on the main network while being able to rate limit the whole guest network by simple queues, this might not be the right way but it was the easiest way for me to do it, I also wanted to setup a network only for IoT devices with no internet access, but further diving into this has only brought me across jank solutions.

I am perplexed by the hesitation to have mDNS by mikrotik (just looking on the forums there are multiple threads of such discussions)

Frankly I can't comprehend the replies by the staff on this thread, and some of the replies are just fear-based rather than factual, and no examples given based on real-world scenarios.
FE;
How will having an mDNS server make these devices be able to access the internet? Unless your devices have already been compromised that doesn't sound right! Actually it sounds very paranoid, being scared of something on the small chance that it might happen? Then why connect to the internet at all?

And let's say even if the IoT devices were able to query local devices through mDNS how will they get internet access if the network they're on is unable to?

So far the only solution I could find was having to buy a pi just to be able to run an mDNS server, as chronicled here,
viewtopic.php?t=160966
This actually hurt reading, the poor guy spending months on what should be plug and play tbh.
Anyway, it has been a tiring day and I'm just more frustrated that the solution to such a simple problem has not been implemented despite so many threads on the forum about this very issue

OlofL · Mon Aug 16, 2021 11:56 am

Yes, the question is, why separate the IoT, if you don't really need to separate ?

Because the IOT device might have more than one service that its broadcasting. And with a mDNS repeater function, you could chose which services to rebroadcast on another network. And then firewall to only allow the specific features you want. My device broadcasts file server, ssh server, vnc server functionality. It would be great to filter those.

I use mDNS repeaters a lot, for instance for guest access to internal apple-tv airmirror, for printer functions etc...

It is easier to separate the network functions IOT/printer/client/server etc. It is cleaner. It is easier creating firewall rules.

Also, you might want to deny internet access from the IOT LAN.
IOT might have different security policies compared to enterprise LAN...

Do I need to go on?

I dont understand why this needs to be "explained" to mikrotik staff... lol

Right now I do this in my Aerohive AP's instead.

archerious · Wed Aug 25, 2021 2:08 am

Yes, the question is, why separate the IoT, if you don't really need to separate ?

Because the IOT device might have more than one service that its broadcasting. And with a mDNS repeater function, you could chose which services to rebroadcast on another network. And then firewall to only allow the specific features you want. My device broadcasts file server, ssh server, vnc server functionality. It would be great to filter those.

I use mDNS repeaters a lot, for instance for guest access to internal apple-tv airmirror, for printer functions etc...

It is easier to separate the network functions IOT/printer/client/server etc. It is cleaner. It is easier creating firewall rules.

Also, you might want to deny internet access from the IOT LAN.
IOT might have different security policies compared to enterprise LAN...

Do I need to go on?

I dont understand why this needs to be "explained" to mikrotik staff... lol

Right now I do this in my Aerohive AP's instead.

Couldn't agree more, the fact that Ubiquiti has had this feature for years is embarrassing. MikroTik is superior in routing, software,e and hardware, so I don't understand why they are allowing Ubiquiti to have an advantage over them. Mdns is extremely important for pro-sumers, the exact crowd that buys MikroTik for SOHO.

I've had several customers upset that their guest wifi cannot use airplay from the regular wifi, leading them to give their main wifi password to guests.....and regret it.

Stupid, stupid, stupid.

Just use Avahi or something else @MikroTik!

infabo · Wed Aug 25, 2021 10:10 am

But why do you not just put the printer to guest wifi instead? This is the recommended way to do it - according to discussion. No need to "hide" the printer in a "regular wifi".

But just kidding. I do not get it either, why people argue so much against mdns repeater.

onnoossendrijver · Wed Aug 25, 2021 1:31 pm

In a network where I need mDNS repeater I placed a small linux box running avahi (could be a Raspberry PI) with interfaces in both vlans.
This works really great.
Offcourse disable routing and/or configure the local firewall correctly...

carabila · Fri Aug 27, 2021 1:13 am

+1 to have mDNS in RouterOS.

CyBuzz · Mon Aug 30, 2021 2:23 am

Another example is to put your printer on a vlan for the same reason, you want it upgradable/maintainable remotely . But you want also to make it discoverable easily.

Exactly my use case

mjbnz · Wed Sep 01, 2021 7:32 am

Yes, the question is, why separate the IoT, if you don't really need to separate ?

The biggest reason I can think of, is that you might have ethernet connected IoT devices in publicly accessible locations - you don't want your trusted network to be on the end of that cable. (CCTV is more likely than IoT, but the point is still the same)

marine88 · Mon Sep 06, 2021 2:32 am

+1 to have mDNS in RouterOS.

RhoAius · Mon Sep 06, 2021 11:03 am

A good practice for IOT on their own vlan is for limiting broadcasts.
You may want L3 connectivity to the devices but you may not like their "chatty" nature on L2.
With the rise of IOT devices it is easy to have 20+ devices on a network that broadcast constantly thus slowing down the network.
Gigabit ethernet and PCs will not feel this effect much but WiFi 5 and bellow or anything not as performant as a PC (ex TV, rpi) can exhibit slowdowns and strange behavior.

iegg · Tue Sep 07, 2021 1:26 pm

For the time being I will install avahi on a Raspberry Pi, however I would really like to have a mDNS proxy feature available in RouterOS. Some clients (seems like MacOS needs it for the scanner of my MFP) need mDNS in order function properly, so it's just nonsense to say that there is no use for it. And yes, I strongly disagree to say that we shouldn't put IoT devices in a separate VLAN: I want to control my network, i do not want those devices to control my network. Firewall rules for inter VLAN routing should of course be implemented.

mafiosa · Wed Sep 08, 2021 2:43 pm

In v7.1 RC3 docker support is added so anyone who has/ will try implementing mDNS via container?

rextended · Wed Sep 08, 2021 2:46 pm

Please keep all Container related questions and feedback to the specific topic: viewtopic.php?f=1&t=178342&p=878204

jookraw · Thu Sep 09, 2021 1:59 pm

In v7.1 RC3 docker support is added so anyone who has/ will try implementing mDNS via container?

It would need to be able to attach docker interfaces to each vlan on the existing bridge (as it needs to be on the same broadcast domain), if possible it could work, but, still not good as a native mDNS repeater / Avahi package for ROS.

I don't think that docker / containers are the solution for the need discussed here.

control4 · Fri Sep 17, 2021 8:12 pm

Glad to find this thread and I am having problems on this as well. Hope that there is a work around for being able to Airplay music to the different zones or even air print when we are on a different VLANs.

As more and more residentials and offices are getting more “Smarter” due to the huge increase of IoT products, it actually make sense to make sure they are on a different VLANs. Most Smart bulbs and other IoT devices are Wi-Fi based hence you do not want them to bog down that particular network when everything is on the same subnet.

In regards to multicast, I am still trying to figure out how to configure it correctly as I’ve a RB3011 with a UniFi 48 Pro POE switch and trying to configure to make sure the VLANs for Video Over IP works and properly configured but no luck.

vfreex · Wed Sep 29, 2021 8:15 pm

For those who are interested, I have a simple mDNS reflector developed by myself and running in Docker. It is just hundreds lines of code in C, supporting both ipv4 and ipv6: https://github.com/vfreex/mdns-reflector

linedpaper · Tue Dec 07, 2021 10:59 pm

Just got my first mikrotik and sad to see this is still not a feature. Second guessing my rb5009 purchase over the Ubiquiti option, hopefully it gets added soon.

eduplant · Sat Dec 11, 2021 10:20 am

For those who are interested, I have a simple mDNS reflector developed by myself and running in Docker. It is just hundreds lines of code in C, supporting both ipv4 and ipv6: https://github.com/vfreex/mdns-reflector

I haven't done any testing yet but this looks really useful. My workaround from this point has been a VLAN trunk to a raspberry pi with unnumbered interfaces running avahi in reflector mode. I'll report back after I've had a chance to dig into v7 and containers.

Regarding the need for mDNS reflectors, I figure I'll add my two cents in case staff makes another appearance on the thread. In theory, nobody should *need* an mDNS reflector. In fact, the aforementioned avahi didn't implement a reflector until later and you have to turn it on in the config. avahi's primary purpose was simply being an mDNS advertisement daemon for service discovery on Linux.

The previous posters talking about routable multicast have sort of the right idea. If you need link local multicast to leave the LAN, then maybe you shouldn't use link local multicast and instead a proper routable multicast group. Agreed! Unfortunately we all are stuck with the implementation decisions that Google (Chromecast/Home/etc), Apple (Airplay/Homekit/etc), and every other IoT vendor have made. They apparently cannot fathom why anyone would be using the devices on a network more complicated than a single Ethernet broadcast domain.

In a home environment, it's true that very few people actually need multiple VLANs and to put themselves in the situation where an mDNS reflector is required. However, a lot of these protocols are not limited to the home and there may be more business use cases than you think that could stand to benefit from this. In larger enterprise/campus networks, for example, it is often no longer acceptable to land wireless clients from controllerized wireless infrastructure directly onto the same LANs as the wall jacks. When there are BYOD users on wireless in a conference room that want to present to a wired AppleTV/Chromecast, you suddenly have a problem. This has been a problem in higher education for years and is becoming more and more common in any institutional environment that has conference rooms.

The solution to this is either proprietary full-stack replacements that speak Airplay/Chromecast and include their own mDNS replacement or for the networking vendors to support a native mDNS proxy. In the US, folks in higher ed have been grumpily lobbying Apple for almost a decade now [1] to just ditch the mechanism. Ultimately, vendors like Cisco saw the need and responded by implementing mDNS proxies in their wireless controllers [2]. Maybe Mikrotik can follow, too?

[1] https://www.cultofmac.com/182919/educat ... x-bonjour/
[2] https://www.cisco.com/c/en/us/td/docs/w ... ur-DG.html

rplant · Tue Dec 14, 2021 1:18 am

For those who are interested, I have a simple mDNS reflector developed by myself and running in Docker. It is just hundreds lines of code in C, supporting both ipv4 and ipv6: https://github.com/vfreex/mdns-reflector

Cool, I installed this on a hap ac2, it seems to work ok, and appears to take up very little ram, and the executable is tiny.
Unfortunately, I needed to use a couple of VLans on the veth so need scripting to enable them first.
Ideally I would like no scripting, so could potentially remove all the other shell executables in the image.
Reducing likelihood of being owned (maybe).

Alternatively maybe Mikrotik could add this as a package...

dynek · Sat Dec 25, 2021 3:12 pm

Can't PM you rplant. Mind explaining how you achieved this? Running openwrt / metarouter on 6.x?

PackElend · Mon Dec 27, 2021 10:53 pm

For those who are interested, I have a simple mDNS reflector developed by myself and running in Docker. It is just hundreds lines of code in C, supporting both ipv4 and ipv6: https://github.com/vfreex/mdns-reflector

can you tell, if this is that the same approach as https://github.com/kennylevinsen/mdns-repeater mentioned in Setting up Avahi Reflector in Mikrotik

Finally solved this!

So from Mikrotik perspective, everything was set up properly. You might need IGMP proxy for some devices, but no need for PIM (some suggested that IGMP is not enough, even though every guide says it uses IGMP), just a simple IGMP-Proxy setup will do.

I have switched from avahi to this mdns reflector:
https://github.com/kennylevinsen/mdns-repeater

which was forked into a docker (https://github.com/monstrenyatko/docker-mdns-repeater) container mentioned further down the same discussion

With RouterOS 7.1rc3 .... would a docker image be usable?
https://github.com/monstrenyatko/docker-mdns-repeater

--------------

by the way are you aware of

We will re-release container package soon. We wanted to improve security of the package, and make sure it does not have access to things it should not access. We will sandbox it more, re-evaluate all security aspects and will release it soon, when it is ready and completely secure.

said in v7.1rc3 adds Docker (TM) compatible container support

broderick · Wed Dec 29, 2021 9:27 pm

Ok, I read most of the topics above, even though I am still trying to make sense of everything has been written.
No networking expert here, and I even didn't know that such a mDNS was a thing until a couple of days ago, so please bear with me.

I have a Mikrotik hAP ac² at the top of my home LAN (in my room). I also have a Plex server installed on a little Windows notebook. There is also a not-VLAn capable switch/ap in my dining room for guest-wifi purpose. My smart tv with the Plex app is plugged to the switch as well. They are all on the same subnet now, and of course the Plex app can reach and read media contents on the Plex server.

I'm going to change a bit my private LAN in the next few days. Ubuntu server is going to be installed on the little notebook and a Plex server, as a docker container, will be installed on it.
I am going to separate an ethernet port ( the same ethernet port which the switch is plugged to) from my Mikrotik bridge and create a new subnet on it in order to set firewall rules to isolate the switch from my main LAN mostly because of the guest wifi running on it. However, I still want the Plex app on my TV to reach and read media contents of the plex server on my ubuntu server which will remain in my main LAN/subnet. Plex server is going to be the only service accessible from another subnet (by my smart TV). I know that the best solution would be that of setting up a vlan-capable switch and put the guest-wifi and my smart-tv on different VLANs in order to handle them with different firewall rules, but I'm not going to buy one..at the moment at least.

So, in your opinion, what would the best solution be in order to achieve my goal only with the devices I have at the moment? Thanks

brotherdust · Thu Jan 06, 2022 7:19 pm

Yes, the question is, why separate the IoT, if you don't really need to separate ?

Normis, as I'm sure you are aware, IOT devices have a notorious reputation for poor security practices. In order to limit the impact of these security problems, a conscientious network administrator will place these devices on separate VLAN. The VLAN provides an implicit context to apply additional security policies. The expectation that really _any_ IOT device is secure is foolish at best.

Providing a native mDNS/SSDP repeater would allow administrators to follow the good practice of keeping these devices in a separate security context, whilst also making it possible for the more user-friendly functions to work across contexts.

Please consider adding this functionality to RouterOS 7. It is sorely needed and has been requested across the forum by your customers for years.

Thank you!

Edit:
If the answer is “no”: since RouterOS 7 lacks a PIM dense-mode implementation (for now), maybe the clever guys on your team could come up with a workaround using PIM-SM and post a working example config to the docs?

invader zog · Fri Jan 07, 2022 1:52 am

I'd also like the feature.

All of my wireless, IOT, and entertainment devices are on one network (guest)
My servers and desktops are on another network (private)
I control and limit access from the guest to the private network

I'd like to be able to do a wireless sync of my iPhone from my desktop computer

If there are any suggestions/guides for how to accomplish this, I'd love to here. The only device I have that communicates on both networks is the MT, but I do have windows and linux servers running in my private network and could install a service there. I've been a MT user for decades now and am reasonably savvy with networking, but I don't know much about mDNS and forwarding broadcast traffic...

TonyJr · Tue Jan 11, 2022 11:53 am

If this is implemented, some kind of way to filter which devices/services are repeated and to which interface would be handy. Sometimes you may not want everything advertised.

Kentzo · Sun Jan 23, 2022 1:41 am

I don't understand why RouterOS's PIM-SM was suggested in the thread: it requires devices to enter / leave multicast groups via IGMP.

mDNS (Apple Bonjour) does not use IGMP, PIM-SM and IGMP-Proxy are useless for it.

Kentzo · Wed Feb 02, 2022 2:19 am

Avahi on your raspberry is reflecting mDNS, ROS does nothing here.

Kentzo · Wed Feb 02, 2022 2:50 am

Haha, I misread Till and TIL

CTSsean · Thu Feb 03, 2022 5:12 pm

Yes, the question is, why separate the IoT, if you don't really need to separate ?

Trust.

The same reason is why you firewall your input chain from the world... You can't always trust that people won't do the right thing. This is the reason for a LOT of vlans.

However with IoT, there are service needs that have to be met. Easiest example: Chromecast. You need to have mDNS to be able to search from a home / production vlan to the Chromecast device discover the device and set up the initial communication. Once you choose to cast to a specific device... your mobile device is taken out of the loop and the data is pulled from the server / internet service. However, doesn't mean you should trust that Chromecast on your home network. Google and other entities have proven that they want data at nearly all costs. Similar goes with Chinese security cameras.

The design of Chromecast (and other google products) is to capture data (while providing a cool service). We want to limit what PERSONAL data google can capture.

Buckeye · Tue Feb 22, 2022 8:26 am

Yes, the question is, why separate the IoT, if you don't really need to separate ?

I spend a lot of time on the Ubiquiti EdgeMAX forums, and there are many noob questions related to getting things to work across vlans.
In my opinion, many people use vlans without enough foundational understanding. They have just heard about how unsafe IoT devices are, and that the IoT devices should be kept separate, then find some recommendation for the ER-X, then come asking for help setting it up with vlans.
Then, soon after they get vlans working, they come back complaining that things don't work any more (chromecast, sonos, printer discovery, etc.)
I put mDNS repeater into the same class as UPnP. It is a bad idea from a security standpoint, but most home users are really more interested in ease of use than security, especially when it comes down to having to deal with family members' complaints about things that used to work no longer working.
These posts always remind me of the https://imgs.xkcd.com/comics/sandboxing_cycle.png cartoon.
If this does get added, it should not be the default. But I can understand why many people want it. It is a compromise between real security and no separation. Supporting mDNS repeater gives more separation than having everything in the same subnet/lan. It is the same argument for allowing a user to use https with "obsolete insecure ciphers" after making them make a manual exception vs. forcing them to use http with absolutely no protection.
FWIW, I don't use either UPnP or mDNS repeater. I just put the untrusted stuff on its own vlan with its own wifi SSID. That does mean I can't cast from my trusted PC, but I can live with that.

ishanjain · Thu Apr 14, 2022 12:00 am

I am just echoing my use case here.

I have 4 private vlans for 4 homes and 1 common guest vlan across all 4 homes.
The TVs in each home sit in their private vlan but sometimes when guests arrive, They want to be able to cast to the TV.

Internet traffic in guest vlan is routed over a vpn and I do not want guests using the private vlans _BUT_ I also want them to be able to cast to the TVs.

Google cast(& Presumably apple's casting tech) requires mdns for discovery and simply will not work if it can't see the TV. It'll be nice to be able to allow specific mdns traffic to be repeated across vlans. It's less safe than isolating the two vlans completely but that will not work in my case.

If I tell them that guests simply can not cast to the TVs, They'll most likely end up sharing the private vlan's password with them and I think that's just worse. :/

Buckeye · Thu Apr 14, 2022 2:43 am

I have 4 private vlans for 4 homes and 1 common guest vlan across all 4 homes.
If I tell them that guests simply can not cast to the TVs, They'll most likely end up sharing the private vlan's password with them and I think that's just worse. :/

So you want your guest to be able to cast to another home? Isn't that what you are asking the ability to do, given you have "1 common guest vlan across all 4 homes."
I won't go into it more, because this thread isn't the proper place, but I think there are better solutions to your problem than mdns to a common guest network.

MartyMcSly · Sat Apr 30, 2022 7:06 am

All this do not change my disbelief on need separation from IoT and home private network.
(On home point of view, business/work is another thing...)

Anyone who's had their home network locked up by ransomware would see the value in separate VLANs.

Especially if they need their home network to access their work VPN. Say, hypothetically, they might be working from home because of a pandemic, perhaps?

Many IoT devices are built to a price, so security is skimped. They are notorious for being attack vectors.

An IoT VLAN is pretty much home internet security 101 these days.

ishanjain · Sat Apr 30, 2022 6:45 pm

So you want your guest to be able to cast to another home? Isn't that what you are asking the ability to do, given you have "1 common guest vlan across all 4 homes."

Yes, but this won't remain turned on _forever_. I'll only be turning on this repeater when I have some guests at home. (I am writing a wrapper for the mikrotik API and people in 4 homes will get a simple interface to turn this on/off)

vikinggeek · Sat Apr 30, 2022 7:06 pm

I am writing a wrapper for the mikrotik API and people in 4 homes will get a simple interface to turn this on/off

Care to share? Looking for something similar such the wife/kids can turn on/off a feature without having access to the router.

craigxau · Tue May 03, 2022 5:40 am

I too have a need for an mDNS repeater for the same reasons.

=> I segregate my networks
=> I have devices across multiple networks that i would like to see each others broadcasts (within limits)
=> I purchased a ton of mikrotik because i an not sheep and walk in a flock
=> i want and like to use the power of the equipment i purchased. Mikrotik is powerful like no other and mDNS is a valid feature request.
=> i am in a group of mikrotik user peers that respect each others opinion and collaborate not criticize
=> i choose to have a high degree of separation within my network
=> if you choose to dump all your equipment onto big flat networks then that's your choice and is totally ok. But not for me.

Adding this mDNS reflector feature would be appreciated. Thanks for your time.

Corbie · Wed May 04, 2022 4:40 pm

Ever home user needs mDNS.
I am a home user and do not need it.
Why is your assumption so absolute?
It is absolute-ly false.

My 4,000 contracts (home and business), corresponding to more than 16,000 people,
do not have it and no one has ever complained about it.

Please explain which critical part of the home network does not work without mDNS.

Thanks.

Guessing your customers are not spoiled as others

We have homestead with smarthome things implemented everywhere which have their own vlan. There is audiosystem around whole farm, which is connected to Loxone server( basically smarthome controller) but employee network is ofcourse on another vlan. And only way to control audioserver is via AirPlay where only mDNS or Bonjour or whatever apple bullshit works, you cannot manually add them so mDNS support would be our only solution. Now we have separate wi-fi for controlling the smarthome things but its kind of annoying for employees to need to switch wi-fi when they wanna change songs for example and then switch back if they wanna access company data. Its kinda specific problem but that doesnt mean there are none.

rextended · Wed May 04, 2022 5:18 pm

Use Alexa devices...
From my Office I can control devices at my Home (different cities and networks) with vocal commands...

mafiosa · Wed May 04, 2022 6:40 pm

Use Alexa devices...
From my Office I can control devices at my Home (different cities and networks) with vocal commands...

You will suggest everything else to prove that mikrotik doesn't need to implement mDNS. Such a simp!

rextended · Wed May 04, 2022 6:43 pm

Zerotier?

If mDNS proxy is implemented, the RFC is broken because on RFC mDNS must not be forwarded outside local LAN...

Corbie · Wed May 04, 2022 11:36 pm

Use Alexa devices...
From my Office I can control devices at my Home (different cities and networks) with vocal commands...

im gonna tell them to change system who cost them 20 000 euro

(its more of home automatization then smarthome) but if i have to be honest we switched them to fortigate

bmann · Sat May 07, 2022 1:09 pm

I see mDNS proxy/repeater as valid feature request and understand why many people want such feature.
But do not understand why some people fight against it so dogged.

During decades networking evolved - we have switching (L2), routing (L3), VLANs, private VLANs, VRFs, VPNs etc. and all tends to separation/segmentation so recommending someone to
put everything to one L2 is strange.

@rextended
You fight mostly against mDNS here. But then you wrote:
"All this do not change my disbelief on need separation from IoT and home private network.
(On home point of view, business/work is another thing...)"

So if you see a value for business, why to deny the same value for home networks? If you do not want it, OK. But why to fight with people who want it.

@normis
Let me give you example of topology you may have at home:
- trusted wired LAN
- trusted (private) WLAN
- guest WLAN
- DMZ for NAS/servers etc,
- DMZ for IoT/media devices

So from 'trusted' LANs you have access to all DMZs, internet etc. And you need the option to cast to media devices in DMZ.
The guest WLAN has access only to internet, but ability cast to media devices. And of course DMZ devices are limited too.

So even if I need to allow some traffic and communication between trusted LANs and media devices, the media/IoT devices are still limited to access other parts of network.
Putting it to one flat L2 would give them more space than it is needed (and all devices are reachable mutually).
If I put media/IoT to separate L3 network, I can even isolate from each other and outside communicate is filtered by FW rules.

At the end it is Mikrotik's decision. It is not only about home networks, but too about small bushiness etc. Even big names can do mDNS repeater/forwarder in some products as in business it is expected to have separated networks. And it is Mikrotik's decision if they aim to business or not.

hapoo · Mon May 09, 2022 7:29 pm

Another vote here for the feature.

If I'm away from my network and I VPN in, services that rely on mDNS are unavailable. It would be nice to be able to have mDNS requests go across from the VPN subnet to my main subnet. If anyone knows how to do this without an mDNS repeater feature, let me know.

whmcr · Mon May 09, 2022 9:46 pm

To those people asking for mDNS, can you give examples where it will be useful?
Rextended provided solutions for the given examples. Maybe there are more examples?

I've seen this implemented on networks using Aruba APs, specifically with AirGroup. The most common deployment reason I've seen is for AirPrint or AirPlay, ChromeCast to allow these devices in another network to be discovered by guests on other networks. Obviously appropriate firewall is required between the networks, or the segmentation is not as useful.

tcxelhyoqiqhmhelha · Thu Jun 16, 2022 6:25 pm

FYI, this thread is the top google result for "multicast DNS mikrotik" and it's funny how this isn't implemented yet. I just wanna be able to plug a raspberry pi with a hostname "raspi" into my network and immediately access it by sshing "raspi.local" without having to figure out which 192.168.88.* it got assigned to.

DarkNate · Fri Jun 17, 2022 9:24 pm

Do not have any sense make separate VLAN of IoT devices and then set Google and Smart TV on "main" Wi-Fi

IoT devices lack security, has vulnerabilities etc. It's always wise to separate them with VLANs.

And with IPv6 you can firewall to accept, established, related, icmpv6 and drop the rest for the IoT VLAN without impacting the main VLAN where default firewall on macOS/Windows/iOS/Android is out of the box doing just that and hence should permit native end-to-end reachability without a middle box for the main VLAN to benefit from native IPv6 without the need for STUN/TURN/ICE/WebRTC and other bs.

mitzone · Wed Jun 22, 2022 10:31 pm

+1 for the mDNS feature also.
Landed here from google.

I am having my IoT devices in a separate VLAN and encounter difficulties managing those with Home Assistant software.

I am baffled that there are no real geeks on Mikrotik side to understand the need for mDNS.

Cheers!

ca202 · Sat Jul 02, 2022 10:29 pm

The problem is there is no point separating trusted and untrusted vans when you allow the untrusted one inject an advertisement into the trusted one to get the trusted one to call into it not to mention allowing the untrusted one to see all that is advertised on the trusted one. Very helpful in its quest to pretend being one of them.

It would be nice to be able to copy mDNS entries in to static config on the trusted one though. Sort of like a static ip reservation flow. Pick it from list of what is on untrusted side to add static copy of it on the trusted side.

Valerio5000 · Thu Jul 14, 2022 11:38 pm

I also happened to go to Google here, I use HAP AC2 which acts as a VPN server to other networks with other RBs. Same thing if through Windows or Android I enter the VPN directly .. well it would be fantastic to have the ability to search for a client on a remote network via DNS name. I have been trying to put a solution in ROS directly for months now I understand that it is useless, is it possible that the Mikrotik staff does not care about this convenient functionality?

+1 for me

CTSsean · Mon Aug 15, 2022 6:52 pm

The problem is there is no point separating trusted and untrusted vans when you allow the untrusted one inject an advertisement into the trusted one to get the trusted one to call into it not to mention allowing the untrusted one to see all that is advertised on the trusted one. Very helpful in its quest to pretend being one of them.

It would be nice to be able to copy mDNS entries in to static config on the trusted one though. Sort of like a static ip reservation flow. Pick it from list of what is on untrusted side to add static copy of it on the trusted side.

That's not true. It's called limiting access. For example, say you wanted to expose port 22 to another vlan, but not port 23, you can limit what can communicate.

jbl42 · Mon Aug 15, 2022 8:23 pm

That's not true. It's called limiting access. For example, say you wanted to expose port 22 to another vlan, but not port 23, you can limit what can communicate.

Exactly. Even Enterprise boxes from Cisco, Juniper and the usual suspects provide mDNS proxies to allow AppleTV based screen sharing among subnets so IThings can be used as sources for projectors and big screens in meeting rooms.
But it's not unsual in the forum here to have the crowd denying the need for features almost all other vendors have for good reasons. The MT community is a bit special in that regard.

5nik · Thu Sep 29, 2022 5:08 pm

+1 vote
I'm facing problem with AirPlay (TV is in different VLAN then computer). Container is not solution for me, because TILE arch.

magchiel · Sun Oct 02, 2022 9:51 am

+1 for this feature.

And while we're on the subject of IoT devices, I own several products that rely on UDP broadcast [^1] (Squeezebox to name one ubiquitous device).
I don't mean to hijack but merely want to add to the point: while I understand all the replies questioning the practices of creating such connections between VLANs and subnets, the reality is anyone who is mixing a home and business environment (i.e. SOHO) will somehow need the tools to work around devices that weren't designed in setups for multiple L2 segments, balancing usability and security.

The ability to selectively relay, block or allow these mDNS and UDP broadcasts in non-bridged settings, IMHO would immediately turn RouterOS into the swiss army knife for SOHO environments. Suggestions to run this in Docker on a MT-device from a management point of view to me still not ideal as for every change in the network I would need to recreate the container (i.e. with the changed interfaces - yes I understand that I could script this command) rather than just change a setting in RouterOS. At this point, using docker-compose on my Docker node would probably be simpler from a management point of view.

[^1]: According to some forum posts you're supposed to get this to work using dst-nat, but I was never able to get it working without running a Pi with https://github.com/nomeata/udp-broadcast-relay/ (incidently also running Avahi reflector) - but it's yet another to configure, update etc. This is why for now I've decided to merge the "trusted" access layer (managed phones, laptops etc.) and IoT segments into one untrusted L2 segment and require internal VPN to the business applications. From a security perspective this is arguably the cleanest solution, but from a usability perspective less so and it doesn't isolate the different devices as as much as I would like to.

Valerio5000 · Mon Oct 03, 2022 5:46 pm

+1 for my !!

Guscht · Tue Oct 11, 2022 12:05 pm

My 2 cent:

Stop asking MT to do a non-RFC thing. MT will most likely not implement such a tool.
MT as a router manufacturer will always obey RFCs, and your wish is to forward/feflect/proxy local frames.

mDNS uses the follwing multicast address:
224.0.0.251 mDNS

IPv4 Multicast Address Space Registry

The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive,
is reserved for the use of routing protocols and other low-level
topology discovery or maintenance protocols, such as gateway discovery
and group membership reporting. Multicast routers should not forward
any multicast datagram with destination addresses in this range,
regardless of its TTL.

https://www.iana.org/assignments/multic ... sses.xhtml

But there is a good thing, you can build your own small mDNS-reflector with AVAHI.
All you have to do is setup a Raspberry, install AVAHI and connect this RPi with the desired VLANs.

E. g. you have VLAN10 and VLAN20, all you have to do is, to create a VLAN trunk, tagged VID10,20 and connect this to the RPi. Thats a step you can implment within a few minutes. So, stop waiting/asking for a feature that will never come and go on and do it your own!

Further references:
https://www.cisco.com/c/en/us/td/docs/s ... er_01.html
https://www.dell.com/support/kbdoc/de-d ... es?lang=en

jbl42 · Tue Oct 11, 2022 1:20 pm

Yes, 224.0.0.0/24 addresses shall not be and are not routed by normal routing.
That's why an additional mDNS reflector is required in the first place to propagate mDNS among subnets.

Technically, it is an odd thing to do. But practically there are many add-on implementations by Cisco et al to make AirPlay working so all the corporate iThings can use AirPlay to share to big screens using AppleTVs. Such setups are widely seen in coorp networks, because of the iThings management loves to use.

No one is asking to route mDNS violating RFCs. It is about having an optional service working as reflector among subnets, on top and independent of normal routing.
Similar to the multicast proxy allowing multicast traffic to pass the router, which normally would not be routed.

One of the Cisco flavors of mDSN reflector is called "Service Discovery Gateway" as described here:
https://www.cisco.com/en/US/docs/switch ... 10010.html
All other usual suspects like Juniper have similar addons.

Yes, it can be done using a Avahi on a raspi. Yes, on certain MT devices it can run as a docker container.
While I personally do not need it, I see it would be easier to have it as an (optional) package for ROS were required and it is a valid feature request.
I do not get the resistance here against a feature widely available on other brands and widely used in coorp networks.

There might be reasons for MT not to add it, but routing RFCs are not part of it. mDNS reflectors are not related to routing.
mDNS reflectors are a required evil to help with things initially designed for single subnet SOHO networks like Airplay. But creeped into coorp networks due to the popularity of iThings in management.

Guscht · Tue Oct 11, 2022 2:15 pm

It do not say they have to ROUTE (IP-Routing at Layer3).

IANA says:

Multicast routers should not forward
any multicast datagram with destination addresses in this range,
regardless of its TTL.

MT is a Multicast-Router, so MT will never FORWARD mDNS. This applies to "Proxy" or "Reflect" too.
Of course, MT could implement such a tool, but they will almost never do. Instead of asking for years, invest a few minutes and create your own solution.

I will not say the wish is totally obsolete and for a lot people a much easier solution, but as written, its a wish that will (most likely) never come true with the native MT ROS.

BTW: The right way to aks for the functionality would be: Not MT should create a workaround (mDNS forward over L2 boundaries is exactly this). Ask Apple to use a protocol which is up-to-date (VLANs are not a fancy stuff from year 2050 anymore). They (Apple) have chosen mDNS which is a Link-Local-Protocol. They know exactly what this means in regards of VLANs. Its not MTs fault, its Apple fault to use mDNS.

woland · Tue Oct 11, 2022 2:28 pm

I They know exactly what this means in regards of VLANs. Its not MTs fault, its Apple fault to use mDNS.

1. Yes, mDNS is an "rfc thing"
https://www.rfc-editor.org/rfc/rfc6762 (since 2013!)
2. every big vendor has some implementation
3. many people use it and it will probably get more and more important with IOT (people are generally lazy)
4. there are several useful open source implementations
So IMHO it would be nice to have.

Edit: something else comes to my mind, the Internet is full of workarounds, which were or are considered harmful & non standard, just to mention NAT, VLSM,

BR

jbl42 · Mon Oct 24, 2022 11:51 pm

Its not MTs fault, its Apple fault to use mDNS.

As a hobbyist, this might be a valid point.

As a professional:
Have you ever tried to sell gear not supporting the managements beloved iThings to a company?
Ever tried to explain to a "important" manager that his shiny new iPad Pro cannot connect to the screen in the meeting room because it's Apple's fault?
I bet not.

ister · Thu Oct 27, 2022 3:48 pm

It is not a valid point even for hobbyists. I was explaining to a colleague how proud I am using mikrotik products, and of the capsman network I have setup and the problem I have to "cast" video from my mobile phone connected to wifi, to my TV connected to the wired network (on different networks), and he replies: "oh, you have to configure mDNS". He is using products of another vendor, and it was implemented years ago....

JordanReich · Wed Nov 09, 2022 7:29 pm

+1, has my vote

ffries · Wed Nov 09, 2022 8:25 pm

+1 for mDNS repearter.

I don't want to run an additional computer just for mDNS.
OpenWRT offers an mDNS package, you may use it.

lars18th · Mon Nov 21, 2022 4:52 pm

+1 to the mDNS reflector. It would be a nice feature to have.

lars18th · Mon Nov 21, 2022 4:55 pm

+1 to the mDNS reflector. It would be a nice feature to have that would help segmentation for IoT devices without additional hardware.

urknall · Wed Nov 23, 2022 3:40 pm

+1 to the mDNS reflector. I would use this feature also...

kJpermol · Wed Nov 23, 2022 4:17 pm

+1 for mDNS feature.

Pl07R3K · Fri Nov 25, 2022 4:17 pm

+1 for mDNS feature

Simonej · Mon Nov 28, 2022 2:23 pm

Hello, in the meantime we wait for the highly desired mDNS repeater/reflector, has someone tried any container package and is able to give some advice for the easiest one?
Those are the ones found:
- https://hub.docker.com/r/yuxzhu/mdns-reflector
- https://hub.docker.com/r/ydkn/avahi
- https://hub.docker.com/r/flungo/avahi
- https://hub.docker.com/r/angelnu/mdns_repeater
- https://hub.docker.com/r/monstrenyatko/mdns-repeater

Amm0 · Mon Nov 28, 2022 4:57 pm

in the meantime we wait for the highly desired mDNS repeater/reflector

Or, how about just a mDNS listener that shows up in /ip/neighbors to start?

On reflection, and not saying Mikrotik shouldn't add Avanti-like features... but I still struggle that if you need mDNS to have a different scope than the existing Layer2 segment, something is wrong with your network design. If the only issue is printers/etc, SRV records in DNS, or using an LDAP sever, seems like a better approach to discovery needs by apps.

Simonej · Mon Nov 28, 2022 5:20 pm

Could agree with your statement, currently using DNS Static for printers, Chromecast etc... but for example mobile phones are not able to the printer using ip or name.

broderick · Tue Nov 29, 2022 11:49 am

My two cents on this matter. I still feel no need for such a mDNS feature actually. I have a few devices on a subnet; among them, a plex app runs on my smartTV which can connect to my Plex server laying on a different subnet; just a couple of firewall rules make the job done. However, I think that this mDNS is something better to have on our Mikrotik device than not, considering also that other competitors already have had it for a long time. If you don't use it you can just leave it turned off or disable it.

Amm0 · Tue Nov 29, 2022 4:36 pm

Could agree with your statement, currently using DNS Static for printers, Chromecast etc... but for example mobile phones are not able to the printer using ip or name.

Always the printers... Didn't mean sound that harsh. It's actually problem: you'd like still find things, like printers, on the entire network, even if you "segment stuff" (e.g. use VLANs/multiple bridges/switch chip).

To answer the question about the using mDNS containers, I'm just not sure any of them are "simple". You're kinda forced to wire up all the Mikrotik [v]LANs to the container on the RouterOS side (otherwise the container wouldn't have access to need networks to use multicast on). After that you have to have configure Avahi (or similar) to describe how you want to listen/reflect/redirect the provided VLAN. And for a pre-packaged container, you have to describe this in environment variables.

So to your question about "what container to use?", my advice is to start with your own Dockerfile that has the Avahi config file you want - to me that generally an easier approach, than un-winding how someone else mapped the actual mDNS configuration files USED to the potentially more limited environment variables wrapped up in a pre-packaged container (e.g. Docker Hub).

That being said, if you can't access something by IP address, not sure mDNS would help – at the end of mDNS process it's just an IP address to use (e.g.mDNS = same as DNS, just multicast instead unicast). So mDNS providing the same IP you're already trying (and not working) on the smartphones/etc. to your printers may not help.

abishur · Wed Nov 30, 2022 8:05 pm

I could also use this feature. I have an Occulus Quest 2 and have setup wireguard to connect my house to a family member's house so I can easily backup important files to a remote site. We also often get together and I wanted to let my nieces and nephews enjoy some games that wouldn't be majorly impacted from some additional latency. But like apple and chromecast, the Airlink feature of the Occulus relies on mDNS.

I'm kind of perplexed by the argument that "the issue lies with apple for using mDNS". Why are we arguing against reality? Rather than complaining that company "X" shouldn't have used it, don't we just have to deal with the fact that Apple, Meta, and Alphabet, the biggest names out there ARE using it? Combining that with the fact that companies like Cisco and Juniper offer mDNS reflection packages there is a valid way to implement it that meets "RFC" specs, right?

In the meanwhile, I saw some people discussing using something like a raspberry pi running Avahi. How would one go about setting that up with the MT router itself being the wiregaurd host?

Buckeye · Thu Dec 01, 2022 3:00 am

Yes, the question is, why separate the IoT, if you don't really need to separate ?

Why have a firewall if you are going to use port forwarding?

Why support UPnP when you can use port forwarding instead with better control?

The reason is because there are many users that don't want complete isolation, but still want convenience more than absolute separation, and many don't even want to RTFM, they just want a simple "click this to make mDNS work".

The fact is, most other vendors selling into the home market segment support mDNS repeaters. Just like they support UPnP2 or UPnP.

MikroTik obviously doesn't plan to add support, even though there are many request for the feature, based on the age of this thread, the retorical question posted by @normis, followed by many posts, but then crickets from MikroTik.

So if this is an important feature for you, vote with your wallet and buy a router that does support it. They are not hard to find. Your only other option at this time is to add something like an unobtainable Raspberry Pi or to have a MikroTik router that supports containers (or OpenWrt see this for example).

I really don't understand MikroTik's stance on this. There is no need to make it the default, and I wouldn't want it to be. But what is the reason for not adding the functionality? Is it that it takes too much code space in the limited flash on many MikroTik routers?

I really don't care about it myself, but it seems like adding the functionality should be relatively easy, given that there are many opensource implementations available. But I do think that NIH (not invented here) syndrome is strong at MikroTik, for example their refusal to support rfc3021/31 subnet masks, because they invented their own proprietary /32 method that can work with /31 in certain circumstances, but not all.
And then MikroTik responds with posts like this that say their /32 subnets are superior to rfc3021, and that's the end of the discussion on their part. "RFCs? We don't need no stinking RFCs"

Amm0 · Thu Dec 01, 2022 5:07 am

I'm 100% with @Buckeye.

there is a valid way to implement it that meets "RFC" specs, right?

I'll just point out reflection and repeaters are NOT in any IETF RFC (at least as AFAIK), for reasons explained below.

The TL;DR version is the RFC answer to dealing mDNS needing to span the local network/segment is actually RFC6763, https://www.rfc-editor.org/rfc/rfc6763#page-30 which is SD-DNS part of mDNS. Essentially if you add _whateverservice._tcp... in the "real" DNS, you can always have a device being able to be found. Most mDNS lookups will fall back to unicast (regular) DNS is how that all works. mDNS is really more about dynamically creating SRV records, but if you only have a handful of home things, a few the right static DNS entries save a container full of work.

In the most recent RFC in the mDNS line, RFC8766, the summary there actually covers most of the ground in this thread, and the agreed IETF reasoning. See below. The note about Wi-Fi was interesting...

Multicast DNS [RFC6762] and its companion technology DNS-based
Service Discovery [RFC6763] were created to provide IP networking
with the ease of use and autoconfiguration for which AppleTalk was
well known [RFC6760] [ZC] [ROADMAP].

For a small home network consisting of just a single link (or a few
physical links bridged together to appear as a single logical link
from the point of view of IP), Multicast DNS [RFC6762] is sufficient
for client devices to look up the ".local" host names of peers on the
same home network, and to use Multicast DNS-based Service Discovery
(DNS-SD) [RFC6763] to discover services offered on that home network.

For a larger network consisting of multiple links that are
interconnected using IP-layer routing instead of link-layer bridging,
link-local Multicast DNS alone is insufficient because link-local
Multicast DNS packets, by design, are not propagated onto other
links.

Using link-local multicast packets for Multicast DNS was a conscious
design choice [RFC6762]. Even when limited to a single link,
multicast traffic is still generally considered to be more expensive
than unicast, because multicast traffic impacts many devices instead
of just a single recipient. In addition, with some technologies like
Wi-Fi [IEEE-11], multicast traffic is inherently less efficient and
less reliable than unicast, because Wi-Fi multicast traffic is sent
at lower data rates, and is not acknowledged [MCAST]. Increasing the
amount of expensive multicast traffic by flooding it across multiple
links would make the traffic load even worse.

Partitioning the network into many small links curtails the spread of
expensive multicast traffic but limits the discoverability of
services. At the opposite end of the spectrum, using a very large
local link with thousands of hosts enables better service discovery
but at the cost of larger amounts of multicast traffic.

Performing DNS-based Service Discovery using purely Unicast DNS is
more efficient and doesn't require large multicast domains but does
require that the relevant data be available in the Unicast DNS
namespace. The Unicast DNS namespace in question could fall within a
traditionally assigned globally unique domain name, or it could be
within a private local unicast domain name such as ".home.arpa"
[RFC8375].

In the DNS-SD specification [RFC6763], Section 10 ("Populating the
DNS with Information") discusses various possible ways that a
service's PTR, SRV, TXT, and address records can make their way into
the Unicast DNS namespace, including manual zone file configuration
[RFC1034] [RFC1035], DNS Update [RFC2136] [RFC3007], and proxies of
various kinds.

mattycourtney · Fri Dec 02, 2022 6:00 am

+1 to the request for an mDNS repeater! Without the mulicast package on ROS 7 it's not currently possible to use mDNS inter-VLAN; having an mDNS repeater would solve this

sergeysi · Tue Dec 06, 2022 9:15 am

One more request for mDNS repeater. Currently there is no way to use AirPrint-like features in corporate networks with printers and users on different VLANs without using VM with mDNS repeater.

mag1024 · Fri Dec 09, 2022 11:33 am

If you have a recent-enough router (one that supports containers) you can use https://github.com/mag1024/mikrotik-doc ... s-repeater to run the repeater directly on the router, without a VM.

That said, +1 for making this a built-in feature.

Valerio5000 · Sun Dec 11, 2022 12:09 am

+ 1 !

digitik · Tue Dec 13, 2022 11:11 am

+1

First of all it story comes from bad Mikrotik DNS, that can not handle more then ~10k entries for spam filter. OK, replacing it by pi.hole with crazy performance gain. Then printserver that Mikrotik can not handle at all. Ok, installing cups and raspberry sharing printers by mDNS. Ok, trying to make normal VPN from Mikrotik and no way to establish connection to protonvpn (Mikrotik have tiny part of standard, that it VPN supports). Ok, installing OpenVPN on pi, successful connect to proton. Speed is better then on 16 core Mikrotik . OK, redirecting pefixes to raspberry and it does not work without hairpin NAT. Ok, moving raspberry to another subnet+vlan, now VPN works fine and Iam loosing printers. Damn...

ffries · Sun Dec 18, 2022 3:25 pm

If you have a recent-enough router (one that supports containers) you can use https://github.com/mag1024/mikrotik-doc ... s-repeater to run the repeater directly on the router, without a VM.

The veth interface has no firewalling (as far as I know on other systems). So how to make sure that only the requested ports go through the VM?

ffries · Sun Dec 18, 2022 3:29 pm

The TL;DR version is the RFC answer to dealing mDNS needing to span the local network/segment is actually RFC6763, https://www.rfc-editor.org/rfc/rfc6763#page-30 which is SD-DNS part of mDNS. Essentially if you add _whateverservice._tcp... in the "real" DNS, you can always have a device being able to be found. Most mDNS lookups will fall back to unicast (regular) DNS is how that all works. mDNS is really more about dynamically creating SRV records, but if you only have a handful of home things, a few the right static DNS entries save a container full of work.

So should I declare for a CUPS server? Should I listen to my printer with Wireshark?

Amm0 · Sun Dec 18, 2022 4:51 pm

If you have a recent-enough router (one that supports containers) you can use https://github.com/mag1024/mikrotik-doc ... s-repeater to run the repeater directly on the router, without a VM.
The veth interface has no firewalling (as far as I know on other systems). So how to make sure that only the requested ports go through the VM?

Just an idea, you could add a bridge's filter to restrict the container's veth to only allow multicast traffic I suppose.

Amm0 · Sun Dec 18, 2022 4:57 pm

The TL;DR version... RFC6763, https://www.rfc-editor.org/rfc/rfc6763#page-30 which is SD-DNS part of mDNS. Essentially if you add _whateverservice._tcp... in the "real" DNS, you can always have a device being able to be found. Most mDNS lookups will fall back to unicast (regular) DNS is how that all works. mDNS is really more about dynamically creating SRV records, but if you only have a handful of home things, a few the right static DNS entries save a container full of work.
So should I declare for a CUPS server? Should I listen to my printer with Wireshark?

On a Mac, there is a command "dns-sd -Z" that outputs the LAN's DNS records from mDNS broadcast, into a DNS zone file that can be use in a DNS server. I presume some similar tool exists for Win/Linux. Only issue is Mikrotik's DNS doesn't support one of the DNS type (PTR), so those records have to go into some other DNS server (perhaps Pi-Hole, but I haven't tested)

Pinter · Wed Dec 28, 2022 3:29 am

I’m new here, just waiting on the arrival of my new Mikrotik router which I was really excited about… am I to understand that in (almost) 2023 mDNS is NOT a feature of Mikrotik routers?? I have a house full of IOT devices and use Home Assistant to bridge everything beautifully to homekit for me. All my IOT devices, cameras etc. My plan was to get a good router and actually segment everything into separate LANs. Im coming from pfsense, am I going to regret this decision?

vergessen · Wed Dec 28, 2022 12:36 pm

I’m new here, just waiting on the arrival of my new Mikrotik router which I was really excited about… am I to understand that in (almost) 2023 mDNS is NOT a feature of Mikrotik routers?? I have a house full of IOT devices and use Home Assistant to bridge everything beautifully to homekit for me. All my IOT devices, cameras etc. My plan was to get a good router and actually segment everything into separate LANs. Im coming from pfsense, am I going to regret this decision?

Did you buy something that you can run a container on? If not then yes you’re going to regret this purchase. It has been made clear certain things mdns, fixing ipv6 on their wireguard implementation etc are just not in the cards. You can of course do it yourself with a container on mikrotik for mdns or like so many things in this ecosystem. Get another device and do the lifting for the nice to have features you won’t find here.

ffries · Thu Dec 29, 2022 11:57 am

I’m new here, just waiting on the arrival of my new Mikrotik router which I was really excited about… am I to understand that in (almost) 2023 mDNS is NOT a feature of Mikrotik routers?? I have a house full of IOT devices and use Home Assistant to bridge everything beautifully to homekit for me. All my IOT devices, cameras etc. My plan was to get a good router and actually segment everything into separate LANs. Im coming from pfsense, am I going to regret this decision?

Brooding it over, mDNS allows information to flow from on vlan to another.
This may be not secure by design, this may be the explanation why Mikrotik does not plan to support it.

vergessen · Fri Dec 30, 2022 11:33 am

Brooding it over, mDNS allows information to flow from on vlan to another.
This may be not secure by design, this may be the explanation why Mikrotik does not plan to support it.
[/quote]

I can also expose winbox ports to the internet, have no firewall. All terrible security choices but the decision is left to me. mDNS is a standard found everywhere else. Seems broken by design to say we won’t support this for security reasons. That’s a decision that the user must make just like having sane firewall rules for their environment

Buckeye · Sat Dec 31, 2022 4:37 am

Seems broken by design to say we won’t support this for security reasons.

That didn't prevent MikroTik from supporting port forwarding or UPnP. And evidently MikroTik doesn't even support upnp2 (miniupnpd) which offers more secure options. see this thread UPnP security questions

So using the security card isn't a valid excuse for not allowing a user to choose to use an insecure "feature". I don't think anyone is requesting the option to be the default.

disclaimer: I don't use port forwarding, upnp, upnp2 or mdns repeater or reflector on my ER-X, but they are all options that are available.

This is a bit like the major broswers no longer supporting "weak" SSL/TLS options at all. And forcing users that have legacy equipment that does not support the newer versions to use http or an old version of the browser that will allow an exclusion for a specific site. When you look at the options of poor security or no security, which is better?

Sun Jan 01, 2023 12:16 am

using the security card isn't a valid excuse

I think I might be one of the most likely of this forum's members to go around waving the "security" flag, and even I will tell you that a flat refusal to support mDNS forwarding on security grounds is bogus.

mDNS forwarding is a routing decision made by the network's manager. Routing is what routers do, per the admin's instructions.

mDNS is no more a "security risk" than is PIM-SM. Yes, it should be off by default, but it should be available, left up to the admin to employ properly when enabled.

Sun Jan 01, 2023 12:21 am

Did you buy something that you can run a container on? If not then yes you’re going to regret this purchase.

I'm not certain about that. I still think this approach is worth trying.

If you're wondering why I don't try it and report back, it's because on the networks I manage that have mDNS devices, I don't (yet) use VLANs, so I don't run into the problem in the first place.

I believe coupling that switch rule with suitable inter-VLAN routing rules should allow mDNS based negotiations to transit VLANs. If not, I'd like to know why.

Amm0 · Sun Jan 01, 2023 12:31 am

I think @raimondsp point isn't that mDNS is insecure. Rather that folks overuse VLANs under "illusion of safety". Not quite the same thing.

[...] you bought a no-name smart light bulb on eBay and you don't want it to access your NAS and upload its content to the internet. But you want to be able to turn on/off the bulb from your PC/smartphone. Then why not put your PC/smartphone under both IoT and NAS VLANs?

My guess at MT's rational is that it's a lot of work, for what they think are "questionable" use cases.

Sun Jan 01, 2023 12:43 am

it's a lot of work, for what they think are "questionable" use cases.

There are far better use cases.

Here's one: AirPrint in a corporate environment. It's convenient in BYOD shops to let people print from their iPhones or whatever, but if you think printers that haven't received firmware updates for 10 years belong on the employee WiFi LAN, you're either insane or not paying attention to security. Isolating the two with VLANs but allowing one-way print requests is entirely sensible.

Sun Jan 01, 2023 1:00 am

Here's another: screen-sharing to conference room displays. The plan to put a bad-ass LED wall in the boardroom might give the CEO a fuzzy, but if you tell him he can't have it because there's a Chinese ODM board at the heart of it that's as full of holes as a block of Jarlsberg, he's gonna buy the video wall anyway and then yell at IT when he can't show his charts and graphs at the next board meeting because someone with a clue put the video wall on a different VLAN than the WiFi.

relokin · Sun Jan 01, 2023 4:04 pm

I understand the reason why you would want to put IoT devices under a separate VLAN. For instance, you bought a no-name smart light bulb on eBay and you don't want it to access your NAS and upload its content to the internet. But you want to be able to turn on/off the bulb from your PC/smartphone.

This is a very good example of the threat model I would like to protect against in my network setup. Most of us have an increasing number of (IoT) devices which run very obscure software stacks. A random bulb bought from eBay is a very example, but also, technically, there is nothing preventing Google to send a software update to my Chromecast and turn it into a spoofer. Having such a device completely free to roam in my network seems unnecessary and undesirable.

Then why not put your PC/smartphone under both IoT and NAS VLANs? Then PC will be able to access both IoT and NAS devices, but IoT cannot access NAS.

How would I do this? How do I setup my iPhone or Android phone to participate in more than one VLANs?

What you are trying to do, is to segregate the network on L2 (via VLAN), but then combine it together on L3 (via inter-VLAN routing). Without a firewall, there is no safety here, only an illusion of it. Yes, IoT devices on one VLAN cannot do neighbor discovery, but with inter-VLAN routing, nobody prevents them to scan the routed network (unless a properly configured firewall). For example, your PC VLAN 10 IP 192.168.10.1/24 accesses a spyware light bulb on VLAN 20 IP 192.168.20.31/24, then the bulb scans the source network (e.g.
Code: Select all
nmap -sn 192.168.10.0/24
), finds a NAS at 192.168.10.75 and does nasty things with that.

Of course, you can configure the firewall to allow traffic only from VLAN ID 10 to 20, but backward - only within the established connections (btw, it won't work in case of mDNS due to multicast), but IMHO that's overcomplicated.

It is much easier to assign PC to both VLANs with IP 192.168.10.1/24 and 192.168.20.1/24 for VLAN 10 and 20 respectively and to prevent (by simply not creating) routing between 192.168.10.0/24 and 192.168.20.0/24 networks.

Indeed, ideally we want an IoT device to be segregated from everything else and allowed only the traffic that is expected from it. For example, an IoT device (e.g., a smart bulb) which uses MQTT should only be allowed to connect to the MQTT server via the relevant port. No other traffic needs to be allowed. In this example, RouterOS has sufficient support for me to implement this. The bulb is in the IoT vlan and the MQTT server is either in the IoT vlan and the firewall/routing rules allows me to access the MQTT server, or the MQTT server has access to both VLANs. Regardless of whether such an L3 segregation (via routing and firewall rules) is overly complicated or not, it is perfectly possible with features already supported by RouterOS (/ip/firewall and /ip/route).

Unfortunately, this is not as easy with devices that implement some form of autodiscovery via protocols such as mDNS, because these protocols assume that they are in the some broadcast domain.

L2 segregation is also possible in RouterOS but at the moment the way it is implemented (IEEE 802.1Q) makes it a binary decision (either no or complete segregation). Two devices either live in different VLANs and there is not broadcast between the two (e.g., mDNS, DHCP requests), or they live in the same VLAN and all broadcast messages are seen across the entire VLAN. I think the feature we're asking for here is a tool to repeat mDNS broadcasts across VLANs.

ffries · Sun Jan 01, 2023 4:11 pm

On a Mac, there is a command "dns-sd -Z" that outputs the LAN's DNS records from mDNS broadcast, into a DNS zone file that can be use in a DNS server. I presume some similar tool exists for Win/Linux. Only issue is Mikrotik's DNS doesn't support one of the DNS type (PTR), so those records have to go into some other DNS server (perhaps Pi-Hole, but I haven't tested)

Sorry for my late reply. On Debian installed "mdns-scan" package, which returns the PTR addresses, example:

mdns-scan
...
XXXX._spotify-connect._tcp.local

avahi-resolve --name allows to map the hostname to its IP addresses.

Debian also offers "mdnsd" package:

embeddable Multicast DNS Daemon
This is a standalone mDNS-SD daemon for small systems. Although still
limited in functionality it can announce services like FTP, HTTP, and
SSH and respond to scanning (enumeration) requests from tools like
mdns-scan.

ffries · Sun Jan 01, 2023 4:23 pm

https://github.com/vfreex/mdns-reflector
is also a good candidate and has Docker files.

docker pull yuxzhu/mdns-reflector:latest

Anyhow I don't know the internal and security implications.
There is a previous post about mdns-reflector.

digitik · Sun Jan 01, 2023 10:47 pm

https://github.com/vfreex/mdns-reflector
is also a good candidate and has Docker files.

Can somebody make a simple tutorial to demonize any working docker mDNS reflector with two interfaces on ROS7?
Thanks.

Sun Jan 01, 2023 11:09 pm

a simple tutorial

Already done.

nevolex · Wed Jan 25, 2023 2:35 am

To those people asking for mDNS, can you give examples where it will be useful?
Rextended provided solutions for the given examples. Maybe there are more examples?

Chromecasting and Casing (audio/ video / printer discovery )in general between the vlans, for example cast from the phone that is on the main network to Iot network etc

craigxau · Sun Jan 29, 2023 2:42 am

This is my original post. Still no progress on mDNS Repeating.

Why do i own a ton of Mikrotik, because its complex technically capable gear and thats who I am. My house is full of segmented networks, VLANS and SSIDs. I run everything from Sat, LORA, WiFi and etherything I can bolt onto my home lab. Mikrotik is at the heart of it all.

If you run a big flat network that is your choice. no criticism here. I choose not to do that and I choose to use my tiks the way they can be used.

So why does Mikrotik, a company that makes such amazing kit continue to ignore this simple little feature request?

My house is full of Google and Apple and i want mDNS to repeat and propegate across my network segments.

Mikrotik Devs. Admins & Management - Does anyone from Mikrotik read our forums, do you have any interest in understaning your loyal communities feedback.

AGAIN - Humbly requesting an mDNS Repeater feature for these amazing product so we can use our tiks the way we want them.

whatever · Sun Feb 05, 2023 11:24 am

+1

While I currently don't need it myself, there are tons of valid use cases for a mDNS repeater. There are multiple ready-to-use open source implementations and required configuration is minimal, this really should be implemented as a feature in ROS.

DarkNate · Tue Feb 07, 2023 8:18 pm

Just deploy IGMP Proxy correctly:
https://help.mikrotik.com/docs/display/ROS/IGMP+Proxy

Upstream interface will be loopback, “downstream” interface will be the L3 subinterface VLANs that sit on top of the bridge. Enable IGMP Snooping on the bridge, disable multicast querier.

I use it, and mDNS along with other multicast routing based apps works fine inter-VLAN.

S8T8 · Wed Feb 08, 2023 4:30 pm

@DarkNate, interesting, could you share an example of your configuration? igmp-snooping will disable bridge hardware offloading on many low-end devices, multicast-querier must be disabled on the router?
Thanks

DarkNate · Wed Feb 08, 2023 5:00 pm

igmp-snooping will disable bridge hardware offloading on many low-end devices, multicast-querier must be disabled on the router?
Thanks

I still can achieve 1Gig end-to-end routing performance inter-VLAN on RB450Gx4, hAP ax2 etc. I don't see what's the problem with losing hardware offloading. As long as you use single bridge per switch chip, bridge fast-foward/fast-path will work:
https://help.mikrotik.com/docs/display/ ... plebridges

Yes multicast-querier must be disabled.

@DarkNate, interesting, could you share an example of your configuration?
Thanks

IMO, mDNS repeater is for lazy bums who refuse to learn PIM-SM and/or IGMP Proxy as evident in this group. Hardly any real network engineering efforts are made.

I appreciate that MikroTik doesn't bend down to lazy-bums' demand for years. One of the few good vendors in that regard.

In my configuration example, I have one router and an L2 switch connected to it for Wi-Fi, keep that in mind:

#Router side#
/interface bridge
add frame-types=admit-only-vlan-tagged igmp-snooping=yes igmp-version=3 mld-version=2 name=bridge priority=0x1000 vlan-filtering=yes
add arp=disabled name=loopback protocol-mode=none

/interface vlan
add interface=bridge mtu=9214 name="VLAN40" vlan-id=40
add interface=bridge mtu=9214 name="VLAN30" vlan-id=30

/interface bridge port
#This is the trunk port connected to the L2 switch#
add bridge=bridge edge=no frame-types=admit-only-vlan-tagged interface=ether1 point-to-point=yes
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether6 pvid=40
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether7 pvid=40
add bridge=bridge edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether8 point-to-point=yes pvid=30

/interface bridge vlan
add bridge=bridge comment="VLAN40 + MGMT VLAN" tagged=bridge,ether1 vlan-ids=30,40

/ip address
add address=100.64.0.1/24 comment="VLAN40" interface="VLAN40" network=100.64.0.0
add address=30.0.0.0 comment="Loopback" interface=loopback network=10.0.0.0
add address=100.64.2.1/25 comment="VLAN30" interface="VLAN30" network=100.64.2.0

/routing igmp-proxy interface
add interface=loopback upstream=yes
add interface="VLAN40"
add interface="VLAN30"

#On L2 switch side#
/interface bridge
add frame-types=admit-only-vlan-tagged igmp-snooping=yes igmp-version=3 mld-version=2 name=bridge priority=0x2000 vlan-filtering=yes

/interface bridge port
#Ether1 is trunk port connected to router#
add bridge=bridge comment=defconf edge=no frame-types=admit-only-vlan-tagged interface=ether1 point-to-point=yes trusted=yes
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether4 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=5GHz_1 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=2GHz_1 pvid=40
add bridge=bridge comment=defconf edge=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether5 pvid=30

/interface bridge vlan
add bridge=bridge tagged=ether1,bridge vlan-ids=30
add bridge=bridge tagged=ether1,bridge vlan-ids=40

If you have IPv6, which you should, be sure to configure a /128 GUA on the loopback interface or some ULA addressing. Without IP addressing on the loopback interface for both v4 and v6, IGMP Proxying will fail.

Buckeye · Wed Feb 08, 2023 8:11 pm

IMO, mDNS repeater is for lazy bums who refuse to learn PIM-SM and/or IGMP Proxy as evident in this group. Hardly any real network engineering efforts are made.

I appreciate that MikroTik doesn't bend down to lazy-bums' demand for years. One of the few good vendors in that regard.

That's one way to look at it. But why is MikroTik selling hAP ax lite into the home market? Most home users are not network engineers.

Your argument sounds similar to:
IMO, the nano editor is for lazy bums who refuse to learn vi. ...

DarkNate · Wed Feb 08, 2023 8:59 pm

That's one way to look at it. But why is MikroTik selling hAP ax lite into the home market? Most home users are not network engineers.

Your argument sounds similar to:
IMO, the nano editor is for lazy bums who refuse to learn vi. ...

MikroTik sells hardware running a single version of RouterOS, the same thing found in ISPs, Telcos and Data Centres. Which vendor other than MikroTik sells an AP like ax lite supporting MPLS over IPv6 out of the box? None.

Their target “home users” are power users. Not your grandma or grandpa who can't tell IPv4 from IPv6.

If your “home users” can't configure IGMP Proxy (like my example config or even the official docs), they should stick to TP-Link with OpenWRT.

Amm0 · Wed Feb 08, 2023 10:23 pm

Well I'm not sure using OpenWRT is needed either. If you use just one LAN at a home, that solves the problem too.

And if you're are using VLANs, don't put stuff that needs multicast (e.g. mDNS [AirPrint, etc.]) on different subnets, also solve this. Since there are containers that support mDNS, that's an easy out here for Mikrotik when someone wants to do something non-standard. Or want to get more creative? DarkNate's complex world of multicast routing awaits – for those that just got the hang of VLANs...

But even after 50K views, no one has described how it work in practice, beyond "others vendors do it" or "add X package"... e.g. how would Mikrotik even define the needed mDNS "overlay network" in the RouterOS config? I don't think this is a trivial or easy thing to do.

While not a fan of @DarkNate's tone, have to agree I'm glad Mikrotik has NOT "caved in" to mob here. The standards/RFCs advise against repeating mDNS. And unicast DNS-SD is the RFC approved method for "mDNS" accross subnets/segments.

DarkNate · Wed Feb 08, 2023 11:42 pm

Well I'm not sure using OpenWRT is needed either. If you use just one LAN at a home, that solves the problem too.

And if you're are using VLANs, don't put stuff that needs multicast (e.g. mDNS [AirPrint, etc.]) on different subnets, also solve this. Since there are containers that support mDNS, that's an easy out here for Mikrotik when someone wants to do something non-standard. Or want to get more creative? DarkNate's complex world of multicast routing awaits – for those that just got the hang of VLANs...

But even after 50K views, no one has described how it work in practice, beyond "others vendors do it" or "add X package"... e.g. how would Mikrotik even define the needed mDNS "overlay network" in the RouterOS config? I don't think this is a trivial or easy thing to do.

While not a fan of @DarkNate's tone, have to agree I'm glad Mikrotik has NOT "caved in" to mob here. The standards/RFCs advise against repeating mDNS. And unicast DNS-SD is the RFC approved method for "mDNS" accross subnets/segments.

Use IGMP Proxy in simple VLAN segregated home networks and call it a day. iPhone in VLAN1 can talk to iPhone in VLAN2 for AirFuckKnowsWhat, no problem.

Unicast DNS-SD defeats the whole purpose of multicast aka saving computing resources on L2 and L3.

Amm0 · Thu Feb 09, 2023 12:21 am

"Sorry bro" but unicast is way more efficient than multicast. Not saying don't use IGMP or a container to solve mDNS via milticast... but I can totally see why Mikrotik doesn't add this. e.g.

If mDNS proxy is implemented, the RFC is broken because on RFC mDNS must not be forwarded outside local LAN...

DarkNate · Thu Feb 09, 2023 1:38 am

"Sorry bro" but unicast is way more efficient than multicast. Not saying don't use IGMP or a container to solve mDNS via milticast... but I can totally see why Mikrotik doesn't add this. e.g.
If mDNS proxy is implemented, the RFC is broken because on RFC mDNS must not be forwarded outside local LAN...

What are you talking about? Multicast is superior for saving resources:
https://networkengineering.stackexchange.com/a/19587
https://www.researchgate.net/publicatio ... ing_Method
https://research.ijcaonline.org/volume6 ... 885611.pdf
https://citeseerx.ist.psu.edu/document? ... 48a684cc44
https://cims.nyu.edu/~eyal/papers/ngc.pdf

Why do you need mDNS proxy when IGMP Proxy for inter-VLAN multicast routing works fine, to begin with?

Amm0 · Thu Feb 09, 2023 2:08 am

Why do you need mDNS proxy when IGMP Proxy for inter-VLAN multicast routing works fine, to begin with?

I'll give that at some small scale multicast may be more efficient – but you can't IGMP proxy a large enterprise/campus/etc network – exactly where it breaks down is harder to predict. And compared to TTL-based caching of unicast DNS-SD results, I'm not sure even at smaller scales... But certainly multicast isn't friendly to Wi-Fi with duplicative mDNS data taking up airtime...

But I think we're in agreement: Mikrotik shouldn't blindly ignore the RFCs WRT to how mDNS/DNS-SD works by promoting it to a mDNS redirection/reflection/etc into a built-in feature. If you want to expand the scope of all multicast (e.g. not just mDNS), then certainly PIM and IGMP proxy are valid ways to go. As would a container.

DarkNate · Thu Feb 09, 2023 12:30 pm

I'll give that at some small scale multicast may be more efficient – but you can't IGMP proxy a large enterprise/campus/etc network – exactly where it breaks down is harder to predict. And compared to TTL-based caching of unicast DNS-SD results, I'm not sure even at smaller scales... But certainly multicast isn't friendly to Wi-Fi with duplicative mDNS data taking up airtime...

But I think we're in agreement: Mikrotik shouldn't blindly ignore the RFCs WRT to how mDNS/DNS-SD works by promoting it to a mDNS redirection/reflection/etc into a built-in feature. If you want to expand the scope of all multicast (e.g. not just mDNS), then certainly PIM and IGMP proxy are valid ways to go. As would a container.

It seems you aren't aware that multicast is used in large scale from stock trading which is nanosecond sensitive to TV networks where multicast serves hundreds of millions of users per second, that unicast simply cannot do without choking a 10G or even 100G link.

I suggest you read this thread, where real network engineers who deploy multicast for a living discuss further:
https://twitter.com/danieldibswe/status ... 2540353540

And oh, duplicate multicast packets are eliminated or reduced when IGMP Snooping + IGMP Proxy or PIM is correctly deployed in a network, you can go even further with EVPN like DE-CIX did.

bmann · Thu Feb 09, 2023 10:42 pm

@DarkNate
You are little bit arrogant, aren't you?
That you are expert in multicast routing does not mean that everyone else must be too. Good for you, but call anyone else lazy-bum?

Not everyone needs to know multicast routing even if they work in IT.
Mikrotik sells wireless APs on consumer market and with "wizard" for simple setup. Do you think that user who buys mikrotik and uses wizard should be able to setup multicast routing and IGMP proxy?

Mikrotik sells to consumers too and configuration should be simple.

And another point. I got briefly over "Multicast DNS" RFC6762 and on several places it counts with "Multicast DNS Proxy Servers" for example as with duplicate answer suppression.
So I do not see anything wrong or proxy/repeater.

Other vendors, even big names have such feature.

So if Mikrotik still plans to sell on consumer market they should consider this functionality. No consumer will do IGMP proxy, multicast etc.

DarkNate · Thu Feb 09, 2023 11:39 pm

@DarkNate
You are little bit arrogant, aren't you?
That you are expert in multicast routing does not mean that everyone else must be too. Good for you, but call anyone else lazy-bum?

Not everyone needs to know multicast routing even if they work in IT.
Mikrotik sells wireless APs on consumer market and with "wizard" for simple setup. Do you think that user who buys mikrotik and uses wizard should be able to setup multicast routing and IGMP proxy?

Mikrotik sells to consumers too and configuration should be simple.

And another point. I got briefly over "Multicast DNS" RFC6762 and on several places it counts with "Multicast DNS Proxy Servers" for example as with duplicate answer suppression.
So I do not see anything wrong or proxy/repeater.

Other vendors, even big names have such feature.

So if Mikrotik still plans to sell on consumer market they should consider this functionality. No consumer will do IGMP proxy, multicast etc.

I am not a multicast routing expert. But I work with those who are. None of them are in this thread.

S8T8 · Thu Feb 16, 2023 10:24 pm

@DarkNate, appreciated your help, followed suggestions on the previous post but not working, could be my fault.
Tried setting the bridge as upstream and then the VLAN2, printer was not visible on both cases, connected to VLAN1 and worked immediately.

I'm OK with IGMP Proxy, the MT complicated way instead of the more consumer repeater, I worked for a short time on huge CISCO campus network (but I'm not experienced as you), never had any problem printing or sharing contents on Apple devices between VLANs with the "repeater" function.

In my case I'm a low-end user, I can print with my computer using the static IP of the isolated device, using an iPhone is not possible to set the IP. How can you eventually build a network for a client with this missing feature?

DarkNate · Sat Feb 18, 2023 4:33 pm

@DarkNate, appreciated your help, followed suggestions on the previous post but not working, could be my fault.
Tried setting the bridge as upstream and then the VLAN2, printer was not visible on both cases, connected to VLAN1 and worked immediately.

I'm OK with IGMP Proxy, the MT complicated way instead of the more consumer repeater, I worked for a short time on huge CISCO campus network (but I'm not experienced as you), never had any problem printing or sharing contents on Apple devices between VLANs with the "repeater" function.

In my case I'm a low-end user, I can print with my computer using the static IP of the isolated device, using an iPhone is not possible to set the IP. How can you eventually build a network for a client with this missing feature?

Why is the bridge upstream? Who told you to do that? I said the loopback needs to be upstream and then the L3 VLANs are separate downstream.

Read it properly:
viewtopic.php?t=174354#p982771

viewtopic.php?t=174354#p982910

UpRunTech · Sat Feb 18, 2023 8:59 pm

I have mDNS repeating running over a Wireguard link. I had started the process of building this https://github.com/TheMickeyMike/docker ... r-mikrotik but then as the container system only allows one interface and the trick with this container is to feed in VLANs over it so things started to look messy or not possible this way with EoIP. I thought there might be another simpler method with bridge filters.

Wireguard is joining the subnets on L3 and each subnet is routed to the other with no filter rules.
EoIP is joining the bridges at each end using the same Wireguard link - no IPSEC used. The following filters are applied at each end as well to only let mDNS and SSDP (for UPnP) frames through on EoIP.

/interface bridge filter
add action=accept chain=forward 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 out-interface=EoIP src-port=5353 comment=mDNS
add action=accept chain=forward comment=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 log-prefix=SSDP mac-protocol=ip out-interface=EoIP  
add action=drop chain=output out-interface=EoIP
add action=drop chain=forward out-interface=EoIP

My iPad and CUPs on my PC can both discover and print to the printer at the other side. The LG Smart TV at the other house with the Photos and Videos App can discover (using SSDP) and play from my MythTV server.

Nothing seemed to work quite right until I reduced the MTU of the Wireguard interface to 1412 bytes as one end is using PPPoE. Also, the neighbour discovery service (dest. MAC FF:FF:FF:FF:FF:FF UDP:5678) seems to be out of the capture reach of the bridge filter so those frames get through. Mitigation would be to make sure that interface in question isn't included in the discovery process.

This method should work fine with VLANs or any other sets of bridge interfaces Mikrotik supports. No mDNS repeater software in containers, rPi's or IGMP snoopers needed; certainly not for small cases like this. I have tested using iPads at each site to discover and print to printers on the other site. So it works.

Here is a quick config I just knocked up on a hAPAC Lite to illustrate mDNS relaying between VLANs using bridge filtering and no IGMP snooping. IPv4 only.
* To be clear this mDNS relay config only relays mDNS traffic. It does not proxy any other data or do any IGMP or other multcast tasks.
* VLAN filtering is enabled using BridgeMain. Tagged VLANs 100 and 200 go to it for the VLANs interface to access.
* eth2 has PVID100, eth3 has PVID200.
* BridgeVLANs is the bridge that will straddle the 2 VLANs. It has the VLAN100 and VLAN200 ports attached as members. If left unfiltered all layer 2 broadcast traffic on both VLANs will pass between them.
* The bridge filter setup operates on each VLAN port only allowing mDNS to pass each way and blocking all other layer 2 traffic.
* Any actual data traffic that clients or servers use on either VLAN using addresses learned in the mDNS packets will pass via the routes on layer 3. You'll need add firewall rules to limit the traffic interaction but is out of the scope of this example.
* I would imagine this would work just fine on a CRS3xx switch as well but you might as well use the rolled gold standard of IGMP snooping.

/interface bridge
add comment="Main Bridge VLAN filtering runs on" frame-types=admit-only-vlan-tagged name=BridgeMain protocol-mode=none pvid=999 vlan-filtering=yes
add comment="Bridge for linking VLANs with filtering" name=BridgeVLANs protocol-mode=none
/interface ethernet
set [ find default-name=ether2 ] comment="Eth PVID100"
set [ find default-name=ether3 ] comment="Eth PVID200"
/interface vlan
add comment="VLAN100 on main bridge" interface=BridgeMain name=VLAN100 vlan-id=100
add comment="VLAN200 on main bridge" interface=BridgeMain name=VLAN200 vlan-id=200
/interface bridge filter
add action=accept chain=forward comment="Allow VLAN100 mDNS traffic out" 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 out-interface=VLAN100 ip-protocol=udp mac-protocol=ip src-port=5353
add action=accept chain=forward comment="Allow VLAN200 mDNS traffic out" 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 out-interface=VLAN200 ip-protocol=udp mac-protocol=ip src-port=5353
add action=drop chain=forward comment="VLAN100 drop all other forwarding" out-interface=VLAN100
add action=drop chain=output comment="VLAN100 drop all output" out-interface=VLAN100
add action=drop chain=forward comment="VLAN200 drop all other forwarding" out-interface=VLAN200
add action=drop chain=output comment="VLAN200 drop all output" out-interface=VLAN200
/interface bridge port
add bridge=BridgeVLANs comment="VLAN100 Port" interface=VLAN100
add bridge=BridgeVLANs comment="VLAN200 port" interface=VLAN200
add bridge=BridgeMain comment="Eth PVID100" frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=100
add bridge=BridgeMain comment="Eth PVID200" frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=200
/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-vlan=yes
/interface bridge vlan
add bridge=BridgeMain comment="VLAN100 port definitions" tagged=BridgeMain vlan-ids=100
add bridge=BridgeMain comment="VLAN200 port definitions" tagged=BridgeMain vlan-ids=200
/ip address
add address=172.16.200.254/24 comment="VLAN200 interface address" interface=VLAN200 network=172.16.200.0
add address=172.16.100.254/24 comment="VLAN100 interface address" interface=VLAN100 network=172.16.100.0

anav · Wed Mar 22, 2023 11:02 pm

I attempted to run mDSN discovery over wireguard but at two DIFFERENT LOCATIONs..........
Feel free to test it, to make sure it works..............academic at this point.
viewtopic.php?p=990840#p990840

Kaldek · Thu Mar 23, 2023 5:23 am

Just deploy IGMP Proxy correctly:
https://help.mikrotik.com/docs/display/ROS/IGMP+Proxy

Darknate is correct but let me add context.

mDNS as a standard is not meant to be reflected or repeated. Avahi is an implementation of the zeroconf standard that added mDNS reflection as a practical solution for those of us who have chosen to segment our networks due to concerns about the number of IoT devices from various vendors on our networks.

That being, neither IGMP Proxy nor mDNS reflection with Avahi is "correct". They're both "as bad as each other" in regards to the mDNS RFC. Pick one, make it work, and knock yourself out.

Mikrotik *could* add an mDNS reflector into ROS, just like they have added UPnP. However, it's not a network standard and that - to me - is why they have never done it. Currently I run an avahi daemon on a Raspberry Pi as I have segmented my network. I'll take a look at using an IGMP proxy but I'm more likely to use the mDNS reflector container on my RB5009.

DarkNate · Thu Mar 23, 2023 7:23 am

That being, neither IGMP Proxy nor mDNS reflection with Avahi is "correct". They're both "as bad as each other" in regards to the mDNS RFC. Pick one, make it work, and knock yourself out.

IGMP Proxy is closest to an internet standard than mDNS reflector/Avahi bullshit is. IGMP Proxy also handles stuff unrelated to mDNS, therefore allow ALL multicast traffic to work correctly across VLANs.

https://www.rfc-editor.org/rfc/rfc4605

IGMP Proxy is so “standardized” that even Cisco supports it:
https://www.cisco.com/c/en/us/td/docs/s ... _proxy.pdf

bmann · Fri Mar 24, 2023 8:00 pm

@Kaldek
> "mDNS as a standard is not meant to be reflected or repeated. ..."
If you check RFC for mDNS, you will see it counts with reflection, gateways even if it itself does not define proxying.

> "Mikrotik *could* add an mDNS reflector into ROS, just like they have added UPnP. However, it's not a network standard and that - to me - is why they have never done it. "
Just guessing, we do not have any word from Mikrotik.

@DarkNate
The more you fight against mDNS reflector/proxy the more it is ridiculous.
Maybe time to accept that this is valid feature request and many other vendors offer such feature, even Cisco. For example:
https://www.cisco.com/c/dam/en/us/td/do ... l-17-3.pdf

The IGMP proxy in theory could be more generic solution. But it is proxy and in fact will do the same as mDNS proxy if it works.
So takes mDNS packet from one subnet and puts it to another.
And if I got it right, then for IGMP proxy to work the devices has to use IGMP protocol and join to mDNS group so proxy can forward the mDNS packets.
But majority of IoT devices does not do that, just send mDNS packets.

For regular users/SMB the mDNS reflector/proxy (or call it as you want) should be part of ROS. No docker, no RPi etc. This is not for regular users and not easy to set up.
If I will recommend someone to buy Mikrotik and tell him that for mDNS he needs RPi to get it work and maintain, then there is no go.

Anyway other vendors do this (even Cisco) so it is just Mikrotik's decision.

DarkNate · Fri Mar 24, 2023 8:40 pm

You've clearly never tested and configured IGMP Proxy correctly. If you did, you'd know it's only two-three lines of config to get it working:
viewtopic.php?t=174354#p982910

Like I said, it will handle all multicast/IGMP traffic.

Amm0 · Fri Mar 24, 2023 9:20 pm

The more you fight against mDNS reflector/proxy the more it is ridiculous.
This is not for regular users and not easy to set up.

Not the only one disagree with this being promoted to a feature. "Regular users" don't have multiple LAN subnets, so how does this even come up in that case...

If you check RFC for mDNS, you will see it counts with reflection, gateways even if it itself does not define proxying.

Wrong. 239.0.0.0/8 are defined to be per interface in RFC2365, so there no need to look at mDNS RFCs.

And any reading of the mDNS/DNS-SD RFC series concludes with converting mDNS (multicast) into DNS-SD (unicast) at interface/subnet boundaries is the "proper" approach. How? In the standards, vendors offered a variety of approaches to do that like discovery proxy, dnsextd, etc.. But ignoring RFC2365 isn't one.

Anyway other vendors do this (even Cisco) so it is just Mikrotik's decision.

Why Mikrotik doesn't.... they've said the use cases don't make sense in the above. They never said anything about the rigorous standard compliance as the reasoning. I'd like to think so, perhaps @DarkNate too, but that's not what they said.

If you've gone done the road of subnetting your LAN, IGMP Proxy should not be a huge leap. And if it was, maybe you should re-think segmenting your network in the first place?

DarkNate · Fri Mar 24, 2023 9:25 pm

If you've gone done the road of subnetting your LAN, IGMP Proxy should not be a huge leap. And if it was, maybe you should re-think segmenting your network in the first place?

VLANs + mDNS containers hacks takes like 10 minutes total for a noob.

IGMP Proxy, takes 5 seconds to configure for all VLANs.

Not sure why these experts keep demanding MikroTik for mDNS repeater crap.

@MikroTik should continue as they are and never succumb to idiotic requests.

For the record, IoT devices work perfectly fine with IGMP Proxy in home use cases.

In production, we use PIM not IGMP Proxy or mDNS bs.

S8T8 · Sat Mar 25, 2023 2:38 am

...it's only two-three lines of config to get it working:
viewtopic.php?t=174354#p982910

Let's see if this second attempt will be the good one

/interface bridge add frame-types=admit-only-vlan-tagged igmp-snooping=yes igmp-version=3 mld-version=2 name=Bridge protocol-mode=mstp vlan-filtering=yes

/ip address add address=192.168.10.1/24 interface=LAN network=192.168.10.0
/ip address add address=192.168.20.1/26 interface=IoT network=192.168.20.0
/ip address add address=192.168.30.1/28 interface=NAS network=192.168.30.0

/routing igmp-proxy interface add alternative-subnets=192.168.20.1/26,192.168.30.1/28 interface=LAN upstream=yes
/routing igmp-proxy interface add interface=IoT
/routing igmp-proxy interface add interface=NAS

DarkNate · Sat Mar 25, 2023 7:01 am

Let's see if this second attempt will be the good one

/interface bridge add frame-types=admit-only-vlan-tagged igmp-snooping=yes igmp-version=3 mld-version=2 name=Bridge protocol-mode=mstp vlan-filtering=yes

/ip address add address=192.168.10.1/24 interface=LAN network=192.168.10.0
/ip address add address=192.168.20.1/26 interface=IoT network=192.168.20.0
/ip address add address=192.168.30.1/28 interface=NAS network=192.168.30.0

/routing igmp-proxy interface add alternative-subnets=192.168.20.1/26,192.168.30.1/28 interface=LAN upstream=yes
/routing igmp-proxy interface add interface=IoT
/routing igmp-proxy interface add interface=NAS

Why do you keep insisting on doing the complete opposite of my config example here?
viewtopic.php?t=174354#p982910

Why do you keep avoiding a loopback interface? Even though I provided the full configuration, you still actively decide to do it the wrong way, before and even now.
viewtopic.php?t=174354#p985159

What is the reason for your fear of loopback interface to correctly set the upstream interface?

bmann · Sat Mar 25, 2023 1:00 pm

Wrong. 239.0.0.0/8 are defined to be per interface in RFC2365, so there no need to look at mDNS RFCs.

Wrong argument. The same you could say about IGMP proxy - so no need to look for IGMP RFCs.

There are many other vendors (with Cisco too) providing such feature at some level. It maybe called differently, but do the same.
So at the end it is Mikrotik's pure business decision if they implement the same what other vendors already have.

Maybe time to stop denying reality and pretend it is something awful and accept this legitimate feature request already provided by other vendors.

Sat Mar 25, 2023 1:14 pm

Wrong. 239.0.0.0/8 are defined to be per interface in RFC2365, so there no need to look at mDNS RFCs.
Wrong argument. The same you could say about IGMP proxy - so no need to look for IGMP RFCs.

Yes. All that RFC means is that the packets in that IP range don't automatically flow from one network to another. When helped across via PIM or a proxy, that's a local administration matter, not subject to RFC restriction. There are no Internet cops gonna come running because you did this.

CTSsean · Sun Mar 26, 2023 4:44 am

Use IGMP Proxy in simple VLAN segregated home networks and call it a day. iPhone in VLAN1 can talk to iPhone in VLAN2 for AirFuckKnowsWhat, no problem.

Unicast DNS-SD defeats the whole purpose of multicast aka saving computing resources on L2 and L3.

Doesn't work. Used your specific example, including adding ipv6 GUA on the loopback, still no packets traverse the IGMP Proxy

CTSsean · Sun Mar 26, 2023 4:56 am

If you've gone done the road of subnetting your LAN, IGMP Proxy should not be a huge leap. And if it was, maybe you should re-think segmenting your network in the first place?
VLANs + mDNS containers hacks takes like 10 minutes total for a noob.

IGMP Proxy, takes 5 seconds to configure for all VLANs.

Not sure why these experts keep demanding MikroTik for mDNS repeater crap.

@MikroTik should continue as they are and never succumb to idiotic requests.

For the record, IoT devices work perfectly fine with IGMP Proxy in home use cases.

In production, we use PIM not IGMP Proxy or mDNS bs.

without "idiotic" requests, you wouldn't have an easy to use interface like winbox.
without "idiotic" requests, you wouldn't have the ability to schedule things.
without "idiotic" requests, you wouldn't have the ability to use Zerotier with Tik.
without "idiotic" requests, you wouldn't have the ability to use containers on v7.
without "idiotic" requests, you wouldn't have the ability to use ROMON.

You don't need to be toxic to be helpful.

I've tested your solution for IGMP Proxy, and that doesn't work for mdns. No packets traverse the proxy. If I set the loopback as the upstream... 0 packets recieved / transmitted on either of the 3 interfaces.
If I set the vlan10 as the upstream, RX packets are seen on that interface, but not anywhere else.

DarkNate · Sun Mar 26, 2023 11:41 am

I've tested your solution for IGMP Proxy, and that doesn't work for mdns. No packets traverse the proxy. If I set the loopback as the upstream... 0 packets recieved / transmitted on either of the 3 interfaces.
If I set the vlan10 as the upstream, RX packets are seen on that interface, but not anywhere else.

You didn't correctly configure it, and you are even hiding the config from the public in this forum just to make my solution look bad. And you need to be extra stupid to set a VLAN interface as upstream, unless a single multicast server like IPTV is running behind VLAN10.

Where is your config export?

0 packets received/transmitted is a bug in RouterOS, you being the expert that you are can confirm with official MikroTik support staff, they'll tell you to ignore packet count in IGMP Proxy. The proper way to verify IGMP Snooping + IGMP Proxy is working correctly is by printing the MDB table:

interface bridge mdb print

DarkNate · Sun Mar 26, 2023 11:43 am

Doesn't work. Used your specific example, including adding ipv6 GUA on the loopback, still no packets traverse the IGMP Proxy

As already explained, since you're expert I suggest you talk to official MikroTik support, packet count will be zero in IGMP Proxy when it is working correctly. Why? Ask them, you're the expert in this conversation clearly.

broderick · Sun Mar 26, 2023 12:13 pm

IGMP Proxy, takes 5 seconds to configure for all VLANs.

For the record, IoT devices work perfectly fine with IGMP Proxy in home use cases.

I'm interested into how this IGMP proxy works because it might fix my issue hopefully.
I have a server which runs on a subnet (192.168.3.0/24) and other devices on another one (10.10.10.0/24). No VLANs, just two subnets set up on two bridges.
I installed jellyfin on the server, and it happens now that a client (my smart TV) is on the subnet 10.10.10.0/24 and it should get access to the jellyfin app running on the server and its contents via DLNA I guess. I had already set a few firewall rules on my MK device to allow a couple of devices on 10.10.10.0/24 to acces my server, like my tv, and my laptop when I'm on the other subnet. They works. However, I didn't manage to make my tv see jellyfin contents on the server, I thought that IGMP or mDNS might have something to do with it.
I'm not a computer networking expert so I am aware that I might have said something stupid.
Could you help me figure it out?
Thanks

optio · Sun Mar 26, 2023 3:57 pm

All proposed solutions are for L2, but what if you have VPN connection between router and user device (smartphone, laptop...)?
mDNS repeater in container is also not an option since system in container can only get veth and tagged interfaces on its bridge, but l3 tunnel interfaces (wireguard, ovpn) cannot be bridged and tagged.
Only what I can see that can solve this is with mDNS repeater/reflector as ROS additional package which can be configured to select ROS interfaces to reflect mDNS between them. Something like: https://docs.paloaltonetworks.com/pan-o ... gmentation

Since Mikrotik is selling products for home users, it should be fair to cover needs for such consumers, even if some advanced skills are needed for configuration, but at least to be possible.

anav · Sun Mar 26, 2023 3:58 pm

For posters here........... Do not mind Darknate's lack of personal communication skills (probably why he has more dates with large networks than real people

) and of course the rampant narcissism.
He has a lot of experience with many large networks that is invaluable to other large network users!
How that translates to smaller home or SOHO setups is not always clear or necessarily possible.
Very pragmatic 'to the point' advice, (and expect some pushback if you keep ignoring the advice provided or keep applying it wrong after repeated attempts/time to help)

CTSsean · Sun Mar 26, 2023 4:28 pm

For posters here........... Do not mind Darknate's lack of personal communication skills (probably why he has more dates with large networks than real people ) and of course the rampant narcissism.
He has a lot of experience with many large networks that is invaluable to other large network users!
How that translates to smaller home or SOHO setups is not always clear or necessarily possible.
Very pragmatic 'to the point' advice, (and expect some pushback if you keep ignoring the advice provided or keep applying it wrong after repeated attempts/time to help)

The guy is the toxic avenger. He may have some experience, but how he has been allowed to touch big networks with such a bad attitude is just horrible. These forums (and other places) are meant to help people with Mikrotik, not belittle others. I never claimed to be an expert, yet he starts with nasty attitude with everyone. Calling everyone lazy for wanting a convenience feature is such a bad attitude.

He then goes on to say 'contact support'. There is virtually no support for anyone that doesn't have a contact at Mikrotik. Forums and other venues like reddit and my discord are one of the very few places people can get help on MIkrotik topics.

spippan · Sun Mar 26, 2023 4:37 pm

even the edgerouter has a mdns repeater..
Ever home user needs mDNS. Don't know why mikrotik keeps ignoring this.

why would someone need to have that? worse, why even relay such network noise?

Amm0 · Sun Mar 26, 2023 4:44 pm

why would someone need to have that? worse, why even relay such network noise?

That's the existential question here. But

[...] at the end it is Mikrotik's pure business decision [...]

And... it sounds like this could be resolved by better docs on IGMP Proxy for those that want to go this route. An example there would go a long way.

But specific the troubles in making IGMP working may involve the firewall. Both the multicast discovery and the resulting unicast traffic once a device was discovered need to be allowed. If you block inter-VLAN forwarding, the IGMP proxy follows those rules too.