Roon Nucleus server discovery issues across VLANs (ref#F8X42Y)

What’s happening?

· I’d like to suggest a feature or give feedback

Describe the issue

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 and mdns is active. Roon can't be found unless I get on IoT wifi where it works fine. Once the server has been found, I can change back to VLAN10 and Roon works fine until some kind of background authentication happens then it loses the Nucleus again. I don't have this issue with BluOS, Nest, Alarm system, Garage control, etc all of which are on VLAN20 and can take commands from VLAN10. Only Roon has this problem.

Two suggestions 1) allow the Roon client to accept the IP address of the Nucleus so it knows where to find it (i'm presuming the Roon app only looks on the same subnet as the device looking) and 2) make it easy to for users to understand what ports in their firewall need to be left open so Nucleus discovery is not problematic.

I have been all over the Tinkering section and there is really technical stuff mostly related to VPN's not VLAN's. This should be a really easy problem to be avoided and many people (that aren't network engineers) setting up IoT networks for security reasons. As said earlier every other device works across the VLAN interface.

Describe your network setup

Unifi UDM pro behind an ATT Fiber modem. Almost all of my devices are hardwired to network except iPhones. All switches are Unifi devices and Unifi AP is wifi6.

Hello @MikeW,

Thank you for taking the time to share your setup and suggestions.

We want to clarify an important point up front:

Roon does not support VLAN-separated environments.

This is a fundamental limitation of how Roon’s discovery and communication protocols operate. Roon relies heavily on multicast, broadcast, and tightly-coupled LAN behavior, which are inherently incompatible with segmented networks — even when firewall rules appear open or mDNS forwarding is enabled.

While some devices (BluOS, Nest, alarms, etc.) may function across VLANs, Roon’s architecture is substantially different and requires all Roon components (Server, Remotes, and Outputs) to reside on the same Layer 2 broadcast domain.

Because of this, issues like the one you’re experiencing are expected in a VLAN deployment.

Regarding your feature suggestions

We appreciate the thoughts, but:

  1. Manual IP entry for Roon Server discovery
    This is not compatible with Roon’s design, which relies on ongoing bidirectional discovery rather than one-time IP resolution. Discovery, metadata transport, RAAT, authentication, and zone updates all depend on being in the same broadcast domain.
  2. Publishing a port-based VLAN firewall guide
    Unfortunately this also isn’t workable. Roon’s discovery and RAAT protocols rely on multicast/broadcast behavior that cannot be “opened” via static ports across VLANs in a reliable or supported way.

What is supported

To avoid instability, you will need to ensure that:

  • Nucleus, all endpoints, and all Roon Remotes reside on the same VLAN / subnet.
  • No L2 or L3 segmentation sits between Roon devices.
  • Multicast isolation features are disabled for Roon-related VLANs.

Once everything is within a flat LAN, discovery and connectivity should stabilize completely.

We’re here if you need further assistance.

Hi @MikeW,

Please let us know if we can answer any questions or clarify any of the above points further.

For a brief overview of our general network recommendations, please see here:

Thanks for the information. I have had a couple of days to experiment. On the same subnet everything works fine. To repeat my Nucleus and all the players are on VLAN20. If the apps are allowed to discover the Nucleus on VLAN20 and are switched back to VLAN10 they are completely stable until I update the Nucleus or restart the PC or iPhone (on VLAN10). 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. I’m trying to figure out which of these two scenarios are the problem. The second scenario is easy to fix as it just requires some allowed communication from the Nucleus through the firewall. The first scenario requires you to change the remote software. As an aside both Control4 and BluOS (on VLAN20) never have this discovery issue and there is no issue with player discovery.

Hey @MikeW,

I’d recommend posting your question over in the Tinkering category, where others who run Roon with VLANS may be able to provide additional thoughts or tips. :+1:

That sounds strange. I have the same setup. Roon server and sonos speakers and endpoints on my media vlan and my phones and computers on the client vlan with a unifi router and a zone based firewall. I have no problems to find my Roon server, neither from the client vlan (roon app) nor from my VPN (Roon ARC). I have MDNS enabled on these 2 vlans and is passing all traffic from the client vlan to the media vlan.

There are no firewall rules on your roon server that prohibits vlan 10?

My IoT vlan is firewalled from my primary VLAN so anything that the Roon Server sends to vlan10 is blocked. That’s what I’m trying to figure out is what do I leave open. Would prefer not to allow fully open access from Roon server to VLAN 10

So if you do not have a local firewall on your Roon server, and you have “auto allow return traffic” on the firewall rule that allows all traffic from vlan 10 to 20 and enabled MDNS, I do not have any more ideas, sadly.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.