· I use my ISP's router alongside a personal router.
ARC Status
· ARC is *Ready*
Describe the issue
My iPhone will not stay connected to my Roon server away from my home network. This happens on cellular and other wifi networks. Sometimes the phone won't connect at all, other times it will play a song, maybe a few songs and then playback stops. When I check settings in ARC on my phone, I see a green cloud indicator, but a red indicator for the Roon server and the ARC connection status indicates a port forwarding problem. I use a service called 'Screens' to connect to my Mac mini Roon server when I'm away from home. Doing that, checking ARC settings in Roon, I see a 'Ready' status. I click 'Perform Connectivity Test', get 'Ready' again, and then my phone connects, but only for a handful of songs and then I have to go through the steps again.
Describe your network setup
My ISP is Verizon FIOS. I have their G3100 router and Orbi RBR50 with 1 RBS50 satellite. The Orbi system is in AP mode and wifi is turned off on the G3100. Firmware is up to date on both. RBR50 is connected with ethernet to G3100, RBS50 is wifi. The Roon server is a M4 Pro Mac mini connected to the G3100 via ethernet. The mac is running Mac OS Tahoe 26.5.
Thanks for the report. Could you please let us know the exact local time and date the next time you notice this, along with any screenshots you can share?
We’ll enable diagnostics so we can see whether the logs give us any clues. Please send that over when you have it.
1415 local time (EDT) today 6/5/26. Just switched off wifi on my phone while at home. Status was all green indicators, ‘ready’. In Roon’s ARC settings, initial display was “Testing” but with no interaction from me, that quickly flipped to ‘Ready’ and ARC is functioning.
The cell signal is weak inside my house, but I’m certain I can duplicate it outside with a stronger signal as well, happens regardless of signal strength.
Just for good measure, started playback while connected to wifi, then turned wifi off. Played through 1 track, started a second, but connection has been lost during second track at 1441 EDT 6/5/26. Playback continues on the second track (buffered data, perhaps?) but tried to perform a search and it hung. Currently seeing Cloud and Roon Server indicators spinning in ARC settings on my phone. Surprisingly, a third track has started playing while indicators are spinning. Stepped outside for a stronger cell signal.
Thanks so much for the additional information and screenshots. Based on the behavior you’ve shared, it sounds like this could be a double NAT + port forwarding timeout pattern.
Your port forwarding rule on the G3100 works, but NAT session tables have a timeout. When your phone switches from WiFi to cellular (or just sits idle), the TCP connection drops and the router forgets the mapping. Roon ARC can’t re-establish it without a fresh “knock” which is why manually triggering the connectivity test in Roon fixes it temporarily.
Let’s first check the G3100 port forwarding rule carefully
On the G3100, go to Advanced → Port Forwarding. Verify:
Protocol is TCP (not UDP, not both — Roon ARC uses TCP)
External and internal port match exactly what Roon's ARC settings page specifies (it shows you the port number)
The destination IP matches your Mac mini's reserved IP
Additionally, even in AP mode, verify the Orbi isn't doing any NAT. Log into the Orbi admin (usually 192.168.1.1 or
http://orbilogin.com
) and confirm:
Router Mode is set to AP (not Router)
DHCP is disabled on the Orbi
The Orbi has no WAN IP that looks like a private address (192.168.x.x or 10.x.x.x)
If the Orbi is still doing any routing, that could be the cause of your issues.
With that, are you able to confirm your mac running Roon Server has a static IP? If not, let’s lock down the Mac mini’s IP address
On the G3100:
Find the Mac mini's MAC address
Assign it a DHCP reservation (sometimes called "address binding" on FIOS routers)
Confirm the port forwarding rule points to that exact IP
Thanks for the follow up. I’d done some previous troubleshooting with ChatGPT and addressed some of these issues.
G3100 port forwarding - I had a manual rule set up, and I believe UPnP was also on. First I tried turning off UPnP, no change. Then (at the recommendation of ChatGPT), I completely deleted the manual rule and turned on UPnP and everything worked just fine, I got a ‘ready’ indication automatically. That’s where we are currently. Looking at port forwarding, there are 4 rules associated with the application ‘UPnP IGD’ where the protocol is TCP. One of the IP addresses is the same as the IP address in ARC settings in Roon, forwarding to the port in ARC settings. One of the IP addresses is also that of the server, but forwarding to a different port. I’m not sure what the other 2 IP addresses are. They are also forwarding to the port that is not the port in ARC settings.
Orbi settings - The router mode is AP, that much I can see. Unfortunately, I’m in over my head when it comes to a lot of networking. I can see an information pane for the LAN Port and this has the DHCP box checked as well as an 192.168.1.xxx IP address.
Roon Server IP is static and matches the IP in ARC settings and in the automatically established port forwarding rule noted above.
I think my question here is should I uncheck the DHCP box in the LAN info pane on the Orbi? Otherwise, I’m not sure what my next action is, other than to continue to wave the flag for help! Thanks!
Thank you for the detailed breakdown! Please don’t worry about being in over your head with the networking side of things—you are providing exactly the clues we need to get this sorted out, and you are doing great.
Let’s tackle your questions and get this connection stabilized.
Short answer: Leave that DHCP box checked!
Why: Because your Orbi is correctly set to Access Point (AP) mode, it is not acting as a router or handing out IP addresses to your phones and laptops. That specific DHCP checkbox just means the Orbi is asking your main Verizon G3100 for its own internal IP address so it can communicate on the network. Unchecking it won’t help ARC, and it might accidentally lock you out of the Orbi’s management page.
To make ARC rock-solid, we need to bypass UPnP specifically for Roon and lock in a permanent manual rule. Since your Mac Mini already has a static IP, you are 90% of the way there.
Please try these exact steps:
Check the Port: Go to Settings > ARC in Roon and write down the exact Port number listed there.
Clear the Clutter: Log into your Verizon G3100 router. Find those auto-generated UPnP IGD rules you mentioned. Delete the specific UPnP rule that points to your Roon Server’s IP and ARC port. (Leave the other UPnP rules alone so you don’t accidentally break your “Screens” app).
Create the Manual Rule: Set up a permanent Manual Port Forwarding rule with these parameters:
Protocol: TCP
Device/IP: Your Mac Mini’s static IP address
Original/Forwarded Port: The ARC port number you wrote down in step 1.
The Critical Reboot: Once the manual rule is saved, fully restart your Verizon G3100 router, and then restart your Mac Mini. This forces the router to dump its buggy UPnP tables and respect the new permanent rule.
Give that a try, and let us know if ARC holds a steady connection when you drop off Wi-Fi!
Thanks for the clear next steps. Unfortunately, though I can see rule that needs to be deleted, there’s no option to delete it or modify it in any way. I can add a new rule, but I can’t edit any of the 3 UPnP rules that are there. There are 3 other rules there as well, not specified as UPnP, can’t edit or delete those either. Suggestions? Turning off UPnP doesn’t seem like the way to go if that’s what Screens is using. Add the manual rule and see what happens leaving everything else as is? Or am I missing something in terms of router settings that would allow me to delete the necessary UPnP rule? Thanks for the ongoing assistance.
No worries — you cannot delete UPnP rules on the G3100, that is expected behavior on FIOS routers. UPnP rules expire automatically when the device stops renewing them, so they will clean themselves up over time.
Go ahead and add the new manual rule with the port you set in Roon ARC settings, pointing to your Mac mini’s static IP. Leave everything else as is for now. The static rule will take priority for ARC traffic, and Screens can continue using UPnP independently.
After adding the rule, test ARC on cellular and let us know if the connection holds more reliably.
Passed the first stress test. Started the ARC app on my iPhone inside my house on wifi and went out to mow the lawn. My wifi does carry outside to some extent, but the signal attenuates pretty quickly. Typically, there’s a lot of switching between cellular and wifi while I mow. Added to that, the iPhone can be stubborn to let go of the wifi signal even when the cellular signal would clearly be stronger (supposedly that’s an improvement coming in iOS 27, we’ll see).
Glad to say, no ARC issues whatsoever. Played non-stop from when I pressed shuffle on my playlist until I finished mowing.
The final test is tomorrow. I’m headed into my office for the day and I’ll be on my employer’s ‘guest’ wifi network.
