Smart Home Privacy
mDNS on VLANs: Smart Home Discovery Privacy 2026
How mDNS and DNS-SD work for Home Assistant and IoT, why VLANs break discovery, and how to relay reflector traffic without exposing your whole LAN in 2026.
Quick answer: How do I get Home Assistant discovery working across VLANs safely?
Use a dedicated mDNS reflector (Avahi on Linux, OPNsense os-mdns-repeater, or pfSense Avahi package) scoped to only the subnets that need discovery. Avoid broad anycast rules that turn your VLAN strategy into a flat network.
Source: IETF multicast DNS overview
Executive Summary
Multicast DNS (mDNS) on 224.0.0.251:5353 powers Bonjour, Chromecast, AirPlay, and many Home Assistant integrations1. VLANs block Layer-2 multicast by design—so phones on LAN cannot discover printers on IoT unless you relay reflector traffic under control.
This guide explains why discovery breaks, which tools fix it, and privacy trade-offs (wider multicast scope = more device visibility). Pair with IoT VLAN setup and OPNsense vs pfSense.
Bottom line: Enable minimal mDNS relaying between subnets that need it—never “open all VLANs” for convenience.
How mDNS and DNS-SD expose devices
mDNS lets hosts announce _hap._tcp, _googlecast._tcp, _home-assistant._tcp without a central DNS server2. That is convenient for consumers but leaks service inventory to anyone on the broadcast domain. On a single flat LAN, every phone sees every Chromecast—acceptable for many homes; unacceptable for guest networks.
| Mechanism | What leaks | Mitigation |
|---|---|---|
| mDNS broadcast | Service names + ports | VLAN isolation |
| LLMNR (legacy Windows) | Hostnames | Disable if unused |
| SSDP (UPnP) | HTTP control URLs | Block at firewall |
Why VLANs break Home Assistant companion apps
Home Assistant Mobile Discovery may rely on mDNS when the app and server share a broadcast domain. Put HA on 10.0.10.0/24 and your phone on 10.0.20.0/24 without a reflector—auto-discovery fails even though TCP port 8123 might be reachable3. Users mistakenly punch giant firewall holes when the real fix is targeted multicast relay.
Reflector options compared
| Platform | Tool | Notes |
|---|---|---|
| OPNsense | os-mdns-repeater | GUI-friendly; define interfaces explicitly4 |
| pfSense | Avahi package | Similar semantics; verify version |
| Linux / Proxmox host | avahi-daemon reflect-filters | Fine-grained if you manage config files |
| Access points | Vendor “mDNS proxy” | Verify it is not bridging all SSIDs blindly |
Step-by-step design pattern
- Inventory which subnets need discovery (e.g.,
LAN+IoT, notGuest). - Allow unicast HTTPS to HA (
8123or reverse proxy) with firewall rules—do not rely on mDNS for routine access. - Enable reflector only on those interfaces; log blocked multicast elsewhere.
- Test with one IoT device before scaling.
DNS filtering interaction
Pi-hole and AdGuard can answer local DNS for static names, reducing reliance on mDNS for known hosts5. That does not replace discovery for roaming devices—combine static records for servers with limited mDNS for ephemeral gadgets. See Pi-hole vs AdGuard.
Common misconfigurations
| Mistake | Symptom | Fix |
|---|---|---|
| Reflector on every VLAN | Excessive broadcast load | Limit to two interfaces |
| Blocking all multicast | Breaks legitimate IPv6 | Scope rules carefully |
| Expecting discovery without relay | App cannot find HA | Add unicast bookmark or relay |
Testing and validation
After enabling a reflector, capture packets on both VLANs to confirm only expected service types traverse (e.g., _hap._tcp for HomeKit). Use iperf separately to ensure multicast storms are not saturating switches. Roll back if CPU on the firewall spikes.
Threat model: what attackers gain from wider mDNS
Broader multicast visibility helps attackers fingerprint devices (printer models, smart TVs). Keep guest Wi-Fi isolated with no reflector into trusted VLANs. Document exceptions for AirPrint or casting if family requirements demand it.
Checklist
- List subnets and mark which truly need cross-VLAN discovery.
- Prefer HTTPS bookmarks over mDNS for Home Assistant mobile access.
- Enable reflectors on a maintenance window and capture firewall logs.
- Verify guest SSID cannot query IoT mDNS reflections.
- Document rollback steps if multicast storms appear.
FAQ
Frequently Asked Questions
Should I put Home Assistant on the same VLAN as IoT?
Sometimes—if you want simplest discovery—but you lose segmentation. Often better: HA on trusted VLAN + firewall + selective mDNS relay.
Does Docker break mDNS for Home Assistant?
Container networking can block multicast unless you use host networking or macvlan—check your install method.
Will reflectors slow my network?
Properly scoped relays add minimal load; misconfigured bridges can amplify broadcast storms—monitor switch counters.
Are Apple HomeKit accessories special?
HomeKit uses Bonjour; same VLAN or controlled relay applies—pair with HomeKit vs NVR context.
What about IPv6 multicast?
mDNS can use IPv6 link-local; ensure your reflector handles both stacks if dual-stack is enabled.
Primary sources
| ID | Source | URL |
|---|---|---|
| 1 | RFC 6762 mDNS | ietf.org |
| 2 | DNS-SD (RFC 6763) | ietf.org |
| 3 | Home Assistant network | home-assistant.io |
Conclusion
mDNS across VLANs is a solved but sensitive problem: reflect sparingly, log changes, and prefer static DNS for infrastructure hosts. After tuning, revisit DNS leak blocking so IoT cannot bypass your resolver with DoH.
Footnotes
-
mDNS uses link-local multicast 224.0.0.251 and UDP port 5353 per RFC 6762. ↩
-
DNS-SD service types such as
_http._tcpadvertise capabilities without centralized DNS. ↩ -
Unicast reachability does not imply working discovery—applications may still expect multicast responses. ↩
-
OPNsense mdns-repeater plugin documentation describes per-interface reflection. ↩
-
Local DNS records in Pi-hole/AdGuard reduce need for mDNS for fixed hosts. ↩