I ran into a situation where I was using a non-routable address space, but not RFC-1918. There is a block that I use for my ISP that is reserved for carrier NAT (RFC-6598 100.64.0.0/10). This is also a non-routable space and should probably be added to the ones Plex recognizes. If not at least this post will keep anyone from wasting a day figuring it out.
Are you suggesting that if Plex notices the āInternetā is using a CGNAT range address, it should provide a warning?
Plex has added the āRelayā to make remote playback work, with limitations but at least somewhat magically, for this type of scenario. There are lots of other ways it can be approached. What did you end up doing?
Note: the Plex support doc for this is pretty good!
This range and cgnat are documented under double Nat on troubleshooting remote access
1 Like
This wasnāt causing a remote access issue. For reasons that are mostly historic now my internal home network uses 100.64.0.0/24. The Plex server was giving an unrecognized domain error when accessed via an ip address in this range and āno soup for youā resulted. When the NAS finishes syncing with itās remote counterpart Iāll re-ip to the 192.168 space and expect to see it work. I posted it more for the possible case that someone else is using an RFC-6598 address space internally.
Oh - youāve piqued my curiosity. If it wasnāt about remote access, how was the address range the source of problems?
Iām trying hard not to ask why you were using those addresses. 
That address range is not recognized as a nonroutable block like the rfc1918 ranges. There seems to be a check in the server code that will only allow local access to rfc1918 ranges. When I re-ipād it to a 192.168ā¦ address anything on that subnet could adopt it.
I owned a wisp and made extensive use of the 100.64 block for just this reason. If the client router had it on the wan almost nothing detected it as a nat. As I said for historic reasons I have an overlay network at my house that used the same space.
I was under the impression that Plex looked at its current IP address and subnet, and considered other devices on that subnet to be ālocalā.
Iām not under the impression that Plex considers all RFC-1918 space to be ālocalā, and I donāt think it does by default. When running on RFC-1918 space I have configured additional RFC-1918 subnets in Plex as LAN Networks and in ...allowed without auth.
I do see this:
- Private/LAN addresses can be specified either as a range or as an individual IP address. Public addresses can only be specified as an individual IP address (using ranges/netmasks with public addresses will fail/be ignored). Do not include spaces or tabs.
Maybe that was biting you, or a version of it?
I donāt think Plex should treat CGNAT addresses any differently from public address space. The CGNAT allocation isnāt intended for āendā networks.
Plex appears to treat the rfc6598 space as a public address and will not allow access on the subnet (found the error message in the log which was what clued me in). Strictly speaking this is incorrect behavior. rfc6598 is conceptually no different than rfc1918. It is called cgnat because that is why it was originally allocated, but it is no different in practice since they should never be routed across a public network.
Shared Address Space is distinct from RFC 1918 private address space
because it is intended for use on Service Provider networks.
However, it may be used in a manner similar to RFC 1918 private
address space on routing equipment that is able to do address
translation across router interfaces when the addresses are identical
on two different interfaces. Details are provided in the text of
this document.
Of course the chances of this affecting anyone other than me are small. I only made this post on the outside chance that it saved someone in a similar situation some time.
I agree that itās nice to post it for that reason!
I see that Plex treats 100.64.0.0/10 the same as other public addresses in the allowed without auth field, and gives the same error:
Jul 27, 2020 11:44:33.047 [0x812b73b00] ERROR - Illegal whitelist covers multiple WAN IPs
I think thatās correct behavior, in context.
Itās annoying when software makes guesses based on IP address range. Iād prefer to be able to use ranges or CIDR notation for the ...allowed without auth setting. I also understand why Plex does it.
I disagree with your premise. The motivation for RFC-6598 was to avoid collisions with RFC-1918 users. Before RFC-6598 there was a lot of CGNAT being done from 172.16/12 because it was the least-used RFC-1918 space. That was just the least painful option.
The fundamental guidance for RFC-6598 is that itās for service provider networks and CGNAT hijinks, not end users. It even warns against using it for other purposes.
Shared Address Space is IPv4 address space designated for Service
Provider use with the purpose of facilitating CGN deployment.
And:
Because CGN service requires non-overlapping address space on each
side of the home NAT and CGN, entities using Shared Address Space for
purposes other than for CGN service, as described in this document,
are likely to experience problems implementing or connecting to CGN
service at such time as they exhaust their supply of public IPv4
addresses.
So I definitely donāt think Plex should treat CGNAT/RFC-6598 space the same as RFC-1918 space.
- End users shouldnāt be using it internally.
- From the perspective of a user network (or Plex Server), CGNAT addresses are usually āexternalā anyway - most likely customers of the same ISP.
I do notice that the Plex UI, parsing, and error handling for List of IP addresses and networks that are allowed without auth is poor.
No matter what you put in that field, the UI reports Your changes have been saved.
Thatās true if itās good, bad, or āabracadabraā.
Itās also very serious about being comma separated - itās even allergic to whitespace.
This works: 192.168.0.0/16,10.0.0.0/8
But this generates an error: 10.0.0.0/8, 192.168.0.0/16
Jul 27, 2020 12:01:04.570 [0x812b73b00] ERROR - Error parsing allowedNetworks ā 192.168.0.016ā: Invalid argument
Thatās funky.
You make valid points, but protecting users from themselves is a problematic stance to take and should at least be well documented.
I will maintain that if it is not routable across the public internet it is not a public address. Strictly speaking 169.254.0.0/16 should also be valid.
These are corner cases and will affect very few users so I think this conversation is enough for anyone who searches looking for a similar problem. I donāt think the developers need to worry about edge cases like this.
I agree with you though that the parsing and error messages should be clear. The error I got in the log was:
Request came in with unrecognized domain / IP '100.64.0.10' in header Host; treating as non-local
I agree completely. I dislike that type of āclassfulā behavior. Best case, I think, is to make a safe guess, show or warn the user, and then allow them to do what they want.
I wondered if this could be edited directly in Preferences.xml. It can be, but thatās not helpful. Whatever you enter via the UI is saved in Preferences.xml anyway. Itās PMS that parses and enforces those restrictions.
Sure - weāre both using nice broad definitions of āpublic internetā and āpublic addressā. 
No animosity here - this is just an interesting topic.
I think weāre on the same page that the real issue, for āunusualā configurations, is that Plex has constraints on how you can configure it. It would be super annoying if you were using public addressing internally, for instance.
For better or worse, I think Plex divides the universe into āPrivateā (RFC-1918, localhost) and āPublicā (everything else).
I donāt think all of the other special allocations and non-public networks should also be lumped in with āPrivateā and RFC-1918.
Iām willing to agree that 169.254/16 isnāt public, and is more like RFC-1918 space. Itās fundamentally āprivateā, and also fundamentally ānot publicā. (Iām relieved that there doesnāt seem to be anybody trying to use this.)
But 100.64/12 definitely isnāt like RFC-1918. Service providers should be filtering it from ingress/egress, so itās ānot publicā. But from the perspective of an end-user network, itās almost always more like āPublicā than āPrivateā.
Since 99% of people wonāt ever assign themselves addresses from RFC-6598, the most common situation is that any CGNAT addresses they see are other ISP customers, external to them.
I appreciate that you called it āCarrier NATā, by the way.
Iāve been using the term CGNAT because thatās what Iām used to. I actually hate everything about it. āCarrier Gradeā implies that itās ābetterā in some way, and really everything about Carrier NAT is awful.
Pretty much agree with you straight down the line. As I said, corner case, just needs proper docs and move on.
As to NAT itās an expedient because IPv6 has spotty adoption and requires much more knowledge to configure correctly. Because NAT is so prevalent the unfortunate side effects have been mitigated to some extent and it does make it easier for the carriers to manage the connection and provides a little bit of extra protection for the end user if they turn off abominations like like UPnP.
Like everything else, if you know what you are doing you can make it work. If you donāt its plug and pray.
1 Like
Iāve never really understood the amount of animosity against UPnP.
If I was a (residential) service provider deploying CGNAT Iād go out of my way to enable PCP. Otherwise the calls from gamers saying āMy Xbox says āModerateāā would drive me insane.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
