Multiple NAT Port Forwarding Issue, Voip Telo Connection Between Modem & Router [See Solution]

[jb76 (John)]

Per the Roon team’s request, I am documenting my specific port forwarding issue for their review in hopes it may help others…

Own one router, Netgear X4S R7800, with the latest firmware, Version 2.4.62, an Xfinity ISP utilizing the 1.1.1.1 DNS address, with UPnP enabled. Using Roon OS on a Necleus Plus Ver. B.

Roon’s automatic connection failed to connect. After several attempts, I followed the manual instructions for setting up port forwarding to no avail as well. Proceeded to the next troubleshooting step where I discovered that multiple NAT issues may be at hand. Reviewing the error message I received here, it appears that is my problem.

If memory serves me right, I attempted to utilize UPnP with JRiver media player many years ago and ran across the same issue. And as I recollect I was told by Xfinity that I could not accomplish a successful UPnP connection using them as an ISP.

If the Roon team can review the error message I received below and tell me how it can be done, without having to deal with a foreign ISP customer service rep who does not want to deal with this issue, please share it with me. Thanks.

Roon UPnP error message is as follows:

{
“connectivity”: {“status”:“NetworkError”,“status_code”:504,“error”:“error: Error: ETIMEDOUT, response code: undefined, body: undefined connected? undefined”},
“external_ip”: {“actual_external_ip”:“98.54.222.2”,“router_external_ip”:null},
“natpmp_autoconfig”: {“server_ip”:“192.168.1.1”,“found_natpmp”:true},
“upnp_autoconfig”: {“server_ip”:“192.168.1.1”,“found_upnp”:true}
}

[jb76 (John)]

I performed a manual port forwarding rule and received a different Roon ARC error message from the one I posted initially…

{
“connectivity”: {“status”:“NetworkError”,“status_code”:504,“error”:“error: Error: ETIMEDOUT, response code: undefined, body: undefined connected? undefined”},
“external_ip”: {“actual_external_ip”:“98.54.222.2”,“router_external_ip”:null},
“natpmp_autoconfig”: {“status”:“NotFound”},
“upnp_autoconfig”: {“status”:“NotFound”}
}

[Rutherford]

Nice! It’s nice to offer help and have the other person do stuff - I appreciate you as well. I’m going to try and be more concise here, I got a little long winded up there. I spent a minute making you a pretty picture

What you’ve got:

What would be “normal” :

• Internal IP address ranges are always used by everyones routers to locate clients in their houses. There are thousands of devices with the 192.168.1.1 address out there! (good article with nicer pictures)
• External IP addresses are pretty snowflakes and there can be only one on the whole internet.
• Routers do this cool thing where they have two halves: the WAN (wide-area-network) and the LAN (local-area-network). WAN is external facing, and should have a external IP address, and LAN will have an internal address and deal with all your clients in your house via ethernet or wifi. Concise short video, sadly no schematics

I suggest simplifying your network. Once we get the Roon Core visible outside your network, and streaming the sweet sweet lossless audio, we’ll re-assemble your network piece by piece until something breaks again, then address that issue.

We want only ONE router in your house to be in control of your network. We know it’s in control when we can:

1. Log into the router to see details using admin/password credentials.
2. Router’s WAN has an external IP address (matches what you see at whatismyip.com)
3. Have access to Port Forwarding details without using archaic CLI commands (command line interface, like DOS (I’m aging myself here. Maybe you too? )
4. See a list of internal clients who have IP addresses like 192.168.1.15 and match up with what clients actually have

I suspect there is some voodoo going on somewhere in your network. Some other device is acting as a firewall: holding an External IP address hostage, and giving out everyone else an internal IP address. Then, that device is talking to another device that’s doing the same thing: double NAT (network address translation aka: router’ing). When you find a spot to put in port forwarding rules, it just drops dead at this double-NAT situation.

Hope this helps! and your sponge is not over-full!

[jb76 (John)]

@Otherford

For now, plug the Ooma into the R7800. Once we get Roon ARC working, we can start putting things back slowly to narrow down what’s breaking it

@Rutherford

I suggest simplifying your network. Once we get the Roon Core visible outside your network, and streaming the sweet sweet lossless audio, we’ll re-assemble your network piece by piece until something breaks again, then address that issue.

Okay, @Otherford it appears that connecting the modem directly to the router, via Ooma’s primary setup instruction, has solved my port forwarding issue. My Roon ARC app is showing it is “Ready.” Thanks!

Have not had a chance to give the ARC a test run, but if I have any issues in that regard I will post it in the appropriate thread. The only other concern will be if I encounter any telephone reception issues that I experienced many years ago when I first installed the phone. Hopefully, that won’t be an issue going forward so I can take advantage of Roon’s new feature.

Again, my sincerest appreciation for all of your help and input.

[Otherford]

That’s great news! Today, I get a two-fer. I helped another dude get his stuff sorted as well. I’m so happy to hear it.

So I understand:

• you changed your physical network configuration into something more like the “normal” picture above.
• it wasn’t working, and now (pretty sure) it is working. So we know the Ooma was being naughty.

Certainly mark this as solved and others with that device can get a start on their issues if Ooma is also part of their network.

Regarding Ooma, you definitely don’t want dropped calls and poor quality. It might be worth going into the Ooma settings and seeing about messing with those too. I recall you said the ATT DNS servers were causing issues and switching to 1.1.1.1 or 8.8.8.8 seemed to solve some issues. You might be able to affect those changes again inside Ooma instead of running all its DNS through the router. At least you have a separate issue to troubleshoot. Maybe Ooma has some optional ports you could forward also.

Let’s see if that ARC works! Turn off your WiFi (and WiFi calling and that fancy Xfinity stuff) and see if you can listen to your Roon!

[jb76 (John)]

Hi @Otherford

So I went back, disabled the UPnP feature in my router settings and manually entered a port forwarding rule since others have expressed that it is the more secure thing to do. Everything seems to be working fine with respect to ARC. Turned off wifi and I was able to stream an album using it on my cell phone.

The only things I noticed of concern to me were the fact that the ARC player screen did not rotate from portrait to landscape mode and there seems to be no Last.fm scrobbling going on during playback as the Roon app does on my tablet. Not sure if there is a setting I am missing on the ARC app or if I need to put in a feature request for both. The rotate screen setting is set to do so on my Google Pixel settings and I do not see the Last.fm login setting when I click on my icon.

As far as the initial telephone issues, I discovered later on that a weak battery in my cordless phone was causing a lot of dropped calls. So I am hoping maybe that was the case initially when I first set up Ooma. Will look there first before getting too technical in server settings, etc. should I start having issues again. I also set the Ooma LAN ip address as static to hopefully prevent it from changing on me.

Muchly appreciated. Cheers!