Same here will not connect iPhone 12 to Roon Core NUC i7… Unable to manually port forward either… Roon did not automatically connect to my Roon Core… Very frustrating…Can anyone else identify with me on this?
I manually configured via 192.168.X.X and 55000 and after rebooting my Core (Geekcom NUC) and my iPhone 12 it’s working perfectly… While here at home… I have not tried from the car yet but will report back my experience! It did take a bit more work to get ARC up and running but appears to be working great now. Note : I did an A/B comparison between the Roon Remote and the new ARC on my iPhone 12 and I could note hear any difference in the sound quality… THAT is a big deal for me… Great job Roon and ARC…!!!
I removed the port forwarding rule and enabled uPnP. rebooted everything (servers, clients, networking equipment) and now get the following error message:
A quick search of “metronet port forwarding” confirms from many users that MetroNet have implemented CGNAT. ARC will not work with CGNAT. Common “resolution” is to request static IP from MetroNet which takes you out of the CGNAT infra.
thanks for getting back to me about this. is there no there way to do this such as a dynamic dns service. I believe they want an extra $10 for that, it feels like a subscription for ARC
hmmm… I won’t say “no way” but let’s peel back the curtain a little bit on what happens with CGNAT, or really, double NAT.
Core: 10.1.1.1
Router IP: 198.51.100.100
In a normal port forwarding scenario you tell the router that incoming connection requests to 198.51.100.100 port 55000 should be forwarded to 10.1.1.1 port 55000. Then ARC knocks on the door of 198.51.100.100:55000 that requests lands on Core. Core responds. All is happy.
In a CGNAT or double NAT scenario you’re “real” public facing address is mapped from 198.51.100.100 to 203.0.113.200 and these mappings are dynamically built only when .100 makes a request outbound towards the Internet.
If you created the double NAT scenario then the 2nd router can take a forwarding rule 203.0.113.200:55000 → 198.51.100.100:55000 and that may work. You’re just double port forwarding to get that request to the core.
However, in a CGNAT scenario, the CG stands for Carrier Grade and this second address mapping is being done by something outside of your control. Without any control of this CGNAT layer ARC requests to connect to 203.0.13.200 port 55000. That address knows nothing about that port and rejects the request. ARC fails.
The reason a static IP works is not because of the static IP. It’s because that static IP is provisioned within the ISP to not use this CGNAT layer so the whole CGNAT issue goes away as part of obtaining a static IP.
thanks for that very detailed response. I have contacted my ISP to get a static IP provisioned.
Just a thought, with roon 2.0 needing to be connected continuously to the internet in order to operate, it seems like they can include some functionality like dynamic DNS to make ARC compatible with CGNAT. I am not sure how many people are in my situation with respect to CGNAT (is this common, especially for fiber customers, or am I an edge case?).
It’s very common with fibre connections because the world is clinging to ipv4 and there are not enough addresses available given the format of ipv4. Ultimately ipv6 will solve these problems but it requires more investment in coding so guess what, few are bothering.
I think it’s interesting that most of us domestic fibre customers have not noticed what we’re being sold is not what we previously had. It’s like getting veneered instead of solid wood!
I just got a static IP from my ISP as they were using CGNAT. roon remote is working like a charm now. thanks team roon. I wish I didn’t have to pay an extra $10 a month for the ability to use this feature (and if I did, I’d rather give the money to roon than my ISP) but I am thrilled to be able to listen from my roon core while at work. WoooHooo!