I have a NucleusOne running tailscale, and taislscale running on my iPhone. ARC can see my server and all my music. Usually, I get the low connection red flag, or it plays one song and stops, the next one appears but nothing happens. I tried two different iPhones, and two different cars so is not the car and it is not the phone. Plexamop works perfectly, for example, running on a NAS in the same network as the NucleusOne behind the same router.
Describe your network setup
All my devices are Unify, modem, Console (Roter) and switches, No firewalls no VLANS.
Thanks for reaching out. Just to confirm here, when you are on WiFi on the same network as the Nucleus, do you experience any of these issues in ARC? Or is it only when you are on cellular? What is the ISP network that the Nucleus uses and separately what ISP do your phones use? Can you please list the exact local time + date + track when you next observe such behavior? We’ll check diagnostics to see if there are any clues. Thanks!
We haven’t seen a response to this thread yet, but we’ll need the information requested in the post above to take effective action on your report.
At your convenience, please see @noris’s response above and share as much information as possible pertinent to the questions asked.
Additionally, do you have this playback issue with both streaming service (Tidal/Qobuz) content as well as your own local tracks? What about tracks you’ve downloaded to the phone locally?
I am repeating my answer from yesterday:
Hello Noris
No the problem is in my car when I am out of home. I am on T-mobile
At home I have to ISPs T-mobile and Comcast. My router uses one as Failover, being main ISP Comcast cable.
It happened last time when I was listening to a playlist “Fleetwood Mac” t played first song and stopped. Other times I just got the poor connection red banner.
I forced me to use Plexamp but ARC being the sagas Roon is my preferred choice otherwise I have to keep two libraries, playlists, etc.
PS: I do not use Qobuz/Tidal in the car.
Tailscale can introduce latency to the network connection between RoonServer and ARC because the network pathway passes through their proxy servers.
You might be better of relying on port forwarding. Comcast isn’t known to have implemented CG-NAT, so you might not need to use Tailscale to reach ARC outside your local network.
Have you tried relying on port forwarding instead of Tailscale? What do you see in Settings → ARC within Roon (this page tests port forwarding irrespective of Tailscale setup).
Thanks. well, I installed Tailscale because port forwarding some days worked some days did not. ARC is a little bit flimsy compared to Plexamp, for example, which just works. But I want to have a reliable ARC as all my music is on Roon and many playlists which I have to duplicate inside Plex to access them from the car. Taislcale was supposed to solve all problems but now it seems it does not. Asking your customers to deal with port forwarding and editing settings in routers is too much. I can do it; I worked for Cisco 7 years. I can build my own amplifiers. But it should not be that way. It should work easily. ARC is a source of frustration for a lot of people, me included. I love Roon and I will keep using. But ARC is a pain. I just re activated the port forwarding to both 55003 and 55002 and it does not work.AT least with Tailscale can connect to the Nucleusone…If you can help I will
Thank you for sharing these details — your dual-ISP setup and Tailscale configuration help clarify the behavior you’re seeing.
Please note that both Tailscale (which is based on the WireGuard protocol) and Roon ARC sessions are IP-bound. When a failover event occurs and your router switches from Comcast to T-Mobile, your public IP and routing path change. As a result, both WireGuard and ARC sessions are terminated and must be re-established — neither protocol can automatically migrate an active session to a new WAN interface without a handshake reset.
This is a fundamental property of WireGuard’s design:
Each peer stores the endpoint (IP + port) of the other side.
When the source IP changes, the existing session becomes invalid.
A new handshake must occur before traffic can flow again.
In a multi-WAN configuration, the only way to keep both ISPs “seamlessly” usable would be to implement policy-based routing or packet marking at the router level — so that packets belonging to the WireGuard/Tailscale tunnel (or to the port-forwarded ARC flow) are always forced out through the same WAN interface. Without such packet marking and routing rules, a failover event will inevitably break the encrypted tunnel and cause ARC to lose connectivity until the next handshake completes.
Even once future ARC improvements to connection recovery are in place, automatic path switching will remain impossible unless your router can consistently preserve the same egress interface for these flows.
In practice, this means:
Both WAN interfaces must have separate and verified port forwarding rules (for ARC).
Or, if you use Tailscale, the router must ensure that all WireGuard packets continue to exit through the same ISP that established the original session.
Otherwise, each time the active ISP changes, ARC will lose its session and reconnect only after the tunnel is renegotiated.
We completely understand that this behavior can be frustrating, especially with complex networks. We’re continuously improving ARC’s resilience in such topologies, but some limitations are inherent to how encrypted tunnels and IP binding work at the protocol level.
Thanks. This makes sense. Now I can try and set port forward for both WAN connections. But if I want to keep Tailscale, how can i make that the router ensure that all WireGuard packets continue to exit through the same ISP that established the original session.? Thanks in advance
I attempted to resolve this issue after reviewing your thread yesterday. Unfortunately, I was unable to find a reliable solution without involving a VPS server to handle the routing.
