When building my home lab, I chose to segregate the network devices into VLANs for easier management and administration. Everything worked until I realized I could access my printer, Apple TV, HomePod, and other smart devices only on my home LAN. So I realized my mistake while setting up VLANs. I needed to make mDNS work across the VLANs in my home network to easily access my printer, smart devices, and media streaming services.
While using VMs in Proxmox, I couldn’t access any devices or services from my home LAN, the one set by my router. For instance, Chromecast or AirPlay devices were not discoverable in any of the virtual machines in my Proxmox setup. After much tinkering, I realized mDNS transmits link-local multicast and works only on my home LAN. Hence, it’s not available on the VMs configured with VLANs. So, here’s what I did to make mDNS work across my VLANs.
Why did I choose an mDNS reflector instead of a proxy?
Keeping things simple for home lab
I wanted straightforward access to my Apple TV, smart devices, printers, and other IoT gadgets whenever I use VMs on Proxmox in my home lab. One of my goals in creating VLANs in Proxmox was to isolate dedicated networks, ensuring that existing devices wouldn’t interfere significantly. So I had to choose between using a mDNS reflector to rebroadcast everything or an mDNS proxy to act as a middleman for all those chatty devices.
I opted for an mDNS reflector since my home has a manageable number of multicasting devices. Also, I aimed to facilitate cross-VLAN discovery of services such as, AirPlay, Chromecast, printers, HomeKit, and others. In short, I expected mDNS to work reliably across VLANs.
My consumer-grade router, ASUS RT-AX88U, offers multicast routing, but won’t let me create mDNS reflectors or VLANs on the stock firmware. So, I made OPNsense work as an internal router/firewall to manage the VLANs on my Proxmox host and handle mDNS traffic between VLANs and the home LAN. To keep things minimal, I set up Avahi Reflector in a headless Debian 13-based virtual machine.
Setting up the mDNS reflector was straightforward
Using Linux instead of an OPNsense plugin
Since I use OPNsense as a firewall and set up VLANs for the VMs on Proxmox, I could easily set up the os-mDNS-responder plugin. However, I learned that it’s simply an mDNS proxy or a passive relay, which doesn’t work bidirectionally. So I picked Avahi reflector as my primary choice. But, merely installing Avahi daemon and its utilities package wasn’t enough. I removed the # symbol before the following values to enable them and reconfigured the avahi-daemon.conf file to suit my usage:
[server]
use-ipv4=yes
use-ipv6=no
allow-interfaces=ens18,ens19
deny-interfaces=lo
[reflector]
enable-reflector=yes
By making these changes, I ensured that the reflector parameter was enabled. Additionally, I configured the avahi-daemon to listen to only the ens18 (old eth0) and ens19 (eth1) network interfaces across VMs to reflect the mDNS traffic. You’ll need to determine and specify the exact interfaces to make them discoverable by the avahi-daemon. Also, I prevented Avahi from listening to the loopback interface so that it would minimize some unwanted noise and I could focus on bridging the VLANs.
Next, I ran the following commands to ensure the avahi-daemon always runs on the dedicated VM.
sudo systemctl start avahi-daemon
sudo systemctl enable avahi-daemon
Although it took several minutes to configure, troubleshoot, and run, it was relatively less confusing than the os-mdns-responder plugin for OPNsense.
Tweaking and tightening the mDNS reflection
Setting firewall rules for efficiency and security
I wanted to avoid any multicast flooding on my network and minimize unnecessary noise. The mDNS reflector acts as a central bridge that works seamlessly to facilitate the discovery of devices and services across segmented and isolated VLANs. OPNsense enables me to route traffic from my physical LAN to other VLANs. However, I equipped some firewall rules to exercise control while maintaining VLAN segmentation. I relied on the firewall rules to ensure better multicast bridging and service discovery across VLANs.
Before setting any firewall rules, I assigned a static IP address to the virtual machine running Avahi reflector, ensuring a dedicated machine instead of an entire VLAN for mDNS traffic reflection.
Here are some of the firewall rules that I set up in OPNsense:
- Allowing the UDP protocol traffic from home LAN and VLANs to the static IP of the Avahi reflector running VM on port 5353.
That felt much safer than making all devices on a particular VLAN handle the mDNS traffic.
- Blocking the UDP protocol traffic from LAN and VLANs to the multicast address (224.0.0.251) on port 5353.
These two firewall rules ensured that there was no multicast chaos, broadcast storm, or duplicate mDNS packets among VLANs and the home LAN. Removing the default rule that allowed everything from any source to any destination helped tighten the security and enable granular control for specific ports.
Dealing with mindful bridging across VLAN boundaries
Casting a YouTube video from a device on any VLAN to my smart TV is quite liberating. Deploying a mDNS reflector and firewall rules in OPNsense for no longer than an hour, including troubleshooting. While I may hesitantly assume it’s a one-time setup, it certainly is a game-changer to let me stream content or control smart home devices without leaving a VLAN or picking up another device. While VLANs do involve a steep learning curve to deal with the network complexities, they can solve your smart home headaches.