CGNAT Built in Test when enabling Remote Access

[rbjtech 4331]

As more and more ISP's are implementing the dreaded CGNAT due to IPv4 availability, there are more and more support requests in the forums on why their emby 'remote access' is not working.

Would it be an idea to test for CGNAT when the 'Remote Access' button is selected in emby ?

It's a simple test and then the user can simply be warned that emby will not be able to provide a remote access service on this ISP connection.   Maybe provide a link to a 3rd party tunnel solution, but advising this is not supported by emby blah blah.

For those that are unaware what CGNAT is (Carrier Grade Network Address Translation) - this is the ISP's own 'private' network in front of the 'Public' internet.   It effectively 'shares' public IP addresses with all the IP's on their private network.     Subsequently you cannot use it for 'incoming' connections - because that public IP is not exclusive or available to you, it's shared with many others behind a 'private' IP address.     There are solutions around it - but they involve a network 'tunnel' - and will be beyond a lot of the users networking knowledge and capabilities.

[hapylestat 3]

ability of emby to provide correct remote path is questionable even with CGNAT, for container setups or when emby are hosted inside NATed network but are reverse proxied by nginx or forwarded by DNAT. Ports and domains would newer match.

Edited October 12, 2023 by hapylestat

[sydlexius 245]

I would assume that unless the ISP's network is architected by morons, that a simple public IP check to see if it's in the correct CIDR range would be sufficient...maybe with a URL to point to a FAQ entry about how to deal with it (per your suggestion by use of tunnels).

[rootbeerdan 4]

If anything, having some good "how to IPv6" entries would go a long way to reducing those remote access questions because of how much simpler it is to configure, as most people are just following step by step guides anyways. In the US CGNAT is pretty rare (outside of cellular, of course), but some ISPs have been testing it out.

[pwhodges 1538]

In my experience "ordinary" people (as opposed to network engineers, of which I was once one) have hardly ever heard of IPv6 or IPv4; and even if they have, don't know if their ISP has provided them with an IPv6 address.  This is as true of my grandchildren as it is of my peers.

The extraordinarily slow adoption of IPv6 is a real shame, in my opinion.

Paul

[pachi 1]

On 10/15/2023 at 7:20 AM, rootbeerdan said:

If anything, having some good "how to IPv6" entries would go a long way to reducing those remote access questions because of how much simpler it is to configure, as most people are just following step by step guides anyways. In the US CGNAT is pretty rare (outside of cellular, of course), but some ISPs have been testing it out.

I believe starlink is using CGNAT so it may quickly become more relevant as they are growing in customers.

[Carlo 4331]

CGNAT is just one of the many issues people have with getting a server up and running on IP hosted at home.

Double NATs (user using 2 or more routers), bridged networks, proxies, reverse proxies, multi-homed networks (more common than you think), virtualized setups including VMs, containers including Docker, Podman, CRI-O, rkt, runC, LXC, LXD, containerd.

Then you have app filters, internet proxies/filters as well as all types of VPNs which also play havok with network settings.

So CGNAT is just of many things that can make setting up Emby Server difficult.

Carlo

[rbjtech 4331]

3 minutes ago, Carlo said:

CGNAT is just one of the many issues people have with getting a server up and running on IP hosted at home.

Double NATs (user using 2 or more routers), bridged networks, proxies, reverse proxies, multi-homed networks (more common than you think), virtualized setups including VMs, containers including Docker, Podman, CRI-O, rkt, runC, LXC, LXD, containerd.

Then you have app filters, internet proxies/filters as well as all types of VPNs which also play havok with network settings.

So CGNAT is just of many things that can make setting up Emby Server difficult.

Carlo

Agree to some extent, but a 'basic' ISP connection for 99% of non technical users will not have any of the above (excl an increased possibility of CGNAT) - and if they do, they are likely to know a little more about their own network as they are the ones that changed/implemented it.

The idea of this FR, is to do a very simple test to 'alert' them to the fact they are likely behind CGNAT and therefore, this is why emby does not work as advertised.

It is not to test anything else, as getting into trying to diagnose any of that is frankly not emby's responsibility - we can offer help, but as you are well aware - diagnosing any form of 'non-standard' network remotely via a forum is almost impossible. 

[Carlo 4331]

Or perhaps instead of showing/checking one type of error out of many, we could establish a tunnel via client software when possible???

Not sure Roku, could do this but I think other clients could.

[sydlexius 245]

41 minutes ago, Carlo said:

Or perhaps instead of showing/checking one type of error out of many, we could establish a tunnel via client software when possible???

Not sure Roku, could do this but I think other clients could.

The problem with that is who would broker the connection?  How would access be managed?  For me this is one of those things where it should ideally be a solution integrated into existing products like routers or NAS devices, or should be tried-and-tested solutions like ZeroTier, Tailscale, etc.  Even better is an open source solution that relies on code and libraries that undergo extensive audits.

[Carlo 4331]

That's an option, but I'm not sure it's wise to integrate specific 3rd party options into our software that have specific requirements like requiring a client vpn-like software module on the client side.

IMHO, it would be better if Emby could punch through some of these NAT like conditions itself which I think is possible. Don't get me wrong, I think any type of additional reporting or specific error messages would be a big help, but the reason for not being able to setup a remote server isn't always available, nor easy to figure out from one side of a connection.

Carlo

[Q-Droid 670]

I think the dev/release cycle is long enough without trying to add the complexity of dealing with more network connectivity layers and challenges. Adding features to proxy, punch through, bypass or even 3rd party integration with such products also requires more time and effort to insure no security holes are created as a result.

I do like the proposed idea of built-in (or plug-in) checkers. Not just for networking and CGNAT but for other common issues that people encounter in their configurations. Library and file access, permissions, locations, etc.

And one big one that I think is a missed opportunity - User account settings, access, passwords, etc. By this I mean a checker to show accounts with conflicting and/or risky settings. A basic security check with recommendations for users not familiar with security or not aware of the risks.

 

[rbjtech 4331]

All great ideas - but this FR is simply to alert the user - tested during the initial setup wizard - that they are likely running behind CGNAT and Emby Remote Access is unlikely to work 'out of the box'.

We can point them to the emby CGNAT support page at this point if they wish to investigate further.

It's just about managing the customer experience - otherwise people will naturally think emby 'doesn't work' when it is infact something 'emby' unfortunately can't do anything about.

Edited October 19, 2023 by rbjtech

[sydlexius 245]

29 minutes ago, rbjtech said:

All great ideas - but this FR is simply to alert the user - tested during the initial setup wizard - that they are likely running behind CGNAT and Emby Remote Access is unlikely to work 'out of the box'.

We can point them to the emby CGNAT support page at this point if they wish to investigate further.

It's just about managing the customer experience - otherwise people will naturally think emby 'doesn't work' when it is infact something 'emby' unfortunately can't do anything about.

IMO, something like this could start with a basic check as you suggest.  Perhaps it could show up as a yellow warning triangle next to the reported address for the "Remote (WAN) access" entry on the management page.  Clicking on that triangle would take you to a KB page that explains CGNAT, as well as perhaps links to port scan sites, etc.