Roon iOS app loses iPhone local audio endpoint randomly (ref#6L1RRT)

What best describes your playback issue?

· My DAC, streamer, or speaker doesn't appear as a Zone in Roon

What type of Zone is affected by this problem?

· *Directly-connected Zones* are affected.

Is your device connected directly to the Roon Server via cable or over the network, or is it chained through another device (such as a streamer, Roon Bridge, or Roon Remote)?

· Connected directly to my RoonServer machine

Does the device show up at all in Roon Settings -> Audio?

· No, it does not show up there

Does the device play audio from another source when using the same connection?

· The device has no problems with another audio source

Have you checked that Roon is whitelisted in any firewalls?

· I've checked the firewall and the issue remains

Since you are using a network connection to the device, please ensure that your RoonServer is on the same subnet as the device

· My devices are on a single subnet but is not visible to Roon

Do you have a complex network setup?

· I don't have a mesh network, but I use *managed network switches*

Try to disable any additional networking interfaces on your RoonServer machine.

· Disabling network interfaces had no change in behavior

Check to make sure RoonReady mode is selected on the device.

· I've checked this and the issue remains

If the device has multiple output options, do the other options work as expected?

· Multiple output types are affected

Is the device using the latest firmware as per the manufacturer?

· Firmware is up-to-date but the issue remains

Do you have an approximate timestamp of when the issue last occurred?

· +/- Tue Jan 28 12:00:09 2025 UTC when I opened the Roon app

What are the make and model of the affected audio device(s) and the connection type?

· iPhone 11 Pro running latest iOS 18

Describe the issue

Roon iOS app randomly loses iPhone local audio endpoint

Describe your network setup

Home LAN is all Unifi gear, and the iPhone is connected to the LAN using Wireguard VPN

I just filed this through the Support questionnaire, but wanted to add some additional information so this (hopefully) doesn’t get auto-closed as ‘your configuration is not supported’.

As mentioned in the report the iPhone that is running the Roon app is connected to the LAN that has the Roon server (running on Ubuntu Linux 24.04) using Wireguard VPN. I found issue reports from other people that got closed because ‘connecting to the Roon server through VPN is not an officially supported use-case’, but I wanted to file this anyway, because I’m convinced the issue here is not the VPN itself, or at the very least should be fixable to work even despite using VPN to connect to the Roon server.

What is happening is that besides the reported issue, literally everything in the Roon app on my phone works perfectly, both when correctly connected to the LAN using my home WIFI, or when outside the house over Wireguard VPN. This includes listing and playing to any audio endpoints on my local LAN such as my Denon receiver, Apple TV, laptop, Chromecast built into my NAD AMP, etc.

The only thing that is not working correctly, is that every time I leave the Roon app on my phone unused for a while, when I get back the iPhone local audio endpoint has disappeared. This even happens when I take off my bluetooth headphones to grab a coffee at work, which will auto-pause the music, when I get back about half of the time the Roon app lost the iPhone endpoint. The solution is always the same: force-close Roon app, go to settings, which will then again have the iPhone endpoint but it is stuck at ‘enabling’, so I manually disable it then re-enable it again, and presto everything works again. I can listen to music all day long over the VPN and even transfer to other zones, but as soon as I stop using the app for a while the iPhone endpoint will be similarly lost.

Because force-closing and re-opening the app always fixes this, it appears to me the app and the Roon server are completely capable of finding each other and negotiating the iPhone local endpoint, that’s what happens when the app auto-starts after all.

The Wireguard VPN is set up to be 100% transparent to whatever is provisioned to connect to it (like this iPhone), it will get assigned a local LAN IP and can access absolutely everything on the LAN as if it is locally connected. There is no firewalling or proxying or port translation or whatever between LAN devices and Wireguard clients, and I never had a single client or server application that had any issues working through the VPN vs through the LAN. Discovering and connecting to the Roon server for example works without any issue from the iPhone over VPN, it’s just the audio endpoint that is randomly lost and can only be re-enabled after a force-close of the app.

I can imagine the Roon server is trying to be smart somewhere and incorrectly chooses a network device or subnet from the host, and that somehow trips the endpoint detection/negotiation or something like that. I would be happy to check the Roon server logs or otherwise debug what it is doing to diagnose, so if you have any instructions to do so just let me know.

Correction to what I wrote before: the Wireguard clients like my iPhone are not on the same subnet as the Roon server, all Wireguard clients are on 192.168.3.0/24 while all LAN clients are on 192.168.2.0/24. These two subnets are transparently bridged by the wireguard server though, as in traffic is free to go between these subnets without any firewall between them. This is why the iPhone Roon app via Wireguard (so on 192.168.3.0/24 subnet) has no issue finding the Roon server on 192.168.2.0/24 subnet and connecting and streaming from it (so long as the iPhone audio endpoint is still available).

Hi @Wouter_Bijlsma,
Thank you for writing in to ask us about this issue. For the use case of listening to Roon outside of your local network we recommend using the Roon ARC app. If you try that does it still have the disconnection you see when using the Roon app?

Hi @daniel,

I will try with Roon ARC and report back!

That said, I would still very much prefer to be able to use the normal Roon app via the Wireguard for two simple reasons:

  1. opening up a port on my router that can get to the Roon server on my LAN seems like a security hazard, I’m running everything over Wireguard for this exact reason: not wanting the outside world to be able to get to any service on my LAN except provisioned Wireguard clients
  2. I really like the regular Roon app and its feature set, and I was planning to use the Roon app from multiple different clients (iPhone, iPad, macOS laptop and Windows workstation) so it would be nice to just have the same thing everywhere instead of having to use Rune ARC for the iPhone.

It also seems a bit silly to have to resort to the Roon ARC solution while everything seems to already work perfectly as-is using the normal Roon app through wireguard, except for this seemingly simple issue of losing the iPhone endpoint while it can obviously work just fine, which is proven by simply force-closing the app and re-opening it.

Is it possible in Roon server to somehow ‘pin’ known endpoints so they will never disappear, and/or maybe by associating them with explicit IP’s? All my devices have static IP’s both on LAN and when on VPN, so in theory the Roon server should not have to query/detect any of them.

Roon does not support VPN.

Well actually it does ‘support’ it in some way because everything is working fine if i just quit and reopen the app. Apparently technically there is no reason it cannot work, it’s just a question of whether Roon (the company) wants to put some effort towards finding a solution for having to manually re-enable the endpoint…

Blanket statements like ‘doesn’t support VPN’ aren’t very helpful anyway because there are all kinds of different VPN solutions, and this one in particular should be completely transparent to both the server and the client.

Ok, I guess I will move my question to the Tinkering forum then…

If I’m honest it would be a little disappointing if seemingly minor issues like this are all simply bucketed under a ‘sorry, no VPN’ policy, especially considering as I said, otherwise everything is working just fine over Wireguard. I’m currently in the 14 day trial period, and this could be a showstopper for me to not continue using the service.

@daniel I tried Roon ARC and so far it seems to be working fine, I haven’t been away from my home network yet but I trust that will also work. I don’t like it as a solution though, not just because of the potential security implications of having to open and forward ports on my router, but also because the ARC app to me seems very limited compared to the normal Roon appp. It’s like a different frontend to Tidal in my case, so not much of a point using it, unlesss I’m missing something.

Roon itself isn’t designed to traverse the local network, it relies on several multicast methods of discovery for connecting to the server and for the server to see devices as an endpoint. Wireguard is a layer 2 protocol and in most setups the UDP multicasts Roon relies on for endpoints are not passed via Wireguard . It may connect randomly at first as it’s often relying on the port it was previously connecting on, but as RAATs ports are changed randomly when the server changes port it will then get no reply on either end and fail. You need to use different tunnelling than Wireguard offers for Roon to work successfully over a VPN. Even then its streaming protocol was not designed for low latency external networks so streaming can be very intermittent and suffer dropouts. It has very low tolerance for latency.

You don’t need port forwarding with ARC if you use Wireguard, if UPnP isn’t configured on your router then it can’t use it. Ignore the port configuration or port forwarding and just use VPN. Roon will report it can’t connect as it only looks over port forwarding but ARC will work and.connect.

1 Like

This is good information, thanks!

The one thing I don’t fully understand from a technology perspective, is why the Roon server needs to use multicast or other techniques to ‘detect’ local endpoints like iPhones in the first place. The phone is running the Roon app, which knows where the server is and can connect to it, so it could just inform the server directly when it attaches, and send a keepalive periodically so the server knows when to disconnect. At the very least there could be some manual ‘inform server’ option in the app, or even better a server setting that lets you declare endpoints that may roam so the server has an idea how to find them. Maybe I’m oversimplifying things here but it seems a bit weird an advanced system like Roon has this kind of limitation for something this trivial.

As for streaming latency etc over Wireguard VPN, I did not experience any kind of issues using the Roon app away from home once manually forcing the iPhone endpoint to be enabled. The experience is identical to running it inside my LAN without VPN. Of course I can imagine things like grouping or syncing zones could be so latency-sensitive that you only want to run them over local LAN, but that’s hardly relevant when using VPN when away from home.

It uses Multicast like all applications do for auto discovery. Any UPnP application, Airplay or Chromecast all rely on Multicast traffic for auto discovery of end points.

As I said it might work in ideal conditions, but its not designed to have a large buffer so if you internet gets high latency Roon will drop out. Again its just not supported outside of local LAN. If you run in to issues its up to you as they wont support it.

I understand multicast is used to discover endpoints that are not running the Roon app, but like I said, an iPhone endpoint does not need to be ‘detected’ at all once you are running Roon software on it that can just inform the server.

Multicast discovery like UPnP is required for devices your server can only talk to using standard protocols you don’t control, like Roon wanting to find Airplay or Chromecast devices and such. An iPhone running Roon software isn’t like that, it can use whatever protocol Roon can come up with to talk to the server and vice versa. Discovery using multicast can still be useful for initial setup e.g. to find the server so you don’t have to enter the IP manually, but after that there is no reason why the Roon app on the iPhone could not just tell the server it is there and what it’s IP is.

Anyway I don’t have any knowledge about how Roon works exactly, and understand things are never as simple as I describe them, and there are probably reasons Roon works like this that I’m not aware of. Just pointing out that statements of the form ‘it cannot work’, ‘it is not supported’, ‘it has to use X or Y’ are also simplifications. If Roon really wanted to improve how it’s software worked when using it over VPN, there are technical solutions for it.

I’m now using the ARC app and it works fine, except that it is lacking in features and has a more limited and less convenieny UI compared to the normal Roon app, which IMO is a bit disappointing.

It doesnt work like that for audio devices in Roon. Server discovers the audio devices not the other way around if one cant see it it wont show up, App connects to server using different protocol for remote use. mDNS is used for remote to discover ad connect to server as a remote only. All RAAT devices use UDP using random port allocation this is from the server to discover them, it sends out keep alive messages all the time and if fails to get one back it wont see audio device.

I’m kind of doubting it actually works exactly like you say it does, because as far as I know iPhones do not respond to uPNP or mDNS or whatever, you cannot detect them over the network, only via Bluetooth or if you make a Wifi hotspot. iPhones and iPads also don’t show up as AirPlay devices for example. AppleTV and macOS use bonjour for this, which is probably what Roon uses to find them. The iPhone endpoint only seems to show up in Roon once you open the application, in fact you can sometimes see in the UI it says ‘Select audio zone’ for a few seconds before the iPhone endpoint appears. Maybe the app starts some service that responds to multicast packets itself when it starts, so Roon will find it, but in theory if it can do that, it could also just inform the server directly as it already knows the IP. That it doesn’t do this is just a design choice not a technical impossibility.

Bonjour uses mDNS and this has nothing to do with the iphone, this is about Roon server discovering Roonremotes app when its running, It obviously wont work if the apps closed. UPnP I am referring to UPNP/ DNLA when using the phone as a controller or endpoint which uses SDP.

Yes so we are basically saying the exact same thing, except that you are describing how it works, and I’m describing how it could in theory be made to also work when discovery is not possible e.g. because multicast cannot be bridged to some VPN tunnel etc.

Anyway appreciate your feedback, let’s just conclude that sadly this isn’t something that works unless you use a silly workaround (force closing the app and reopening)…