Roon ARC: “Online and ready” but cannot connect to server (iPhone 12, build 379)
Description Roon ARC reports “Online and ready” in Roon’s settings, but on the iPhone 12 the ARC app initially shows the Core as available and then drops with “cannot connect to your server” after a few seconds. Network checks indicate the port‑forwarding and Core connectivity are correct.
Environment
Core:
Platform: Roon Optimized Core Kit (ROCK)
Core IP: 192.168.2.1 (static)
Network:
Netmask: 255.255.255.0
Gateway: 192.168.2.254
DNS: 192.168.2.254
Router / ISP:
Router: KPN Box 12
LAN: 192.168.2.0/24, router IP 192.168.2.254
WAN / public IPv4: 37.251.x.x (public, not CGNAT)
Port forwarding rule:
Protocol: TCP
Internet IP: (left empty)
Internet port: 55002
Destination IP: 192.168.2.1
Destination port: 55002
Roon / ARC versions:
Roon Core: latest stable (shows ARC “online and ready” on port 55002)
Roon ARC: build 379 on iOS
Client device with issue:
Device: iPhone 12
OS: iOS 18.6.2
Connection tested on: 4G/5G (Wi‑Fi off) and home Wi‑Fi
What works / tests performed
External port test from mobile network
Using a public port checker to 37.251.x.x:55002 reports the port as open.
Internal connectivity test
From a Mac on the LAN:
nc -vz 192.168.2.1 55002 → succeeds, so the Core listens on that port and local firewall is not blocking it.
Core network config
Static IP 192.168.2.1 with gateway and DNS 192.168.2.254; matches router LAN settings.
Roon ARC settings on Core
Roon → Settings → Roon ARC shows Ready, port 55002, correct public IP, no port‑forwarding error.
Problem behaviour
On the iPhone ARC app:
ARC starts, shows the Core as available / “online and ready”.
When trying to connect, ARC spins for a few seconds.
Then visibility drops and ARC ends with: “cannot connect to your server”.
The Core’s ARC settings screen remains on “Ready”; it does not show a port‑forwarding error or change the port number.
Steps already tried
Full reboot of KPN Box 12 and Roon Core.
Verified port‑forward rule matches Roon ARC port (55002) and points to 192.168.2.1.
Confirmed no second router / double NAT, and that WAN IP is public (37.251.x.x).
On iPhone 12:
Deleted ARC, rebooted phone, reinstalled ARC.
Ensured Local Network, Background App Refresh, Mobile Data allowed.
Disabled battery optimization while testing.
Behaviour is unchanged: “online and ready”, then “cannot connect to your server”.
Request
Could you please:
Confirm whether there are any known issues with Roon ARC build 379 on iOS (iPhone 12 / iOS 18.6.2) that match this “online and ready but cannot connect” pattern.
Review the ARC logs from my Core to see where the session fails after the initial connectivity check.
Advise whether there are any additional diagnostics (e.g., specific logging levels, secondary test builds, or profile resets) that I can run to help isolate this.
Thank you in advance; from my side the port and connectivity chain appear correct, so this may help identify a client‑side ARC regression.
Describe your network setup
Below is text you can paste into that “Describe your network setup” field and adjust if needed:
ISP:
KPN (Netherlands), fiber connection
Public IPv4 address: 37.251.x.x (no carrier‑grade NAT)
Network devices and topology:
Main router/modem: KPN Box 12, IP 192.168.2.254, DHCP enabled
LAN: 192.168.2.0/24
DHCP pool: 192.168.2.1 – 192.168.2.200
Primary DNS for clients: 192.168.2.254
No second router or additional NAT device in front of or behind the Box 12.
All wired devices (including the Roon Core) are connected directly to the Box 12 or via an unmanaged switch (no VLANs, no extra routing).
Port forwarding:
On the KPN Box 12, a manual port‑forward rule is configured:
Protocol: TCP
Internet IP: (left empty, applies to current public IP)
Internet port: 55002
Destination IP: 192.168.2.1
Destination port: 55002
External port‑check tools from 4G/5G report 37.251.x.x:55002 as open.
From inside the LAN, nc -vz 192.168.2.1 55002 succeeds, so the Core is listening and reachable on that port.
Roon Core / ARC OS and devices:
Roon Core:
Platform: ROCK (Roon Optimized Core Kit)
IP: 192.168.2.1 (static)
Network settings on the Core:
IP: 192.168.2.1
Netmask: 255.255.255.0
Gateway: 192.168.2.254
DNS: 192.168.2.254
Roon ARC client with issue:
Device: iPhone 12
OS: iOS 18.6.2
Network: tested both on home Wi‑Fi and on 4G/5G (Wi‑Fi off)
Roon versions:
Roon Core: latest stable (shows ARC “Online and Ready” on port 55002).
We’ve reviewed the diagnostics from your account and can see ARC connection attempts failing with the following error:
Network is unreachable (errno = 51)
address = 37.251.x.x, port = 55002
This occurs after ARC reports Online and Ready, which indicates the Core is listening correctly but the incoming connection is failing at the network level.
To help us narrow this down, could you please:
Let us know which mobile provider you’re using when testing ARC over 4G/5G.
Test ARC locally by connecting your iPhone to the same local network as the Core (Wi-Fi on, mobile data off).
Share the exact local timestamp when you attempt the local connection and see the error.
This will allow us to correlate the behavior with diagnostics on our side.
I am using KPN for 4G/5G when testing ARC outside my home network.
Local test on Wi‑Fi
When my iPhone 12 (iOS 18.6.2) is on my home Wi‑Fi (same LAN as the Core) with mobile data off, ARC does connect and works normally.
The problem only appears when using 4G/5G outside my LAN, where ARC shows the Core as Online and Ready, then fails with “Cannot connect to your server”.
Timestamp of failing mobile test
The most recent failing 4G/5G test was today [19 Jan] at approximately [14:38] local time (CET), when I attempted to connect from ARC and saw the “Port Forwarding Issue” message.
Security software on the phone
On this iPhone I am required to run Microsoft Defender (corporate policy).
Could this app, or its network protection/VPN profile, be blocking ARC traffic when I am on 4G/5G, even though ARC works on Wi‑Fi?
Since ARC works correctly on your home Wi-Fi (same LAN) and the issue only appears when using 4G/5G, the Core itself and the port-forwarding setup are behaving as expected. This suggests the connection is being affected somewhere along the mobile network path.
Given that Microsoft Defender (with managed security / network protection features) is installed on the iPhone, that remains one possible factor, as these components can filter or reroute traffic on cellular data.
To help narrow this down, could you please try the following if possible:
Temporarily disable Microsoft Defender’s network protection / VPN components (if your policy allows), then retry ARC over 4G/5G.
Additionally, if available, please try logging into ARC on another phone over 4G/5G that does not have Microsoft Defender or any corporate security / VPN profile installed.
These two tests together will help confirm whether the behavior is related to a device-level security layer or to specific mobile network conditions.
No changes are required on the Core or router at this stage. Let us know the results and we’ll continue from there.
On the iPhone I disabled the Microsoft Defender VPN profile and turned Microsoft Defender off, as far as policy allows.
With both the VPN and Defender disabled, I tested ARC again over 4G/5G.
Result:
The cloud connection indicator turns green (“Online and ready”).
When I try to connect, ARC now fails connecting with the server with a “Port forwarding issue” message.
Test on another phone
I currently do not have access to another phone without Microsoft Defender / corporate profile to run the second 4G/5G test.
So, with both the Defender VPN and the Defender app disabled, ARC can again reach the Core well enough for the cloud status to be green, but the app now stops on a port‑forwarding error instead of the earlier “cannot connect to your server” message.
With the Defender firewall/VPN enabled, ARC briefly sees the Core as online, then drops with “cannot connect.”
With Defender disabled, ARC reports a port-forwarding error. Note that the cloud status only verifies a downstream connection between Roon’s diagnostic servers and the phone — it does not confirm the end-to-end session to the Core.
In diagnostics, we see this exact pattern from your timestamp. HTTP requests to the server are interrupted mid-request or timeout when the firewall is disabled. ARC can’t reach in the server in the older logs.
Can you please clarify what you mean by “as far as the policy allows” in your response above?
Roon relies on sustained, long-lived TCP sessions. In enterprise-style or heavily stateful network environments, these sessions can be interrupted, which will manifest as authentication or connectivity failures in ARC.
As a side note, on the KPN Box 12 it can help to disable IPv6 entirely to remove dual-stack complications.
Have you considered relying on Tailscale for NAT traversal? It would be more tolerant of other network security on the phone. It might also bypass any session tracking at the router level that is contributing here.
We’ll watch for your response and work from there. Thank you.