Currently Roon seems tuned for just one scenario: A LAN segment connecting core, remotes and bridges.
Usage of mdns mechanisms tells me that one of the motivations is to facilitate configuration, without the user having to intervene in the set up. I like systems that just work without me having to jump through various hoops to configure them. But I also like the fredom to tweak when the automatic mechanisms do not fit a particular use case. Unfortunately, this tweaking ability does not seem provided by Roon.
Unfortunately, the way roon operates right now keeps it from working when more than one interconnected LAN form a wider network. While I would appreciate autoconfiguration to work in this scenario, I think it could be easily supported in a transitional way by opening the door for users to explicitly configure the communication endpoints each piece of software needs to interact with the other pieces of software (e.g., tell the remote where the core is, or tell the bridge where the core is…, or tell the core where an airplay device is,…)
In fact, the remote seems configurable this way.
Without knowing too much about the underlying RAAT protocol used to stream the music, I feel hesitant to say that this should be the way to enable playing music accross LANs… but it really feels it should be as simple as it is to configure a squeezebox to find its server explicitly.
If this kind of configuration where allowed, it may be able to even cover the case where devices connect to a home network via a VPN connection, which I believe has been requested in other threads.
At the moment Roon needs everything to be on the same subnet for network connections.
Now although that seems to be a very simple and straightforward requirement, I can tell you that even that seemingly simple configuration results in many strange and wonderful networking issues. Attempting to diagnose network issues at a distance is a task that can expand to consume all Support time, even when the issues have nothing or little to do with Roon.
I shiver in my boots at the thought of expanding networking configurations. Sure, I’d love to use Roon away from home and I’m looking forward to what the devs bring out in that regard. But the difficulties of supporting and diagnosing issues arising from users of varying experience or knowledge using interconnected LANS or VPNs is not something to be taken lightly.
Thanks for your answer, as it tells me I probably did not explain myself properly if I cause you to shiver in your boots.
Let me explain better (I hope).
In Roon 1.2 it is possible to cross LANs: In what cases?
At least in these cases:
It is completely possible to configure a squeezebox (or squeezelite) directly with the IP of the Core. That Core could be sitting on the other side of the universe but as long as its IP was routable, the squeezebox could contact it, and the Core could stream music to the squeezebox. In fact, for those of us with iOS or Android devices, we could install SqueezeX player software apps, and configure them to contact the Core server. When at home, those players would be seen by the core. When not at home, a VPN connection would make the portable player access our music. I believe this kind of connectivity was being requested in other threads.
For HQPlayer Roon even supports direct configuration of the HQPlayer IP address using the audio configuration interface. I have not set up any HQPlayer, but I bet it could also be sitting on the other side of the universe and, as long as its IP was routable form that of the Core, music would be streamed.
The Remote seems to also be configurable to find a Core. It first tries to find it with a series of multicast messages, but when it fails, it provides a means for the user to introduce directly an IP address. A very sensible option. In my case that seems to work properly (although I admit that something seems funny behind the scenes…)
Even Airplay servers could sit on different networks (as long as routers were configured to forward mDNS packets between those networks), where it not for what seems a defect in Roon’s implementation of the mDNS packet handling. BTW, this defect could also be easily overcome if the audio settings page allowed direct configuration of the Airplay server, as it does with the HQPlayer.
So. What I am saying is that including more ways to manually configure things will enable legit scenarios with Roon software, similar to those already enable (I am not even asking that such configuration works through a nice GUI. Configuration files are fine)
More concretely, I am asking for is a similar ability for the Roon Bridge: to be able to directly configure a bridge with the address of the Core, bypassing the more complex discovery protocols.
Nothing more, nothing less. The way I see it, it is that simple, and consistent with the cases Roon allows as shown above.
If for some reason (unpublished complexity of the underlying Roon streaming protocol) it was not possible to offer a direct configuration, what I am asking for is enough information for some of us to address the networking issue while the Roon team works on it with whatever priority the team considers adequate (I seem to remember that in another thread, somebody from the team actually said inter-networking scenarios were in the roadmap).
In fact with some of that information available, some of us could actually suggest solutions to other users with networking problems in these forums…
@brian mentioned some of the issues arising from port forwarding (one way in which a distant computer can pretend to be on the LAN) in this post.
The devs have indicated that distant access is on the roadmap and the proposed solution is unlikely to require a VPN.
Generally speaking I am in favour of user configurability but I think it is fair to say that Roon design principles put a higher value on a single robust solution rather than a wider choice of variable quality alternatives.
Accordingly my guess is that the distant access solution will be more of a railroad track than the open garden you are describing. I’m not privy to any special information here, that’s just a guess (and a hope !).
Sometimes reading how various networks misbehave reminds me of looking at my girlfriend’s cat perched atop some structure and yowling to be let down - how the hell did it get into that position ?
Edit: I’ve referred to distant access rather than the more usual remote access in order to avoid confusion with the Roon Remote nomenclature.
Thats exactly what we all, VPN folks, need. Let me specify IP adress for the endpoint, that’s all. But for now, i can control, but not get audio from PC outside the Core segment. But i CAN play music FROM different segments to the endpoint which resides in the Core segment. Sure, i use VPN between the segments without any restriction. More about that is here: No audio on Windows 8 Desktop [VPN and Private Zones].
I think, such a great software as Roon with the accent for the networked audio approach, must have such possibilities.
I know, Roon team planned to bring up some sort of remote control, without VPN, but this is, for sure, a huge work. For now, it will absolutely great if them just add to menu “Add Network Device” new option - Roon Endpoint. And give us to type the IP. System itself already working, it’s all about multicast discovery through VPN. If it will be done - I’m Rooner for life, for sure!
(Just found this post while researching a problem I’m having)
I’ll echo this request. My use case is a work network that blocks multicast for security reasons. I can connect my Raspberry Pi with Roon Bridge to the network just fine, but my Roon Core on my laptop can’t discover it. With direct IP configurability (like exists for HQPlayer, which doesn’t have native discoverability) I could manually add the Roon Bridge as an end point.
All that being said, I don’t know if the actual audio streaming also relies on multicast (to support the multi-zone playback feature), or if it is point to point. If the former, obviously there would still be an issue even after you bypass discoverability
For some reason, Android devices sometimes CAN connect to the Core in the different vpn segment. Once they connected - audio plays just fine. So, i think it’s all about the discovery process.
That’s pretty encouraging @Alexey_Levchuk, thanks for sharing your experience.
I’m playing around with UDP to TCP tunnels (on port 9003, which I believe is the Roon discovery UDP port). Progress has been iffy so far. I’m guessing the Roon client app also uses multicast to find the Roon core (both running on my laptop), so things are a bit complicated (esp. given my ancient unix networking skillage)
Alas, I only have the problem on my work network, so hard to clear too much time for it. If I find a tunnel config that works (I’m trying both socat and netcat) I’ll be sure to post.
Having a different subnet for IoT devices is something common, and will be more and more necessary in the future, because security is important nowadays.
Also, with roon ARC needing an open port from the internet, people forwarding this port to a subnet where you have sensitive data and a computer you probably use for work is huge security concern and should be avoided at all costs.
The solutions to forward packets from one subnets to another that I tried worked for some times but fails a lot of time and are even not working at all in last versions, and requires opening traffic to random ports from unsecure subnets on top of having networking skills that usual people don’t have.
The fact that it doesn’t work across different subnets seems more of a design flaw than a real requirement and it remove the possibilities to have any security whatsoever when using this product.
For sure having multicast is requiring less bandwidth when streaming to multiple devices, but the network speeds nowadays are such that the benefits are outweighted by the drawbacks.
The answers from roon on the subject are also a bit disapointing, because they repeat “it doesn’t support being on different subnets” and stop de discussion here.
Roon should support a way to connect the app on a computer to the core without having to forward that many protocols.
I will probably not renew my subscription to roon, because not being able to listen to music while I’m working makes it useless, and if I need to have something else for my computer, why keeping it.