Roon ARC Fails to Connect Remotely Despite Open Port Configuration on UniFi Gateway (ref#ROOH60)

[Ray_Lopez]

What’s happening?

· I'm having trouble with Roon ARC

What best describes your issue with ARC

· Other

How can we help?

· None of the above

Other options

· Other

Describe the issue

I’m experiencing an issue where Roon ARC is failing to connect remotely, despite the port appearing open and accessible from outside the network. My Roon Server is running on macOS 14.2.1 at the internal IP address `10.11.15.5`, with RoonServer version 2.49 (build 1525). I’ve manually configured a port forward on my UniFi UCG Max (UniFi OS v4.1.22) to forward external TCP port 55000 to the Roon Server, and UPnP is also enabled. My modem (Altice UBC1326, ISP=optimum online) is operating in Bridge Mode, so there is no double NAT involved.

To confirm connectivity, I ran a packet capture on the WAN1 interface of the UniFi gateway. The capture clearly shows that TCP connections to port 55000 from an external client successfully complete the three-way handshake and even transfer some data. For example, an external client at `` initiates a connection to `:55000`, receives a SYN-ACK from the Roon Server, acknowledges it, and begins sending data. The server also sends ACKs, confirming the connection is open. However, no application-level response is ever returned — the server does not send back an HTTP response (such as 200 OK or 401 Unauthorized), and the connection hangs without a proper close (no FIN or RST flags).

Internally, I confirmed that the Roon Server is listening on port 55000 by running `lsof`, which returned `RoonAppli TCP *:55000 (LISTEN)`. A connection test using `nc -zv 10.11.15.5 55000` from another machine on the LAN succeeded. Additionally, a `curl http://:32400` (for Plex, another service that also has forwarded ports) from an external network worked as expected, while `curl http://:55000` returned `Recv failure: Connection reset by peer`, indicating the Roon ARC endpoint is either rejecting or silently dropping the request.

In the RoonServer logs, I found repeated entries of `Warn: [mobile] /hello => ServiceUnavailable`, which I suspect may be related to the ARC service not initializing properly. Roon ARC had previously been working on this setup, and no firewall rules have changed on my end since then. I’ve also tried changing the external port to 55001 (forwarded to internal 55000) and rebooting the UniFi gateway, but the behavior remains the same. There are no VPNs active, and all devices are on the same LAN subnet or accessing externally via mobile data for testing.

There was also a unifiOS update 2 days ago, that can also be the culprit, but I also don't see any firewall rules preventing the connection, especially if the plex port is functioning.

Please let me know if there's anything else I can provide — I’m happy to send additional logs or run any diagnostics you recommend. Thanks in advance for your help.

Describe your network setup

ARC was working just fine a few days ago; I noticed that it didn't connect remotely yesterday, before the latest roon update.


Network Setup Details
Roon Server OS: macOS 14.2.1

Roon Version: RoonServer 2.49 (build 1525)

Roon Server IP: 10.11.15.5 (static DHCP reservation)

Router: UniFi UCG Max running UniFi OS v4.1.22

Modem: Altice UBC1326 (bridge mode enabled)

ISP: Optimum Online

Port Forwarding: TCP 55000 → 10.11.15.5:55000

UPnP: Enabled

VPNs: None active

Additional Hardware: No double NAT, no secondary routers

Firewall Rules: No specific deny rules applied to ARC or port 55000 and/or no rules have been changed.

Working Comparison: Plex on port 32400 is reachable externally via identical port forwarding setup

[connor]

Hi @Ray_Lopez,

Thank you for your post and for your incredibly thorough troubleshooting so far.

My honest suggestion here is to bypass port forwarding entirely and instead install Tailscale on this Mac and on the phone:

Tailscale Setup Instructions: MacOS RoonServer

This would allow for more robust proxying and NAT traversal and would be immune to router and ISP updates long-term (it’s Wireguard-based).

However, if you want to troubleshoot port forwarding instead:

There’s likely no major misconfiguration of the local network here. This is possibly a quirk of prefixing or DNS. Let’s look at three other vulnerabilities that might underpin this scenario:

1. ARC’s access to cloud services to authorize the session layer (unlikely). You can verify this by checking if ARC has cloud service connection in the ARC settings page when you’re attempting to connect to RoonServer over cellular data on the phone.
2. A possible DNS resolution issue with the cellular carrier that interrupts Roon/ARC’s discovery phase. This would be both difficult to pin down and unlikely.
3. ARC is attempting to connect over IPv6 to a static IPv4-only reservation or there are prefixing issues. Run ifconfig and see if an inet6 address is visible.

For context, the port test only pings Roon’s own servers and listens for a response on the designated port (55000) from those servers - it does not test the downstream connection to the ARC framework on the phone, nor does it test ARC’s own access to cloud services.

If you have manually configured a port forwarding rule, you can disable UPnP, so the port forwarding stack doesn’t try to negotiate and create a competing rule on RoonServer startup.

Please let me know if you have any questions. Thanks!

[Ray_Lopez]

Hello Conor,

Thank you for the response!

I have been using wireguard as a stand in and work great, and i’ve been meaning to move the entry way from a forwarded port to vpn anyway! This just expedited it lol.

Appreciate your time

Respectfully,

[noris]

Hi @Ray_Lopez ,

Glad to hear that Tailscale is working great for you! I’ll go ahead and mark this one as solved, happy listening!