It was already enabled and this was working before the last update to Roon. But, sure, I’ve toggled it off and on again with precisely the same outcome.
That was answered above but, to repeat: “My Remotes and Server are on the same subnet and I still can’t connect”
The server is running on Sequoia. Clients are on Sequoia, Tahoe, and iOS.
@alex_h An additional observation – if I restart Roon Server, I’m able to connect for a short period of time (<15 minutes) before my remotes get kicked off and return to the red dot/“Connecting…”.
Fair to say this is not an issue with network permissions as those would be enforced continuously.
Thanks for confirming that the server works for some time before the issue occurs. I’ve activated diagnostics for your account and I see that you Roon has quite a few IP addresses from several networking interfaces. Can you please confirm if you temporarily disable most and leave just one active one, does the issue still occur?
What would the number of interfaces or assigned IP addresses have to do with anything? This Mac does more than just serving Roon and disabling the interfaces is impractical – please provide real troubleshooting steps instead of just guessing at something.
As a reminder, a few weeks ago, I didn’t see any connection problems. The most obvious thing that’s changed is the Roon build.
I understand your frustration, and I want to reassure you that we’re not guessing here. The request to temporarily disable extra interfaces is a standard troubleshooting step to help us isolate whether the multiple IP addresses are contributing to the issue. From the diagnostics we reviewed, your Roon Server is reporting a significant number of network interfaces/IPs, and in some environments, this can cause connectivity issues with discovery and communication across devices.
We realize your Mac serves multiple purposes and that disabling interfaces long-term isn’t practical. The goal here is simply to test with just one active interface, even briefly, so we can either rule out or confirm this as a factor. If the issue persists with only one interface active, then we can confidently look elsewhere without ambiguity.
I’d also like to kindly ask that we keep the tone constructive; we’re on the same team here, and our intent is to help get your system stable again as quickly as possible.
Would you be able to give the single-interface test a try, even for a short period, and let us know what you observe? That result will give us a much clearer path forward.
I know you’ve already reviewed your mac firewall - have you tried completely disabling it temporarily, and rebooting your devices afterward?
With that, we’re seeing some errors that are potentially pointing to the legacy version of Roon 1.8 - do you have Roon 1.8 installed currently?
Given that not all of the interfaces are physical devices, this would be a complex undertaking.
But, I decided to take a look at the route table. Your assertion that multiple interfaces could somehow be a factor only makes sense if there are routes on different interfaces for the actual subnet where my remotes live (192.168.0.0/22).
And there were two routes for this subnet but one of them was a Tailscale subnet route. This configuration has been stable for ages and worked fine with Roon up until a recent build; however, in the spirit of troubleshooting, I turned off subnet routes in the Tailscale client on the Roon server and, now, connectivity with remotes seems to be stable.
Of course, this breaks site-to-site connectivity for other things.
What changed in Roon that this formerly functional, stable network configuration no longer works for remote connectivity? How do I fix this?
We are glad that you were able to figure the root cause out.
Recent Roon update did not have major connectivity updates so it is not likely related to it.
However, in the past we had similar threads where subnet router functionality caused caused connection issues for Roon.
In this case we do recommend you to contact TailScale support so they can advise you on how to set it up safely so it does not interfere with already running local services.
I didn’t figure out the root cause, though. I figured out a workaround.
This configuration has been stable and functional for quite awhile. Nothing else has an issue – Roon is the only thing having an issue and that is a recent change.
We are not exactly sure what is the problem root cause and in order to confirm that the problem is with early access build we do recommend you to go back to production build.
There are plenty of variables that we should conclude and narrowing it down by going to the production build is going to help.
let us know please whether it is suitable for you.
