Roon ARC streaming issue (Poor Connection) with Tailscale on 5G despite double green (ref#7PP8AR)

MCMXC · May 3, 2026, 1:09am

Hi! What’s not quite right with Roon?

· Can’t reach my Server, remotes or ARC

Can’t connect to my Server, remotes or ARC

· Other ARC issues

Tell us what's going on

· I'm sorry to be reaching out over this but I can't dig into whats going on myself to work it out.

Roon ROCK with tailscale. iPhone 17 with tailscale. Bot hhconnected working well, appear in Tailscale web UI. iOS can ping roon no worries. Roon works flawlesly at home and at home on Arc.

On 5G full cell reception (600+mbps speed tests) arc connects (double green lights - cloud and roon server)) no worries - loads new albums, playlist changes artwork - but wont stream anything not pre-dowenloaded - "poor connection"

I have deleted and redownloaded arc, tried subnet routing rather than the tailscale on Roon ROCKL (which needs version an update btw).

No success

I wish I could get in and manipuilate the IP its trying to use to access Roon via tailscale - or troubleshoot further but alas

what can I do to help you guys work out what my issue is?

Tell us about your home network

· 1Gb fiber - public IP (dont want to expose a port). No ISP router just a UniFi Fiber Gateway. Use tailscale for streaming media from home on other apps - works flawlessly throughout - not an issue.

MCMXC · May 3, 2026, 7:22am

Hard to illustrate further but this paints the picture

The poor connection warning on non downloaded song.
The server status as all green
Ping to the Roon server at home (over Tailscale and 5G) clearly accessible
The 5G speed test - no worries.

In case you guys can audit any logs

17:17pm here is 3am on 05/03/26 in New York

connor · May 4, 2026, 6:50pm

Hi @MCMXC,

Thank you for your report. We’ve taken a look at ARC logs to try to pinpoint what’s going on.

It’s normal to experience some latency in the Tailscale connection, but consistent failures from the ARC framework despite a clean connection on the phone points to a probable routing problem between ROCK and ARC. Logs seem to corroborate that almost nothing is getting through: we see basic HTTP requests failing alongside the timeouts for track playback.

Some of these requests are passing through the ROCK’s publicly routable IPv6 address instead of the Tailscale interface. If ARC is still attempting to communicate with your server via an IPv6 address that hasn’t been pinholed, the Unifi firewall will be filtering out and blocking this traffic.

We’d like to request a quick test before we escalate this to Devs:

In UniFi, go to Settings → Networks → your LAN, find the IPv6 settings, and set the IPv6 Interface Type to Disabled.
Restart ROCK. Turn on Tailscale on the phone.
Open Roon → Settings → Roon ARC and see if you can stream any tracks on cellular data with Tailscale connected
Test playback on 5G.

Let us know if this changes any of the behavior you’re seeing. Thank you!

A brief note concerning the Tailscale version in RoonOS: the team reviews each Tailscale release and updates as necessary to retain parity with essential features. The most recent Tailscale release did not affect RoonOS; you can disregard the update notification.

MCMXC · May 5, 2026, 5:32am

@connor thank you for time taken to look at this for me and in consideration of my speciifc setup!

Very glad you mention IPv6. I had already turned IPv6 off during those test I sent you (I was concerned about it causing issues!) but it was in use previously so that expalins what you were seeing.

To confirm - Roon currently has no IPv6 address

Confirm IPv6 completely disabled on LAN.
Reboot Roon, reboot router, reboot iPhone.
Confirm no IPv6 address given to Roon
Off wifi → onto 5G and Tailscale and then fire up Roon Arc

Lets me know what else I might be able to try!
thank you agin for the help

benjamin · May 11, 2026, 10:03pm

Hi @MCMXC,

Thanks for the update! From the looks of it, in your 3rd image, you’re pinging 10.0.0.41 which is a private LAN IP, not a Tailscale IP (which would be 100.x.x.x).

This means ARC is routing through your LAN address rather than the Tailscale tunnel when you’re on 5G. That traffic can’t reach your home network from outside, which is exactly why streaming fails while the control handshake (which goes via cloud) still shows green.

Can you check your Tailscale IP for the server On the Tailscale admin console or the app? Then ping that address from your iPhone on 5G — does it respond?

Thank you!

MCMXC · May 12, 2026, 2:01am

Copy that

Confirmed can ping the tailscale address of the Roon server but roon arc wil not connect via 5G.

reinstalled the rock softwear and reboot - still receiving the poor connection message - though connected and all loading.

vadim · May 15, 2026, 1:54pm

Hello @MCMXC

It is great news that the ping to the Tailscale IP (100.x.x.x) is responding correctly while you are on 5G. This confirms that the tunnel itself is up and the basic routing is functional.

The fact that metadata (artwork/lists) loads but streaming fails with a “Poor Connection” error suggests that the low-bandwidth control traffic is getting through, but the high-bandwidth audio stream is being choked or blocked.

To isolate this further, we’d like you to try one specific test:

If possible, please connect your iPhone to a different Wi-Fi network (like at a friend’s house or a coffee shop) and keep Tailscale active.

Does Roon ARC stream correctly in this scenario?
If it works on external Wi-Fi but fails on 5G, we can narrow the culprit down to your mobile carrier’s handling of the connection.

Tailscale is built on the WireGuard protocol, which relies entirely on UDP traffic.

While pings (ICMP) and metadata sync (HTTP) are very lightweight, streaming high-quality audio generates a continuous, heavy stream of UDP packets.
Some mobile carriers are aggressive with their “Traffic Management” policies. When they detect a heavy, sustained UDP stream, they may identify it as potential “garbage” traffic or a security risk and throttle it severely. This would trigger the “Poor Connection” warning in ARC even if your raw 5G speed tests look amazing.

Perform the External Wi-Fi test mentioned above and let us know the results.
Check Tailscale “Derp” Status: In your Tailscale app or admin console, check if your connection is “Direct” or “Relayed” (DERP) when you are on 5G. A relayed connection through a DERP node can significantly limit bandwidth and increase latency, which often breaks ARC streaming.

We’re looking forward to hearing if a different network environment changes the behavior!

MCMXC · July 19, 2026, 12:43pm

Network Setup

· I use a single personal router not provided by my ISP

ARC Status

· ARC is *Ready*

Describe the issue

Roon ARC streaming issue (Poor Connection) with Tailscale on 5G despite double green, No DERP. Album artwork, tracks, all load - [re-opening of (ref#7PP8AR) ]

Describe your network setup

Mobile: Telstra 5G no throttling good connection and speed
Home: Superloop NBN 500mbps fiber to premises
UniFi fiber gateway
Roon ROCK VM on ProxMox based NAS Server (intel Xenon with 10GB NIC)
All apps and servers current version

MCMXC · July 19, 2026, 1:04pm

Have done extensive testing since last discussion on your recommendation

You last reply (ref#7PP8AR)

If possible, please connect your iPhone to a different Wi-Fi network (like at a friend’s house or a coffee shop) and keep Tailscale active.

Does Roon ARC stream correctly in this scenario?

If it works on external Wi-Fi but fails on 5G, we can narrow the culprit down to your mobile carrier’s handling of the connection.

Tailscale is built on the WireGuard protocol, which relies entirely on UDP traffic.

While pings (ICMP) and metadata sync (HTTP) are very lightweight, streaming high-quality audio generates a continuous, heavy stream of UDP packets.

Some mobile carriers are aggressive with their “Traffic Management” policies. When they detect a heavy, sustained UDP stream, they may identify it as potential “garbage” traffic or a security risk and throttle it severely. This would trigger the “Poor Connection” warning in ARC even if your raw 5G speed tests look amazing.

Perform the External Wi-Fi test mentioned above and let us know the results.

Check Tailscale “Derp” Status: In your Tailscale app or admin console, check if your connection is “Direct” or “Relayed” (DERP) when you are on 5G. A relayed connection through a DERP node can significantly limit bandwidth and increase latency, which often breaks ARC streaming.

On Wifi network other than my home

This works but not reliably. Some tracks will stream and others will not. Same error poor connection. This is indistinguishable from my 5G issues. Albums, artwork, tracks all load and are browsable but spin and won’t play then the error.
Tailscale DERP

Tailscale show direct connection from my iPhone to Roon. No DERP relay present. Both on WiFi and on 5G
Throttling

I feared this was possibly the cause. I moved from a budget re-seller carrier to the expensive national carrier. I have been assured I have no throttling and access to the 5G stand alone network. (The very best available in Australia)

Further to this I have no issues streaming HD movies via Jellyfin on 5G over Tailscale on this mobile carrier and from the same server. This is far higher bit-rate and load and works flawlessly.

I am currently using arc daily and reliant upon offline downloads which work well but would love to revolve the issue.

You will be able to see a number of test around 22:20 19/July (GMT+10) in my logs.

I am reasonably technical and happy to get into the weeds to help diagnose and fix the issue.

benjamin · July 21, 2026, 7:25pm

Hey @MCMXC,

Thanks for the incredibly thorough testing, that detail about Jellyfin streaming flawlessly over the same Tailscale tunnel and carrier is the most useful data point here. It tells us the tunnel itself is healthy and high-bandwidth, so we can likely set aside carrier throttling and DERP as causes.

The pattern you’re describing, metadata and some tracks playing, others stalling with the same error, and it happening on external WiFi too, most often points to an MTU/packet-fragmentation issue on the WireGuard tunnel rather than the network itself. A couple of targeted tests would help us confirm:

From a computer on your tailnet (tethered to 5G), run ping -M do -s 1400 <server-tailscale-IP> and step the size down (1200, 1000, 800). Let us know the largest size that gets a reply.
In Roon → Settings → Roon ARC, drop streaming quality to a fixed lower bitrate and test again, does it play reliably at low quality?
In that same ARC settings screen, confirm the address ARC reports for the connection (we want to make sure it's the 100.x Tailscale address).

Appreciate you getting into the weeds on this. 👍

MCMXC · July 22, 2026, 2:46am

Howdy @Benjamin,

Thanks for playing along, I feel we are getting somewhere too. Here’s what I found on each:

1. MTU probe — Ran the DF-set ping test from a device tethered to 5G, stepping down in size. Found a clean, repeatable cutoff:

Reply from 100.71.104.42: bytes=1252 … Lost = 0 (0% loss)
Pinging … with 1255 bytes of data: Packet needs to be fragmented but DF set. … Lost = 4 (100% loss)

So the tunnel is hard-capping at exactly 1280 bytes total (1252 payload + 28 header) — that’s Tailscale’s documented default MTU. Anything over that gets an explicit “needs fragmentation, DF set” rejection rather than a timeout. I’ve got the full ping sequence (1400 down to 800 in steps) on Pastebin if useful: [link]

2. Low bitrate test — Switched to “Bandwidth Optimised” for cellular and retested. Unfortunately this did not resolve it — still getting the “poor connection” error on tracks that previously stalled.

3. Confirming ARC’s connection address — I can’t actually find where ARC surfaces the IP/address it’s connecting to in the settings page. Could you point me to where that’s shown? That would be great information

Let me know what you make of it and what else would help narrow it down.

Thanks again,
-H

Claude’s 2 cents

MSS clamping. Rather than relying on Roon to respect the MTU, you clamp the TCP Maximum Segment Size on the tunnel interface itself, so every TCP connection through it automatically negotiates a safe segment size before it ever tries to send an oversized packet. This is the standard fix for exactly this class of WireGuard/VPN MTU problem — nothing Roon-specific needed. The iptables rule looks like:
iptables -t mangle -A FORWARD -o tailscale0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

This however is not possible given the official locked-down ROCK appliance image.

benjamin · July 23, 2026, 6:08pm

Hey @MCMXC,

Genuinely impressive probe work, that’s a textbook DF-set MTU sweep. Here’s the thing though: I think it’s steered us onto a red herring, and I want to save you from chasing MSS clamping (good instinct, but it won’t move the needle here).

Why the MTU result is expected rather than a fault:

1280 is Tailscale's normal, documented default MTU, a clean cutoff there is a healthy tunnel, not a broken one.
Your Jellyfin data is the tell: it's moving sustained high-bandwidth traffic over the exact same tunnel and carrier without issue. Whatever is choking ARC, it isn't the tunnel's ability to carry a heavy stream.
Your DF ping only tested ICMP. ARC's audio rides TCP, and because your server is a Tailscale node itself, its TCP connections automatically size their segments to the 1280 tailscale0 MTU, they never emit the oversized packets your ping was rejecting. That's also why MSS clamping wouldn't help: the --clamp-mss-to-pmtu rule acts on forwarded traffic (a subnet-router scenario), not on connections the server originates and terminates itself. So the ROCK image limitation is moot here, you're not missing anything.
And your low-bitrate test agrees: if this were bandwidth or packet size, "Bandwidth Optimised" would have improved it.

So let's pivot from the tunnel to what's actually different about ARC. A few data points would help a lot:

When tracks fail, is it the same tracks every time, or random? If you can, grab 2–3 that reliably fail and 2–3 that reliably work, and note for each: source (local library file vs Qobuz/Tidal), and format/sample rate (e.g. 16/44 FLAC vs 24/192 or DSD).
Do the failing tracks never start, or start and stall mid-track?
Timestamps: tell us the exact local time you hit play on a couple of failing tracks in a fresh test, so we can line the server-side ARC logs up precisely.

On where ARC surfaces the address, fair question, and the honest answer is it doesn't expose it cleanly. The one place to look is server-side: on a Roon remote or desktop, Settings → Roon ARC → diagnostics, which shows a copyable status blob. Heads up though: that report reflects the public port-forward test (your WAN IP), so with Tailscale and the port set to 0 it'll read "not ready" and won't reflect the tunnel path, that's expected. Paste it here anyway; it confirms Roon's detected addresses and that port-forwarding is properly disabled. Pinning down the exact address the audio socket uses over the tunnel really needs a packet capture, which the locked ROCK image makes tough, so let's lean on the per-track pattern above instead.

MCMXC · July 27, 2026, 12:55am

@benjamin

Okay I need a little bit of time to get into this (testing between sites, 5G and non-home WiFi). Making a playlist of the files and will record times for log interrogation.

I only use local file streaming. Tidal (which I am not using currently) works flawlessly. All examples previously and going forward are all local files. There is no inbetween. The songs play quickly without buffering or a fails - long pause with the spinner over the play icon followed by the “Poor connection” error box.

My Roon Arc setting on Roon appear like this - no diagnostics to speak of, that box is empty.

benjamin · July 29, 2026, 5:35pm

Thanks @MCMXC!

Thank you for confirming this. We’ll be monitoring for your reply!

MCMXC · July 31, 2026, 9:32am

Hey @Benjamin,

Some data, though I want to be upfront that it’s not a clean, settled pattern.

I built a 9-track test playlist (mixed FLAC/MP3, listed at the bottom) and ran it twice:

30 July 2026, 15:38 AEST (New York time: 30 July 2026, 01:38 EDT), on external WiFi (at work): all 9 tracks played flawlessly.
31 July 2026, 19:23 AEST (New York time: 31 July 2026, 05:23 EDT), on 5G: all 9 tracks failed.
Server time isnt my local time - trying to help - is it NY time?

That looks like a clean WiFi-works/5G-fails split, but I want to flag two things before you put any weight on it:

It hasn’t reproduced. Earlier in my testing (before I built this specific playlist) I had a mixed pattern — some tracks worked on 5G, and some didn’t work on WiFi. That doesn’t match the mixed picture before.
Track selection. I deliberately picked these 9 tracks because they were a mix of big and little files and none of them had been played in the last month, on the theory that a recently-played track might be cached somewhere (server or client side) and behave differently to a “cold” one.

Happy to keep running more rounds across both network types to see if the split holds up, or if there’s a more targeted test you’d suggest given the above after log interogation.

Test tracks used:

Inner City — Big Fun (Octave One Remix) [MP3 192kbps]
Soul II Soul / Caron Wheeler — Back to Life [MP3 160kbps]
Gui Boratto — Azzurra [MP3 320kbps]
Gui Boratto — Alcazar [FLAC 44kHz/16-bit]
Ian Pooley / Högni — 1983 [FLAC 44kHz/16-bit]
SNK — '95 Massive Giga Mix [FLAC 44kHz/16-bit]
Stefan Vincent — 8AM on the Train to Work You Ask Me to Send You Something That Makes Me Happy (For Maarten) [FLAC 44kHz/16-bit]
Kaskade — 4 AM (Djuma Soundsystem Dub Mix) [FLAC 44kHz/16-bit]
Benjamin Damage — 010x [MP3 320kbps]

Thanks,
-H

noris · August 3, 2026, 10:11pm

Hey @MCMXC,

Thanks for sharing those results. It is interesting that the pattern is there, but you also noted that some tracks had worked earlier, so we do not want to overstate it yet.

Looking through the logging, it appears that transcoding is happening on the Roon Server when things are working. Since it is working on WiFi, that points to something on 5G blocking transcoding. Please do try the WiFi versus 5G comparison a bit more so we can confirm whether that is the factor.

Are you able to set a custom DNS on your ARC device and, if needed, on your home router as well? Updating those DNS settings may help improve connectivity. Also, if you’re able to test using a Tailscale exit node (Tailscale installed on another PC on the home network), that may change the behavior. Please let us know what you find.

MCMXC · August 6, 2026, 4:00am

@noris

Oh man,I haven’t even considered DNS.

And ofcourse I run a weird DNS set up with self hosted Technetium. I can get into that if needed

However

Using an exit node - sorted all 5G streaming immediately. What does that mean, why would using the exit node help?

My guess is your going to say DNS haha

Just tested the same songs again - all working (6th/Aug/26 2 1:57 GMT+10)
Even ran it a second time with original quality - flawless

benjamin · August 13, 2026, 6:12pm

Hey @MCMXC,

That is excellent news to hear!

Traffic to Tailscale addresses (100.x) still goes phone-to-server directly; the exit node only captures everything else. So when you enabled it, the same audio stream went through the same 5G WireGuard path that had been failing, and it worked. That means bandwidth, carrier throttling, the 1280 MTU and NAT traversal are all off the table. Good news, given how much testing you put into them.

What the exit node did change is DNS, and which internet path your phone uses for everything that isn’t Tailscale traffic. So the fault has to be in there, which is where your Technetium setup comes in.

The pattern fits: browsing, artwork and playlist changes all come from your Roon Server by IP over the tunnel and need no name lookup, which is why they always worked. Starting a stream is the part that needed something resolved, and a long spinner followed by “Poor Connection” looks much more like a resolver timing out than like a starved stream, a bandwidth problem stalls mid-track rather than refusing to start.

My guess is your tailnet DNS points at Technetium, and on 5G in split-tunnel mode those queries either never reach it (if it’s on a LAN address like 10.0.0.x and nothing is advertising that subnet as a Tailscale route) or they come back with answers that only work inside your house.

Could you check, with the exit node turned back off:

In the Tailscale admin console under DNS, what are your global nameservers, is “Override local DNS” enabled, and is MagicDNS on? And is Technetium’s address a 100.x Tailscale address or a plain LAN address?
Temporarily set the global nameserver to 1.1.1.1 with “Override local DNS” on, then run the same 9-track playlist on 5G. If it plays, we’ve found it.
Then set it back to Technetium and confirm it breaks again.

If that confirms DNS, the permanent fix is to make Technetium reachable from outside the LAN, either install Tailscale directly on the Technetium host so it has its own 100.x address, or advertise your LAN subnet as a Tailscale route from a node at home. Either way you’d no longer need the exit node, though leaving it on is a perfectly reasonable setup if you prefer.

Thank you, and we’re happy to hear you’ve able to get some steady listening in no matter!