Roon ARC unable to securely access Roon Server after modem switch (ref#UGRW80)

Network Setup

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

ARC Status

· ARC is *Not Ready*

Roon Error Code

· None of these are listed. It simply says "TIMEDOUT" or similar.

System or third-party *firewalls *or *antivirus software* can sometimes block RoonServer from reaching ARC.

·
Try adding RoonServer and its associated processes to the whitelist of any firewalls or antivirus software you have installed, including the Windows system firewall, if applicable.
[You can learn more about firewall exceptions with Roon here.](https://help.roonlabs.com/portal/en/kb/articles/firewall)

Has the status in Roon -> Settings -> ARC changed after adding exceptions in your firewalls and antivirus software for Roon?
ARC is still *Not Ready*

Don't give up yet.

· I'm stuck. I'd like to create a post to ask Roon Community for help.

Describe the issue

Switched modems, and now Roon ARC can't securely access Roon Server

Describe your network setup

Ubiquiti Dream Machine Pro with AT&T BWG320-500 Modem. System worked fine until I got the above new modem. With Ubiquity's UniFi interface, I still have the same port-forwarding port set up as before. Roon has also set ARC to that port. Don't know why ARC stopped working.

@Andrew_Stein, can you post a screenshot or copy the error message displayed in the Settings → Roon ARC tab? Also, the BWG320 is also a router, so there is a good chance you have a double NAT condition occuring between the AT&T router and the Ubiquiti router. What did you have before the AT&T router was installed?

Hi. I am away from home, but Settings/Roon ARC reported that it couldn’t securely access the Roon Server. I logged into the BGW320 and set up an entry for Roon under Custom Services, assigning it the same port range (XXXXX-XXXXX) that I had set for Roon in Ubiquiti’s port-forwarding settings. I had also set up the modem in passthrough mode. My previous modem, which worked with Roon ARC, was also an AT&T, but I forget how I had set it up. Since I configured the new modem for passthrough, could I still have a double NAT?

Should I de-activate Wi-Fi on the BGW320?

I am using my Dream Machine Pro to handle all the networking (wired and Wi-Fi) throughout the house, so I prefer to avoid using any of those features on the modem.

Thank you.

Yes, I would deactivate WiFi on the AT&T gateway at a minimum. However, to the best of my knowledge (I have an older Pace gateway, not the newer version you have), AT&T gateways cannot be tuned placed in a modem-only mode, they must retain their router mode, so dual-NAT will most likely occur for you. Placing the AT&T router in passthrough mode removes any security and firewall services it provides; your Ubiquiti router may cover that for you, but I like the security of both AT&T and my ASUS router.

One possible solution is to install the Tailscale VPN on your ARC handset and Roon server computer. This was the only method that worked for me with my AT&T/ASUS configuration, even though I was able to see ARC connecting when I was mobile. However the connection always was unreliable until I used Tailscale. No port forwarding rules are needed with Tailscale.

Hi. Turns out Wi-Fi was already deactivated on the modem. I discovered that ARC works on Wi-Fi but not on cellular data. I have no idea why.

I am getting this diagnostics data for Roon (I have altered IP addresses for security):

{
“ipv4_connectivity”: {“status”:“NetworkError”,“status_code”:504,“error”:“error: Error: ETIMEDOUT, response code: undefined, body: undefined connected? undefined”},
“external_ip”: {“actual_external_ip”:“76.aaa.bbb.ccc”,“actual_external_ipv6”:“null”,“router_external_ip”:“192.186.22.73”},
“status”: “status”: MultipleNatFound
,
“natpmp_autoconfig”: {“server_ip”:“192.173.10.2”,“found_natpmp”:true},
“upnp_autoconfig”: {“server_ip”:“192.173.10.2”,“found_upnp”:true}
}

Yes, this message confirms you have two subnets operating, one using 192.168.22 and one using 192.173.10, resulting in a double NAT’d network with causes issues with ARC. My guess is that the AT&T gateway is assigning 192.168.22 addresses and the Ubiquiti is assigning 192.173.10 addreses.

In your port forwarding rules, you need to check that both the port number ARC uses and the IP addresses are correctly assigned to the port forward rule (i.e., the AT&T gateway needs to forward the ARC port to the IP address of the Ubiquiti router (assuming it is 192.173.10.2) and the Ubiquiti needs to forward the ARC port to the IP address of your Roon server computer, assuming it is using a 192.173.10.nnn address).

I had set up a custom service in the AT&T page for Roon ARC (assigning it the same port assigned in Roon to Roon ARC). The AT&T NAT/Gaming screen, however, offers only one choice under “Needed by Device”: “passthrough.” Under the IP Passthrough screen, I had assigned Passthrough Fixed MAC address to my Ubiquiti Dream Machine’s MAC address.

I then tried taking the AT&T modem out of passthrough mode, but that didn’t work.

Then, I switched IP Passthrough to Allocation Mode of Default Server, and it worked. I have no idea why.

Thank you for your help.

1 Like

Just an aside. Not related to the issue at hand.

This ip address range is not in one of the non-routable address ranges. This means that it is possible that there are servers out in the internet at large that use these ip addresses.

This does not cause an Ip address conflict because the OP’s use of these addresses is on a local network isolated by a NAT router.

However, it does mean that if the OP ever wants to use a service (say a web site) offered by a server with one of these Ip addresses, then they will be unable to because the router managing his 192.173.10.0/24 subnet (or any other device on this subnet) will consider such an ip address to be local and either pass the connection, incorrectly, to the local network device or it will reject the request because there is no device with that ip address.

Because there are 4 billion+ different ip addresses and only 256 will suffer this issue it is highly likely that the OP will not encounter the issue. But there is a chance that they will.

As a consequence, the use of this subnet should be discouraged and the router on the OP’s network that manages this subnet should, ideally, be changed to use a subnet within one of the non-routable ip address regions that are reserved for limited cal network use.

These ranges start with:

  • 192.168 (but don’t use 192.168.22 because that is used by your other router)
  • 172.x (where x is a value between 16 and 31 inclusive)
1 Like

Thank you for the heads up. I had made up that address because I didn’t want to post the actual one in a public forum. That said, what would be the appropriate range that wouldn’t pose the problem you mentioned? Thanks for your help.

Any of the non-routable ranges that I presented above so:

Anything starting with 192.168
Anything starting with 172.16 up to 172.31
Anything starting with 10.

Since you are using a 192.168.22.0/24 subnet on your other router, I would be inclined to use something like 10.0.0.0/24 (i.e set the router address to 10.0.0.1) on the router in question so that, looking at the ip addresses, it will be blindingly obvious which subnet the device is part of.

Incidentally, any ip (v4) address an the LAN side of any router is private and can’t be used to either mount an attack on your network or to identify you so there is no need for any obfuscation. The only ip addresses that you need to hide/obfuscate are the ip addresses allocated to you by the ISP’s DHCP server which, for ip v4, is just the WAN side ip address of router that manages the WAN (internet) connection.

In your case, you have:

Internet ------------ Router 1 ---------------------- Router ------------------------------Devices
         WAN IP addr     LAN IP addr       WAN IP addr       LAN IP addr               Device IP addr
         (don't pub).   (e.g. 10.0.0.1)    (e.g. 10.0.0.2)   (e.g. 192.168.22.1)       (e.g. 192.168.22.2)

The only IP address that you need to keep private is the Router 1 WAN ip address. All of the remaining IP addresses are of no use to anyone else for any purpose whatsoever (other than understanding the way that your network is assembled and whether or not there are any faults).

2 Likes

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.