UDP Broadcast Relay – Blocking outbound broadcasts on specific interfaces

[8b4df00d]

Hi everyone,

My homelab is segmented into several VLANs. Certain devices use mDNS to advertise their services across subnets (e.g., AirPlay on Apple TVs). To make these services discoverable, I am using the UDP Broadcast Relay plugin (Relay Port: 5353, Broadcast Address: 224.0.0.251, Source Address: 1.1.1.1). I have also created the necessary firewall rules on each interface allowing traffic from the local subnet to 224.0.0.251 on UDP/5353.

This setup works flawlessly, and all mDNS services are forwarded as expected.

On the WAN side of my OPNsense, I have a standard FRITZ!Box network containing shared devices (such as an AirPrint-capable printer).

Technically, I could just add the WAN interface to the UDP Broadcast Relay configuration, add the corresponding firewall rule, and the printer would become available.

However, I have security concerns: adding WAN to the relay would mean that all mDNS broadcasts from my internal VLANs would also be forwarded/exposed to the WAN network. Even though this is just a homelab, I would like to prevent internal broadcasts from leaking into the WAN (since this interface is shared with others).

What I have tried so far:

• I added a floating/outbound rule on the WAN interface to block traffic from any to 224.0.0.251 on UDP/5353. This did not work; the broadcasts are still sent out on WAN.
• Blocking incoming traffic to 224.0.0.251:5353 on the internal interfaces does stop the broadcast on WAN, but it also breaks mDNS functionality entirely because OPNsense no longer receives the initial mDNS requests.

My Question:
Is there a way to selectively listen to mDNS on internal interfaces and relay them to specific VLANs, while blocking the relay from broadcasting those gathered mDNS packets out onto the WAN interface?

Thanks in advance for any insights!

[Tinus]

If a machine wants to resolve an mDNS name, it sends a multicast message to port 5353. All the other machines see this message, and the ones that want to claim that name respond with a multicast message to port 5353.

What the relay does is simply listen to all these messages and for every message that comes in on one of the configured interfaces, repeat it on all of the other configured interfaces.

So with simple firewall rules you can't really distinguish between the requests and replies and what you want to achieve is not possible. You would have to use a different relay that allows you to be more selective. I don't know if that exists and if the results would be what you want.