Joe B.

Expert ★★★★★ 27,853 satisfied customers

Specialities: Windows 11/10, Printers, Networking, VLANs, Multicast & Bonjour/mDNS

mDNS not propagating across VLANs — Bonjour across subnets, mDNS reflector/gateway, firewall & multicast rules

Technician

Hey! We’ll track down why mDNS is not propagating across VLANs and fix your Bonjour discovery across subnets.
A few questions so we don’t guess: Which services are failing — AirPrint, AirPlay, Chromecast, HomeKit, something else? Are those devices isolated in a dedicated IoT VLAN while clients are on another VLAN/SSID? And what network gear are you using (UniFi, MikroTik, OpenWrt, Cisco/Meraki, etc.) — does it have a built-in mDNS reflector / Bonjour gateway option?

Customer

Services are the main issue. I’ve got printers and Apple TVs in an IoT VLAN, user devices on a separate LAN VLAN. On the same VLAN, mDNS / Bonjour discovery works fine. Across VLANs, nothing shows up — no AirPrint, no AirPlay. I tried loosening firewall rules but mDNS is still not working across VLANs. My router is running a Linux-based distro, and I keep hearing I should use an mDNS reflector like Avahi, but I’m not sure how that fits with VLANs and firewall rules.

Technician

Got it. This is the classic “mDNS not propagating across VLANs” design limitation, not a bug.

By default, mDNS (multicast DNS) uses UDP 5353 to 224.0.0.251 (or ff02::fb for IPv6). Those are link-local multicast addresses — they are deliberately not routed between subnets. So when you segment clients and IoT devices into different VLANs, you also segment Bonjour discovery.

That’s why your services work on one VLAN/SSID and vanish across VLANs.
To fix it, we either:

• Deploy an mDNS reflector / mDNS repeater (Avahi, built-in UniFi mDNS reflector, VyOS mDNS repeater, etc.) that listens on each VLAN and reflects mDNS packets between interfaces, or
• Use a Bonjour gateway on some wireless controllers to selectively forward and proxy mDNS service records between VLANs.

Plan:
1) Verify basic multicast (IGMP snooping, querier) and firewall for UDP 5353 on each VLAN.
2) Configure an mDNS reflector (Avahi or vendor feature) and bind it to the right VLAN interfaces.
3) Limit reflected services to what you need (AirPrint/AirPlay) so you don’t flood every network with mDNS noise.
4) Test discovery from LAN → IoT and back to confirm mDNS across VLANs is working.

Customer

That explains why it broke when I moved stuff into separate VLANs. In my case, clients are on VLAN 10, IoT devices (printers, HomePods, Chromecasts) on VLAN 30. I allowed UDP 5353 between the VLANs in the firewall but discovery still fails, so I guess the router isn’t actually forwarding the multicast 224.0.0.251 traffic. Can you walk me through a sane mDNS reflector config so services show up across VLANs without opening everything up?

Technician

Step 1 — Confirm mDNS works per-VLAN and multicast isn’t totally broken
Before we drop in a reflector, we want to make sure local mDNS is healthy on each VLAN:
1) Plug a test laptop or phone into the IoT VLAN (same VLAN as the printers/Apple TVs) — either via SSID mapped to VLAN 30 or a tagged switch port.
2) From that VLAN, confirm that AirPrint printers, AirPlay receivers, and Chromecasts show up normally. If discovery fails even within the VLAN, you have a local multicast issue (sometimes IGMP snooping without a querier or multicast disabled on a Wi-Fi profile). Fix that first.
3) Next, move the client back to the user VLAN (VLAN 10). Confirm you can ping the IoT device via IP but mDNS/Bonjour names and services still don’t appear. That tells us unicast routing is fine but mDNS is not propagating between VLANs, which is expected without a reflector or Bonjour gateway.

Once local multicast is confirmed on each VLAN, an mDNS reflector becomes the clean, predictable fix for discovery across subnets.

Customer

I tested that: when my Mac is on the IoT SSID (same subnet as the printers), all the AirPrint and AirPlay stuff shows up. On the normal user VLAN, I can ping the printers and Apple TVs by IP, but they never appear as Bonjour services. So yeah, mDNS works inside each VLAN, just not across VLANs. I’m fine putting a small Linux VM or container on the router — I just don’t know the right Avahi reflector configuration or how to keep it from blasting mDNS everywhere.

Technician

Perfect — that’s exactly when an mDNS reflector is the right tool.

With Avahi, the reflector mode acts like an mDNS repeater: it listens for multicast DNS queries on one interface (say, VLAN 10), and reflects them to the other interface (VLAN 30), and vice versa. It doesn’t “route” 224.0.0.251 in the traditional sense; instead it re-emits the packets on each interface where it’s allowed.

Typical high-level Avahi mDNS reflector config looks like this:

• Enable enable-reflector=yes so Avahi repeats mDNS between interfaces.
• Limit allow-interfaces= to just the VLAN interfaces you want to bridge (for example, br-lan and br-iot).
• Optionally add reflect-ipv= controls or service filters depending on platform to avoid reflecting every service type.

Most of the “noise” concerns are solved by only reflecting between two or three VLANs and letting the rest of the network remain isolated. A lot of OpenWrt and VyOS setups use exactly this pattern for AirPrint across VLANs and HomeKit across VLANs.

Customer

That helps conceptually. Could you give me a more concrete example of the Avahi configuration for an mDNS reflector between VLAN 10 (LAN) and VLAN 30 (IoT)? Also, do I still need firewall rules between those VLANs if Avahi is reflecting mDNS, or does it somehow bypass the firewall?

Technician

Step 2 — Example mDNS reflector config (Avahi)
Let’s assume:

• Interface for VLAN 10 (LAN) is br-lan
• Interface for VLAN 30 (IoT) is br-iot

In /etc/avahi/avahi-daemon.conf, the critical bits look roughly like:

[server]
use-ipv4=yes
use-ipv6=yes
allow-interfaces=br-lan,br-iot

[reflector]
enable-reflector=yes

The exact syntax may vary slightly by distro, but the key option is enable-reflector=yes, which tells Avahi to reflect mDNS between all allowed interfaces so that clients can browse services from other VLANs as if they were local.

Regarding the firewall:
• Avahi itself runs on the router/VM, inside the system, and sends/receives multicast on each VLAN interface. Your inter-VLAN firewall rules still apply for unicast traffic to the service (like printing to IPP or streaming to an Apple TV).
• You normally do not need to “route” 224.0.0.251 between VLANs because Avahi is handling the reflection. But you must allow unicast traffic from VLAN 10 to the service ports on VLAN 30 (e.g., IPP 631, AirPlay ports, Chromecast TCP/UDP ports).

So the pattern is: mDNS reflector for discovery, and a tight firewall that allows only the unicast traffic you actually want between VLANs.

Customer

Understood. I’m also running managed switches and Wi-Fi APs with IGMP snooping. Could that interfere with mDNS across VLANs, or is the reflector enough? I’ve seen people mention IGMP queriers, “multicast to unicast” on APs, and vendor features like UniFi’s mDNS reflector or Juniper’s Bonjour gateway. It’s a bit confusing which knobs actually matter when mDNS is not propagating across VLANs.

Technician

Great question — multicast knobs can absolutely affect mDNS behavior inside a VLAN and how well your reflector works.

Key pieces:
• IGMP snooping on switches is fine, but you need some form of IGMP querier in each broadcast domain so snooping tables don’t age out. Many routers or L3 switches can act as the querier.
• On Wi-Fi, options like “multicast to unicast” or “proxy ARP” are usually safe, but aggressive multicast filtering on the SSID can break Bonjour/mDNS. If mDNS fails even within one VLAN, check the WLAN profile for multicast blocking.
• Some vendors (UniFi, Mist, Extreme, Cisco, etc.) bundle this into a built-in mDNS reflector / Bonjour gateway feature. Instead of a separate Avahi VM, you flip on “mDNS reflector” or “Bonjour gateway” and select which VLANs or SSIDs should share mDNS services.

With your Linux router + Avahi, the main multicast requirements are:
1) Ensure multicast is not globally disabled on VLAN 10 and 30.
2) Make sure the APs forward UDP 5353 on those SSIDs.
3) Run one mDNS reflector that listens on the VLAN interfaces and let it handle cross-VLAN discovery.

If you ever move to gear with a native Bonjour gateway, you’d typically disable the Avahi reflector and configure the vendor gateway to forward only the service types you care about (e.g., _ipp._tcp, _airplay._tcp, _googlecast._tcp).

Customer

That clears up a lot. I’d like some simple “rules of thumb” for our small office: we’ve got a couple of VLANs (LAN, IoT, guest), a couple of SSIDs, and mostly want AirPrint and AirPlay across VLANs but don’t want guests to see everything. Any suggestions on how to keep the mDNS reflector config tidy and not accidentally expose services to the wrong network?

Technician

Absolutely — think of mDNS across VLANs like any other shared resource: only bridge what you actually need.

Good small-office pattern:
• Keep IoT devices (printers, Apple TVs, smart speakers, Chromecast) in a dedicated IoT VLAN.
• Allow mDNS reflection only between LAN ↔ IoT VLANs (no reflection to Guest). In Avahi, that means listing only the LAN and IoT interfaces in allow-interfaces and leaving the guest VLAN out.
• Keep the firewall stateful and narrow: only allow unicast ports needed for AirPrint (IPP 631, sometimes RAW 9100), AirPlay (TCP/UDP ports Apple uses), Chromecast, etc., from LAN to IoT. Guests should either get no mDNS across VLANs or only tightly-scoped Bonjour gateway rules if required.
• If your stack supports it, filter which DNS-SD service types traverse the mDNS reflector or Bonjour gateway so you’re only forwarding _ipp._tcp, _airplay._tcp, _googlecast._tcp instead of every random service on the network.

That way you solve “mDNS not propagating across VLANs for AirPrint/AirPlay” without turning your segmentation into one flat broadcast domain again.

Customer

I applied the Avahi reflector settings with LAN and IoT interfaces only, confirmed multicast isn’t blocked, and tightened the firewall to just the service ports you mentioned. Now AirPrint, AirPlay, and Chromecast all show up from the user VLAN but not from the guest VLAN, which is perfect. mDNS finally works across the VLANs that should see it.

Technician

That’s exactly the outcome we want — mDNS propagating across the right VLANs, but still respecting segmentation.

Final checks so your mDNS reflector keeps behaving:
• Monitor CPU and logs on the Avahi host; if you add lots of IoT devices, consider filtering service types or limiting which VLANs are reflected to avoid mDNS “storms”.
• Document which VLANs participate in Bonjour across subnets so future firewall changes don’t accidentally break UDP 5353 or the unicast service ports.
• If you change SSIDs or move devices between VLANs, re-verify that each VLAN still has a functioning local mDNS domain plus a path through the reflector.
• For large or Wi-Fi-heavy environments, consider vendor features like a Bonjour gateway on the AP/controller instead of a DIY VM, especially if you want more granular control and reporting.

But for a lot of networks, a well-configured mDNS reflector across VLANs is the sweet spot: simple, predictable, and it just makes AirPrint/AirPlay “work like home” again.

Customer

Awesome, that’s exactly what I needed. mDNS is finally working across the VLANs that I want, and discovery is stable. Thanks for walking through the reflector configuration and firewall side of it so clearly.

Technician

Summary: When mDNS is not propagating across VLANs, that’s by design: UDP 5353 to 224.0.0.251 is link-local multicast and doesn’t cross subnets. The fix is to keep multicast healthy per-VLAN, then use an mDNS reflector / Bonjour gateway to repeat discovery between selected VLANs while the firewall still controls unicast traffic. Configure something like Avahi in reflector mode, bind it to your LAN and IoT VLANs, and only allow the ports and service types you actually need. Want help mapping this to UniFi, OpenWrt, Cisco, or another platform? Open the chat and an expert will build the config with you.

Quick answer: the accepted fix

Accepted fix when mDNS is not propagating across VLANs: confirm Bonjour/mDNS works inside each VLAN, then deploy an mDNS reflector / Bonjour gateway (for example, Avahi with enable-reflector=yes) bound to the VLAN interfaces you want to bridge. Keep link-local multicast (UDP 5353) enabled on those VLANs, allow only required unicast service ports (IPP, AirPlay, Chromecast, etc.) through the firewall, and avoid reflecting to guest or untrusted networks. This restores mDNS discovery across subnets without flattening your VLAN design.

FAQ

Step-by-step: enabling mDNS across VLANs with a reflector

1. Verify that Bonjour/mDNS services work inside each VLAN (no reflector yet). Fix local multicast issues first if discovery fails on a single VLAN.
2. On your router or a small Linux VM, install and configure an mDNS reflector (for example, Avahi) with enable-reflector=yes and allow-interfaces set to the VLAN interfaces that should share services.
3. Ensure multicast is not globally blocked on those VLANs and that Wi-Fi SSIDs mapped to them allow UDP 5353. If you run IGMP snooping, make sure there is an IGMP querier active.
4. Update firewall rules so clients on the “consumer” VLAN can reach the service ports (IPP 631 for AirPrint, AirPlay/Chromecast ports, etc.) on the IoT VLAN, while still blocking unnecessary traffic and keeping guest networks isolated.

Note for UniFi, OpenWrt & controller-based networks

1. On platforms like UniFi, Mist, or Enterprise WLAN controllers, look for a built-in mDNS reflector / Bonjour gateway option. Enable it on the SSIDs and VLANs where you want mDNS across subnets and select the service types to forward.
2. On OpenWrt or similar, use Avahi reflector mode or a supported mDNS package, following the vendor’s guide for firewall rules and interface selection so discovery remains limited to the VLANs you choose.

Sources

• Debian manpages — avahi-daemon.conf (enable-reflector and mDNS reflection)
• Christopher Smart — Resolving mDNS across VLANs with Avahi on OpenWrt
• Juniper Mist — Bonjour gateway for mDNS across VLANs

Matt ● replies in < 1 min

Technician Expert

⭐⭐⭐⭐⭐ Trusted by 27,000+ customers

Alex · Expert's Assistant

Start Chat

5 Tech Support Specialists are online right now.