Having issues using VLANs and what ROON does to find the server. Roon Nucleus and all devices that play are on IoT (VLAN20) and all of the access devices (iPhones, iPad, PC) are on VLAN10. I have setup a firewall rule that any device on VLAN10 can talk to VLAN20 and take return traffic. MDNS is active. Roon can’t be found unless I get on the IoT wifi where it works fine. Once the server has been found, I can change back to VLAN10 and Roon works fine until the Nucleus software is updated or the device on VLAN10 is restarted and the server has to be discovered again.
This implies that either 1) the remotes don’t look off the current subnet for the Nucleus or 2) the Nucleus is sending something back that’s not permitted through the firewall. The firewall rule allows all traffic from VLAN10 to VLAN20 and replies but no traffic originated on VLAN20 to get to VLAN10. The second scenario is easy to fix as it just requires some allowed communication from the Nucleus through the firewall which I hope someone here knows the solution.
As an aside I don’t have this issue with Control4, BluOS, Nest, Alarm system, Garage control, etc or with player discovery all of which are on VLAN20 and can take commands from VLAN10. Only Roon app has this problem.
I have been all over the Tinkering section and there is some really interesting technical stuff mostly related to VPN’s not VLAN’s. This should be a really easy problem to be avoided with many of us (that aren’t network engineers) setting up IoT networks for security reasons.
Hardware: Running Unifi UDM pro, Unifi switches and AP behind Fiber connection to internet.
@MikeW
Mike I suspect its because you dont have the necessary multicast routing solution in place so that SSDP discovery packets get passed between your VLANS. MDNS wont do that. I’ve used SMCRoute in the past but dont know the Unifi UDM pro but maybe it has something similar.
This is a classic Discovery vs. Routing issue. It is very common with Roon (and Sonos) when devices are placed on separate VLANs.
What you are seeing is expected behavior when multicast discovery is partially blocked.
What is actually happening
Discovery is link-local multicast, not normal routed traffic
When you open the Roon app on VLAN10, it attempts to discover the Core using mDNS (UDP 5353). This is link-local IP multicast, which is not routed between subnets by default.
Your UniFi gateway routes -unicast- traffic between VLANs just fine, which is why Roon works after the Core has been found once (the Core IP is cached).
Why it works once, then breaks again
When you are on VLAN20, discovery works locally (no routing involved).
After discovery, Roon switches to unicast TCP/IP (direct IP) for control, which your router handles correctly.
When the Core or controller restarts, discovery must run again.
Multicast discovery does not cross VLANs unless explicitly allowed or reflected.
The most common UniFi-specific cause (Check this first)
On UniFi systems, this is very often caused by an SSID setting, not a firewall rule.
Check both SSIDs (VLAN10 and VLAN20):
Go to Settings → WiFi → [SSID] → Advanced
Look for Multicast and Broadcast Control
(or “Block LAN to WLAN Multicast and Broadcast Data” in older UI versions)
This must be DISABLED
If this is enabled, the access point drops mDNS packets silently, even if global mDNS is turned on at the gateway.
Required UniFi Settings Checklist
Global mDNS: Settings → Services → Multicast DNS → ON
SSID Settings: Multicast/Broadcast Control DISABLED on both SSIDs
IGMP Snooping: Enabled on both VLAN10 and VLAN20 networks
Optional Firewall Refinement (Only if you run strict segmentation)
Normally no special firewall rule is required once multicast is allowed. However, if you want to be explicit, ensure this is allowed in LAN IN:
Action: Accept
Protocol: UDP
Source: Roon Nucleus IP (VLAN20)
Destination: VLAN10
Port: 5353 (and optionally 9003)
Fallback Workaround
If multicast remains problematic, Roon supports manual connection:
Assign a static IP to the Nucleus.
On the Roon remote “Waiting for Core” screen, look for “Connect via IP” (sometimes hidden under “Help” or “Configure”).
Enter the Core IP.
This bypasses multicast discovery entirely.
Summary
This is not a general routing problem.
Roon discovery depends on mDNS multicast, which UniFi often blocks at the SSID level by default.
Fix multicast handling and Roon will behave normally across VLANs.
Thank you for the explanation and specific guidance. I had already set the “required Unifi Settings Checklist” correctly. I tried adding the firewall rule and I must have gotten something wrong as it didn’t solve problem…I will continue to fiddle with this. I already had ROON server on static IP address so specifying in the app works like a charm. I have a limited number of devices so this will work. Will continue to try to get firewall rule to work.
IoT networks can be special. Your IoT VLAN (20) likely has client isolation or device isolation enabled, which prevents devices on the same VLAN from communicating with each other. This is a common security feature on IoT networks. Just even being on the same subnet doesn’t mean they can communicate it this is enabled.