I’m experiencing an issue with the recent changes to Plex’s remote-access requirements. I understand that Plex has introduced a monthly subscription for remote access through their servers, but my setup does not use Plex’s remote servers, nor should it require a paid subscription.
My environment uses multiple VLANs/networks for isolation. My main server sits on one network, and other household members are on a separate network. To allow them to access my media library, I use a local relay/forwarding setup between networks (no external relay, no connection through Plex servers, and no WAN access involved).
Despite this being entirely local traffic within my home, Plex is now displaying a message stating that I need a subscription to access my own media “remotely.” This is unexpected and incorrect because:
All access is fully local and contained within my home network.
No Plex cloud services are being used.
Previously, this setup worked without any subscription requirement.
I do not want or need a monthly subscription simply to access content stored on my own equipment, inside my own LAN, especially when it never touches the internet.
This appears to be a misclassification of inter-VLAN connections as “remote access,” which forces a paywall on local use.
Could you/someone please clarify whether this is an intended change or if anyone else is experiencing the relay issue, and if so, why local multi-network setups are now being treated as remote connections? If not intended, can this be corrected so LAN/VLAN access does not require a subscription?
If the client access is coming through a gateway, it is considered “remote”.
A VLAN is exactly that: a way to split one LAN into several separate ones, and if one of them wants to communicate with one of the others its packets have to go through the router.
Considering the target audience for Plex (non-professional home users) it was decided not to implement any VLAN cases in the “local vs remote” detection. At least for now.
I’m running into the same issue, but without vlans. Using the IP directly in the browser works, but I usually access my server through its hostname, using chimera.local.
chimera.local now says I need a remote play pass, when it didn’t like a month ago?
And that’s on top of the latest version simply being unable to retrieve account auth, so I had to rollback my install to get it to work at all today.
Thank you for your reply. I understand there’s a lot of complexity in developing Plex to work for many different setups, but this situation is still frustrating. I imagine many users in the media-server space will run into the same issue, especially those using multiple VLANs or segmented home networks.
It might be more user-friendly if, when Remote Access is disabled, Plex would still allow access to the library as long as the traffic stays entirely local. That would avoid local setups being incorrectly treated as remote and blocked behind the subscription requirement.
@Ros3
If it helps, I do something similar—I use self-assigned SSL certificates to create easy-to-remember links instead of relying on lots of IP addresses. It’s also great for people who are less tech-savvy, since it avoids asking them to enter a bunch of numbers. I’ve never had any issues with this approach before.
PMS will not accept self-signed certificates (if you want to attach it to PMS)
Use of a FQDN forces the connection to be considered REMOTE (even if local).
I avoid the problem by registering hostnames in my DNS Resolver (my router).
This way, I can use hostnames and let the computer resolve it (transparently) to the IP address. PMS never sees a name.
example:
Bookmark for my PMS server uses the hostname and adds the URL
http://glock:32400/web
Browser resolves the IP with the router DNS resolver
