Lesson 5 of 5 10 min read

Keeping Smart Home Features Working Across VLANs

You have created VLANs, assigned devices, and locked down firewall rules. Everything is isolated and secure. And then you discover that Siri cannot find your HomeKit accessories, Spotify cannot cast to your speaker, and your Home Assistant automations have stopped triggering. Welcome to the multicast problem—the single biggest headache of VLAN-segmented smart homes. This lesson explains why it happens and how to solve it without compromising your security posture.

The Multicast Discovery Problem

Most smart home ecosystems rely on multicast or broadcast protocols for device discovery:

  • mDNS (Multicast DNS) / Bonjour: Used by Apple HomeKit, AirPlay, AirPrint, Spotify Connect, and many other services. Devices announce themselves by sending UDP packets to the multicast address 224.0.0.251 on port 5353. Other devices on the same network listen on this address to discover available services.
  • SSDP (Simple Service Discovery Protocol) / UPnP: Used by Chromecast, Roku, and many media streaming devices. Devices send UDP packets to the multicast address 239.255.255.250 on port 1900.

The critical point: multicast traffic does not cross VLAN boundaries. Multicast packets are confined to their broadcast domain. When your iPhone on the Trusted VLAN sends an mDNS query looking for HomeKit accessories, that query never reaches the IoT VLAN where your smart bulbs live. The bulbs never see the query, never respond, and your iPhone concludes no accessories exist.

This is by design—VLAN isolation is doing exactly what you asked it to do. The challenge is selectively allowing discovery traffic while maintaining the security boundaries you have built.

Solution 1: mDNS Reflection / Repeater on the Router

The most common and cleanest solution is to enable mDNS reflection (also called mDNS repeating) on your router. This feature listens for mDNS packets on each VLAN and re-broadcasts them onto other specified VLANs. The router acts as a bridge for discovery traffic only.

UniFi

On UniFi, mDNS reflection is built in. Navigate to Settings > Networks (or Settings > Services > mDNS in some firmware versions) and enable Multicast DNS. This reflects mDNS between all networks. In newer UniFi firmware, you can control which networks participate in mDNS reflection.

pfSense / OPNsense

On pfSense, install the Avahi package from System > Package Manager. Once installed, configure it under Services > Avahi. Enable the service, select the interfaces (VLANs) that should participate in mDNS reflection, and ensure “Enable reflection” is checked. OPNsense has a similar Avahi plugin available through its package system.

Firewalla

Firewalla supports mDNS reflection natively. Under Network > Network Manager, enable “mDNS Reflector” and select which segments should share mDNS traffic.

What mDNS Reflection Does Not Do

mDNS reflection allows discovery—devices can find each other across VLANs. But the actual control traffic (commands to turn on a light, stream audio, etc.) still needs to pass through the firewall. Your existing “allow trusted to IoT” rule handles this: your phone discovers the bulb via reflected mDNS, then sends control commands that the firewall allows because they originate from the trusted VLAN.

Solution 2: IGMP Snooping

IGMP (Internet Group Management Protocol) snooping is a switch-level feature that optimizes multicast traffic delivery. Without IGMP snooping, the switch floods multicast traffic to every port. With IGMP snooping enabled, the switch tracks which ports have devices interested in specific multicast groups and only forwards multicast traffic to those ports.

When to Enable IGMP Snooping

  • Enable IGMP snooping on all VLANs that carry multicast traffic (IoT, trusted, cameras).
  • It reduces unnecessary network load, especially on camera VLANs where video streams are multicast.
  • Ensure your router is configured as the IGMP querier for each VLAN. Without a querier, IGMP snooping tables expire and the switch falls back to flooding, negating the benefit.

The Device Roaming Gotcha

When a wireless device roams from one access point to another, IGMP snooping tables may become stale. The device has moved to a new port, but the switch still thinks multicast traffic should go to the old port. Most enterprise switches handle this gracefully by re-learning when the device sends a new IGMP join, but budget switches may have delays. If you notice intermittent multicast issues (casting stops working after a device moves to a different room), stale IGMP state is a likely culprit. Lowering the IGMP query interval on the router can help.

Solution 3: Avahi as an mDNS Proxy on Linux

If your router does not support mDNS reflection, you can run Avahi as an mDNS proxy on a Linux machine connected to multiple VLANs. A Home Assistant server is an ideal candidate because it often needs to communicate with devices on both the trusted and IoT VLANs.

On a Debian/Ubuntu-based system (including Home Assistant OS via the Terminal add-on):

  1. Install Avahi: sudo apt install avahi-daemon
  2. Edit /etc/avahi/avahi-daemon.conf and set:
    • enable-reflector=yes
    • allow-interfaces=eth0,eth0.20 (listing the VLAN interfaces that should participate)
  3. Restart Avahi: sudo systemctl restart avahi-daemon

The Linux machine must have interfaces on each VLAN (either physical NICs or VLAN sub-interfaces). It then listens for mDNS on all configured interfaces and repeats announcements between them.

Specific Exemptions for Common Use Cases

Some devices and services require special firewall rules beyond mDNS reflection:

Home Assistant

Home Assistant is often the central hub that needs to reach devices on the IoT VLAN. You have two options:

  • Place HA on the trusted VLAN and rely on the “allow trusted to IoT” firewall rule. This is simpler but means HA is on the same network as your personal devices.
  • Place HA on the IoT VLAN and create specific firewall rules allowing your phone/laptop to reach HA’s web interface (port 8123). This is more secure but requires more rules.

Regardless of placement, HA needs unrestricted access to the IoT VLAN for integrations, and it may need access to the camera VLAN if you use camera integrations (RTSP streams, Frigate, etc.).

Matter and Thread Border Routers

The Matter smart home standard uses IPv6 multicast extensively. Thread border routers (devices like the Apple TV 4K, HomePod Mini, or Nanoleaf Thread devices) form a mesh network and need to exchange IPv6 multicast traffic across network boundaries. If you use Matter devices:

  • Ensure IPv6 is enabled on both the trusted and IoT VLANs.
  • Allow ICMPv6 between VLANs (needed for neighbor discovery and router solicitation).
  • Allow IPv6 multicast traffic (specifically, ff02::/16 and ff03::/16 scopes) between VLANs where Thread border routers and Matter controllers reside.
  • If your Thread border router (e.g., HomePod Mini) is on the trusted VLAN and your Thread devices are on the IoT VLAN, the border router needs to bridge between them. This may require both devices to be on the same VLAN, or careful IPv6 routing rules.

Matter is still relatively new, and cross-VLAN Matter setups can be finicky. Test thoroughly after any VLAN changes.

Philips Hue Bridge

The Hue Bridge needs to be reachable from your phone (trusted VLAN) for the Hue app and from Home Assistant if you use the Hue integration. If the bridge is on the IoT VLAN, create a firewall rule allowing traffic from the trusted VLAN to the Hue Bridge’s IP on port 443 (HTTPS API) and port 80 (HTTP API for local v1 API calls). Alternatively, since the “allow trusted to IoT” rule already permits this, no additional rules may be needed.

Casting (Chromecast, AirPlay, Spotify Connect)

After enabling mDNS and/or SSDP reflection, casting requires the controller (your phone) to reach the cast target (the speaker or TV). If your phone is on the trusted VLAN and the Chromecast is on the IoT VLAN, the “allow trusted to IoT” rule covers the initial connection. However, some casting protocols also require the cast target to establish a reverse connection back to the controller for status updates. The “allow established/related” rule handles most of these, but if casting is unreliable, you may need to allow specific ports from the IoT VLAN to the trusted VLAN:

  • Chromecast: TCP 8008, 8009, and 8443
  • AirPlay: TCP 7000, 7100, and a dynamic range
  • Spotify Connect: TCP 4070, 57621

Testing Checklist

After configuring mDNS reflection and firewall exemptions, work through this comprehensive test list:

  1. Voice assistant device discovery: Ask Alexa or Google to discover devices, or open the Home app on iOS and verify all HomeKit accessories are reachable.
  2. Casting: Cast a YouTube video to a Chromecast. Play a Spotify track on a connected speaker. AirPlay audio to a HomePod or AirPlay-compatible speaker.
  3. Automations: Trigger a Home Assistant or HomeKit automation that controls an IoT device. Verify it executes within the expected timeframe.
  4. Camera feeds: Open your camera app (Ring, Wyze, UniFi Protect, etc.) and verify live streams load. If using local NVR, check that recordings are being captured.
  5. Firmware updates: Trigger a firmware check on an IoT device and verify it can download and install updates. If you have restricted outbound internet from the IoT VLAN, ensure HTTPS (port 443) is allowed.
  6. New device onboarding: Connect a new device to the IoT SSID and complete its setup process. Some devices require being on the same network as your phone during initial setup. If setup fails, temporarily connect your phone to the IoT SSID for onboarding, then switch back to the trusted SSID.

Troubleshooting Common Issues

Device Discovery Works Initially but Fails Later

mDNS cache entries and IGMP snooping tables have expiration times. If discovery works right after configuration but breaks after hours or days, check that the IGMP querier is running and that mDNS reflection is persisting through router reboots.

HomeKit Shows “No Response”

HomeKit relies heavily on mDNS. If accessories show “No Response” in the Home app, verify mDNS reflection is working by running dns-sd -B _hap._tcp on a Mac connected to the trusted VLAN. If no results appear, mDNS reflection is not functioning correctly.

Onboarding Requires Same Network

Many IoT devices use a direct Wi-Fi connection or Bluetooth for initial setup, then transition to cloud control. During onboarding, the device may need to be on the same VLAN as your phone. After setup is complete, move the device to the IoT VLAN by connecting it to the IoT SSID (some devices allow changing networks in their app settings; others require a factory reset and re-setup on the correct SSID).

Summary

The biggest operational challenge of VLAN segmentation is maintaining smart home functionality that depends on multicast discovery protocols. mDNS reflection on the router is the primary solution, allowing devices on different VLANs to discover each other while maintaining firewall-enforced isolation for all other traffic. IGMP snooping optimizes multicast delivery but requires an active querier. Avahi on a Linux machine provides mDNS proxying when the router lacks native support. Specific exemptions are needed for Home Assistant, Matter/Thread border routers, Hue Bridge, and casting protocols. Always test device discovery, casting, automations, camera feeds, firmware updates, and new device onboarding after any VLAN configuration change. With these solutions in place, you have a segmented network that is both secure and fully functional for daily smart home use.

Lesson Complete