I’ve recently come to discover,to my horror, that ROON doesn’t work in a multi-vlan’d network where the CORE is on a separate VLAN than where the REMOTE is located.
After searching around I see this issue has been raised in the past with an the answer being that its unlikely to ever be fixed due to how the ROON REMOTE currently works.
I’ve attached a screenshot taken from a recent Wireshark capture that I did while trying to understand what is going on. As you can see from the attachment, it appears that when the ROON REMOTE is opened on my mobile device the APP initiates a Multicast ARP request to every possible IP Address found within the particular VLAN/Subnet where the REMOTE is located. This is basically a caveman like approach in order to try and find the ROON CORE that it needs to talk to.
Since Multicast ARP requests are simple Layer 2 they are not routable outside of the single broadcast domain they originated from. This explains why the REMOTE is unable to find the CORE on a different VLAN.
So with all that said I have two questions:
Has any progress been made or further thought given to allow the ROON REMOTE/CORE pairing to work in a Multi-VLAN environment? Would it be possible to give the end user two options during initial setup with one option being the existing default behavior of the REMOTE and another, new option, being let the end user enter a specific IP Address of the CORE turning off the ARP Multicast behavior of the REMOTE?
If support is a concern/roadblock with such a configuration from the ROON team then I think the answer is simple. Just say you wont offer support for those brave enough to click the “Custom” setup option. I get that making things idiot proof has its benefits but it also has just as many pitfalls by hamstringing your more “savy” end users in what they can do with your platform. Long ago I ran away from Apple for this very reason.
Thinking of a potential Band-Aide to solve my current dilemma, can the ROON staff comment on whether or not the software will allow one to point the “Storage” configuration found within the APP to a different VLAN/Subnet via direct IP so that the NAS could live on VLAN-x and the CORE/REMOTE live on VLAN-y?
With the setup mentioned in #2 above, I could place my CORE/REMOTE together on an island by themselves (ie…a dedicated VLAN) and leave my DATA/MUSIC on a more protected VLAN. I could then hard code the NAS IP Address, living on a different VLAN, within the ROON REMOTE “Storage” configuration and from my Router I could then configure it to route the IP of the REMOTE to the other VLAN where my NAS would reside.
Since I know the next question/reply may be “Why are you using multiple VLANS” I will provide that answer here.
The answer is simple, I am using multiple VLANs for security purposes. I have some devices/systems that I have deemed not trustworthy to live among my other devices that are trusted and hold personal data. These untrusted devices (black boxes) are placed on “islands” by themselves (ie…VLANS) so that I can limit what they have access to. One such device is my Google phone where the ROON REMOTE lives. There are other devices as well but I wont get into listing them all here.
Thanks for reading and for any info/assistance you can provide
Can’t offer much help other than this observation. Sometimes a caveman like approach is what is required when you are dealing with cavemen! I happily include myself in that category!
Currently I have 2 lan connections on my ROCK that are associated with 2 vlans; this allows remotes associated with each vlan to find it but the process is slow and sometimes hangs.
Is there a reason why we can’t include a ‘static’ ip address of the Core in our controls?
It’s not on Roon to allow/disallow traffic-flow between your networks. Use your firewall instead to allow the respective traffic to flow between your networks.
As the possibility to add the Core’s IP-address is already given, it’s unlikely that Roon will change something here. If that doesn’t work for you, then there must be something else going wrong, preventing the connection between Control and Core.
So your Core has two IP-addresses then? I’m pretty sure you entered the right one in the Remote.
You’ve only uncovered a small bit of the puzzle. What you found is the brute force way Roon attempts to identify core after all other discovery methods have failed. Sending a broadcast storm onto the network is certainly “caveman” (I like that, well said).
However, even if you did forward/leak this to the other broadcast domain what you’ll find is things still don’t work. Part of the negotiation for remote is that the core actually creates a TCP socket back to remote (turning core into the client / remote into the “server”). This socket is used to push all of the configuration information of that client (services, endpoints, etc.) Roon uses a range of ports in order to do this so you’d have to open that entire range for this to work.
I’m still reverse engineering this but from what I’ve gathered so far, and in my head, the only reliable way I can determine to make this work is using NAT + some multicast relay service. I can configure my router to NAT the inside Roon IP to an outside IP on the non-local lan segment. What I’ve not gotten deep enough into my reverse engineering though is if Roon core/remote embeds it’s IP in any of the communication which would then require the NAT is “Roon aware”. This is a mess and way too time consuming. I’ve actually just put some tablets on the “Roon network” and have called it good at this point until I can get back into figuring this out.
The other suggestion I got, which is excellent, is to use Roon Extension: Roon Web Controller v1.2.0 This is a web interface into Roon requiring nothing more than the http socket to function. My limitation is extensions don’t work directly with ROCK so, again, I’ve got some work to do.
Good luck. You may just want to pluck a $100 Fire 10 off Amazon and call it good for now. There is way too much music to listen to to be distracted by this amount of work to get Roon functional across LAN segments.
I am able to confirm the presumed IP the controller should see by using the option at the bottom of the page…‘configure roon devices’ which shows the core server and it’s IP address. There can be no confusion anyway, because the controller IP is determined by membership in the Vlan (e.g. the normal lan is xxx.xxx.2.xxx and the media replaces 2 with 40. The ip addresses for the core are identical except for 2 vs 40 to make them easy to remember.
I do get access to the core from either Vlan/subnet but it does take a bit of time
Thanks IP. I do the same for the tablet that is ‘dedicated’ for Roon. But I use radio and play music in other rooms so I often use my phone, a non-dedicated tablet, or laptop as the controller and they are on the general vlan, not the ‘media’ one. Deep digging is beyond my skill set so I (and I’m sure others) appreciate you efforts. I use Untangle as my router and Unify switches so I’m forever trying to figure things out.
I don’t know if you saw my earlier comment, but I added a USB 3.0 Network Port to my NUC and ROCK immediately saw it as a second ethernet. I associated each with a different vlan using the switch and set the IP addresses as static matching each vlan. I am now able to connect to ROCK Core from either network but it takes a while to connect.
OH this is great news. I didn’t even think to try this. I’m not sure I want a “server” spanning two different networks but it’s good to know that ROCK will identify and use the second interface. This might be another good temporary solution.
My “guess”, total guess here, is the “bit of time” is core using the wrong interface, timing out, and trying again. It eventually works but that eventually may be the delay you’re seeing. To fix that ROCK would need to implement source based routing in Linux. Couple different ways to do this but ultimately the goal is to always match an ingress ethernet frame on the hardware queue back to egress queue of that same hardware. This guarantees that responses to requests are hitting the same wire as the request. Those running Core on Linux could set this up pretty easily but we’d need root access to ROCK to enable this functionality.
As @ipeverywhere has already pointed out, ROCK is the wrong OS for such a setup as it doesn’t allow access.
E.g.: With VLANs you can run as many networks as you wish over a single wire but you need OS access to configure it. My Windows PC is setup this way, connected to 3 networks at the same time, but additionally, independent on how you connect different networks physically, needed tweaking of the routing table also to work properly.
IMHO you definitely need root-access to the OS to configure a multi-homed host properly.
IP
I’m not sure what is happening, but multicast/broadcast is not supposed to cross vlans, so I’ve heard. I have also blocked lan to wlan multicasting (using unify which I think you also use) for each vlan. There is the option to identify mac addresses of servers that are allowed to broadcast over the wlan, so I have added my dhcp server and the Rock mac for the correct interface to the exception list. If things are working as they should, the wireless should only be seeing the ROCK address assigned to that vlan. It all sounds like it should work but the connection still takes time.
