<Remember to vote for your own suggestion after you create it
Based on Support for RFC6598 there was an intentional design decision made to limit the IP subnets allowed to bypass auth. There is no visual indications in the UI of this limitation and I’ve spent days looking into it before I found the above post. First, please revise both the UI and documentation to accurately reflect the limitations of the product so it’s not misleading.
Second, I am using Tailscale to publish my Plex server to only the devices I need so it’s not on the internet, and I need support for Tailscale’s 100.64.0.0/10 network to bypass auth for my devices to connect since I’m doing auth with tailscale. What would it take to get you guys to make this simple change? Or at least allow it in the XML config and limit it in the WebUI so users who know what they are doing can effectively use the Plex server the way they need to.
Just a small correction, RFC 6598 introduced the concept of a shared IP address space, neither explicitly public nor private, but intended to be used by ISPs to help in the face of IPv4 address space exhaustion. That address space is 100.64.0.0/10 (not 100.60.0.0./10) and what Tailscale utilizes.
It would therefore be inappropriate, in my opinion, to allow them in allowlists as local IP addresses as they are not explicitly private addresses (though, as a practical matter, they are).
Tailscale itself provides a means of allowing remotely connected devices to appear as though they are local (see subnet routers).
So, you can already allow any Tailscale client device to appear as it were on your local network without modification to Plex, arguably with better security (zero trust). What would the practical benefit in allowing these ranges in Plex be?
Thanks for catching the typo in the subnet, I corrected my post.
I have a lifetime Plex Pass, I’ve been a paid subscriber for quite some time. As noted, the IPs in tailscale are, in this context, private, and since I use Tailscale for posture management and authentication, they are already in a zero trust configuration. I could just as easily use tailscale routing, or ipsec tunnels, or I could deploy Caddy in the VM and reverse proxy it out over tailscale, any other more complicated solution to bypass the arbitrary limits in the Plex server config and the problem is solved. I am just asking to fix an arbitrary and worse, undocumented, limitation in the IP filter config, so I can use the software I like enough to pay for, in the same environment I use for all my other apps.
The Plex Pass gives me hardware decoding, and several other server side features. Limiting who can use the server isn’t a Plex Pass benefit, or if it’s intended to be that then their licensing model is broken… it makes it more like M$ CALs and who wants to license software like M$?
In my opinion, it’s not an arbitrary limit. They made a conscious decision to only allow private networks (which are explicitly defined in RFC-1918, which is in no way obsoleted by RFC-6598) for what is considered to be “local” in the context of Plex Media Server.
Everything else, even “shared” address space, it not private. This was done for security reasons. Plex has no way to know you’re using Tailscale and that you trust what is not, technically speaking, a private address space. And yes, Plex does have a responsibility to protect people from themselves. It’s not inconceivable (even if it is unlikely) that TS could mis-manage routes at some point allowing access between tailnets. If you’ve allowed the whole /10 access to your server without auth, that would be a problem.
For funsies, try traceroute’ing/tracepath’ing 100.64.0.1 from an Internet-connected system on your network. Notice that it will attempt to route to it via your WAN. Now try the same thing to any RFC-1918 address (not local to your network). It will not attempt to route to it via your WAN (if your router is doing its job).
My point is that RFC-6598 doesn’t truly define a private address space. It reserves a shared address space with a specific intention. Why should Plex compromise their security posture, particularly when there’s no need? TS already provides a means by which this can be easily bypassed. There’s simply no practical need for it, in my opinion.
I agree it should be documented. Plex should add specific RFC 1918 clarifying language to the docs and ideally to Plex’s configuration screens.
Tailscale should have requested allocation of an endpoint-visible overlay block. Their use of 100.64/10 is a stretch of the purpose of RFC 6598. “Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment”.
Definitely agree. The Wikipedia article to which they link for the “without auth” note section of the referenced doc isn’t specific enough, in my opinion. It should likely link directly to the RFC-1918 document itself to make it very clear that only private IP address spaces are considered local.
I only went back and scrutinized the document @FordGuy61 posted more closely after you posted. It was only then that I noticed the document wasn’t specific enough. Maybe the Wikipedia article was changed after the article’s initial publication (I haven’t gone as far as to check for update dates).
Either way, I agree with you that Plex should update the document to specifically reference RFC-1918 (in-force, not obsolete) and explain the reasons why it was chosen. Maybe not that last part; in a way, I don’t think it requires explanation. But there are always going to be some who question the choice.
I appreciate the support for enhancing the documentation and UI experience… I was more frustrated by the time spent trying to understand the silent failure than anything else.
In the end, when you pay for someone else to write the software they get to make the decisions on how it works, and if the Plex community at large needs to be “protected” then perhaps it’s just not the right software for me. If the overwhelming opinion is a limit to RFC1918 space is the right choice then as the minority I’ll solve the problem another way. Jellyfin seems like a reasonable alternative and so far has no hidden “features”. Thanks again for the feedback from everyone who commented.
