Advantages of mDNS-Bridge vs UDPBroadcastRelay

[keyser]

Hi all - and @dennypage i particular ;-)

I’m experimenting with heavy segmentation and a high level of filtering/firewalling between VLAN’s for all kinds of separate IoT devices. Right now Apple Bonjour based services (airplay/print/homekit) and Chromecast is my focus.

I have a good setup running now using a single mDNS instance setup in UDPBroadcastRelay (224.0.0.251:5353) and things are working peachy.
But: UDPBroadcastRelay is rather limited in filtering, and especially in traffic directions, so I was wondering if the new mDNS-Bridge package is better suited?

I’m mostly interested in controlling direction of mDNS bridging - Example (all names are pf interfaces): From CLIENTS to IOT, not the other way around. But also more multi interface granularity - fx: From SERVERS and CLIENTS to IOT and HOME, and from HOME to IOT but not the other ways around.

Can this be done i mDNS-Bridge, and can I also filter the mDNS services allowed in the proces (known mDNS service names)?

[dennypage]

@keyser Yes. It provides for detailed filtering, both inbound and outbound, per interface. Detailed documentation is here, but if you simply install the pfSense package, it should all be clear from the UI. The only obscure concept may be how to do a complete one-way, which you can find discussed in this thread.

While I haven't looked at the code for UDPBroadcastRelay, I assume that it simply retransmits the packet as received. This is not a good choice for mDNS because of the presence of link local addresses which need to be removed. This is very common with IPv6, but can also occur with IPv4.

[keyser]

@dennypage Okay cool, that does sound like it is a much better fit. UDPBroadcastRelay does not support IPv6 either, so that also makes mDND-Bridge the better option.

I’ll find some time and give it a spin. Thanks for the clarification

[tman222]

Thanks @keyser for this post, as a long time user of UDP Broadcast Relay, I was wondering about the differences myself. One thing I did like about UDP Broadcast Relay is that you could relay more than just mDNS multicast traffic:

https://docs.netgate.com/pfsense/en/latest/packages/udpbroadcastrelay.html#examples

However, upon reviewing the settings today I saw that I'm only using UDP Broadcast Relay for mDNS, so I decided disable it and give mDNS Bridge a try. So far everything appears to be working as before and I like the more granular filtering abilities (i.e. allow/deny by interface).

@dennypage - got a couple questions for you:

1. Looking at the advice you gave in the other thread regarding one-way communication, would another way to set this up (assuming one Untrusted and one Trusted interface) to allow inbound on the Trusted interface and set the type to _nothing_ vs. allowing outbound on the Untrusted interface and setting the type to _nothing_?
2. When I tried to configure the mDNS Bridge package settings in the GUI without selecting an interface first, the package crashed vs. catching the error and warning the user to select an interface. This happens even if adjusting just the package's global settings. Just wanted to let you know in case you were not aware of this issue yet.
3. I see the latest version on GitHub page is 2.2.0 - is this the version included in the package? If not, does it make sense to upgrade now, or wait for the next version of the package to be released?

Thanks again for all your hard work and effort on this, it is greatly appreciated!

[dennypage]

@tman222 said in Advantages of mDNS-Bridge vs UDPBroadcastRelay:

as a long time user of UDP Broadcast Relay, I was wondering about the differences myself. One thing I did like about UDP Broadcast Relay is that you could relay more than just mDNS multicast traffic:

https://docs.netgate.com/pfsense/en/latest/packages/udpbroadcastrelay.html#examples

As noted above, using a simple packet relay for mDNS is bad because it ends up forwarding link-local unicast addresses that are invalid outside the network segment in which they were created.

FWIW, my current project is a generic multicast bridge, which forwards based on IGMP and MLD interest determination. Essentially a smart replacement for the use of a UDP broadcast relay in the multicast space, or pimd if sources and syncs are on locally attached network segments. Notably, the list of potential uses for mcast-bridge will not include mDNS, because mcast-bridge does not allow link-local multicast addresses (224.0.0.0/8 & FF02::/16) to be configured.

1. Looking at the advice you gave in the other thread regarding one-way communication, would another way to set this up (assuming one Untrusted and one Trusted interface) to allow inbound on the Trusted interface and set the type to _nothing_ vs. allowing outbound on the Untrusted interface and setting the type to _nothing_?

If you limit the configuration to exactly two interfaces, yes. However, if you have more than two, or you want to use the global filter, using an outbound filter list of _nothing_ is more flexible.

2. When I tried to configure the mDNS Bridge package settings in the GUI without selecting an interface first, the package crashed vs. catching the error and warning the user to select an interface. This happens even if adjusting just the package's global settings. Just wanted to let you know in case you were not aware of this issue yet.

I believe that this is already fixed in the current version of the package.

3. I see the latest version on GitHub page is 2.2.0 - is this the version included in the package? If not, does it make sense to upgrade now, or wait for the next version of the package to be released?

pfSense 25.07 is version 1.0.1. pfSense 25.11 is 2.2.0. The Redmine is here.

Thanks again for all your hard work and effort on this, it is greatly appreciated!

Welcome.

[keyser]

@dennypage said in Advantages of mDNS-Bridge vs UDPBroadcastRelay:

@keyser Yes. It provides for detailed filtering, both inbound and outbound, per interface. Detailed documentation is here, but if you simply install the pfSense package, it should all be clear from the UI. The only obscure concept may be how to do a complete one-way, which you can find discussed in this thread.

While I haven't looked at the code for UDPBroadcastRelay, I assume that it simply retransmits the packet as received. This is not a good choice for mDNS because of the presence of link local addresses which need to be removed. This is very common with IPv6, but can also occur with IPv4.

Just a small update on this: The mDNS-Bridge package is definitively a more nuanced mDNS relay service than the IPv4 only bruteforce relay done in UDPBroadcastRelay.
Allegedly it uses less ressources, and it definitively does allow for better and more nuanced filtering on a pr. Interface basis. It also works on both IPv4 and IPv6. So if mDNS only is your requirements, this is the package to use compared to Avahi and UDPbroadcastRelay.

However: There is a limitation that comes into play once you have more than 2 interfaces in the mDNS relay mix.
In that case full control of filtering is not possible unless you start doing some pretty corny floating rule outbound firewall filtering as well.

Example:
I cannot “listen” for _homekit on INT1 and only forward that on INT3 while also listening on INT3 but only forward that to INT2. Since listening is needed on INT1 and INT3, and some forwarding is needed on INT2 and INT3 that will effectively cause all packets from INT1 and INT3 to be visible on INT2 and INT3.
Perhaps not a big deal for most, but it can cause some services to be visible (not reachable) on unintended interfaces.

[keyser]

@dennypage And thank you SO much to @dennypage for maintaining the package - and so selflessly spending time supporting it and us users.
Especially when we ask stupid questions or are so selfcentered we find ourselves important enough to outright complain over volunteer work like this.

All package maintainers should really have a HERO badge here on this forum.