Local/Inter-VLAN Access Incorrectly Requiring Plex Remote Access Subscription

Plex Media Server
, ,
1

Hi Plex/Peeps

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?

—————————————————————————————————————

UPDATE

Just to provide a small update on this for anyone who stumbles across the thread later.

I did eventually get this resolved, although I’ll admit it was frustrating given that I was troubleshooting everything from within my own network the entire time. In my opinion it feels a bit overly restrictive for purely local scenarios, though I appreciate why things are implemented the way they are.

In my case, the issue wasn’t a single setting but a combination of how name resolution and request handling were being processed across VLANs. If you’re running a more segmented setup, it’s worth double-checking how DNS is resolving locally and how any reverse proxy or gateway in front of Plex is presenting those requests.

Once those pieces were aligned, local access started behaving correctly again.

2

Try adding your local IP networks so it’s knows what to consider local.

https://support.plex.tv/articles/200430283-network/

1 Like
3

What subnets are you using?

4

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.

1 Like
5

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.

1 Like
6

Don’t use a domain name in your local network. It is not necessary and introduces additonal complexity.

See Client says it won't play from "remote server", although the server is local for additional things to check.

7

Thanks for this Sean, I’ll have a read

8

example lets say subnet mask is 192.168.8.0/24 for ISP Home router and UDM-Pro-Max is 192.168.9.0/24

9

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.

10

@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.

11

Do you have the version number or repo I can look into to see if this might fix my issue as well?

12

@michaelvickers807

  1. PMS will not accept self-signed certificates (if you want to attach it to PMS)

  2. 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:

  1. Bookmark for my PMS server uses the hostname and adds the URL
http://glock:32400/web

  1. Browser resolves the IP with the router DNS resolver

  2. PMS sees only the expanded IP address

13

In case anyone else has their VLANs listed in the network tab, make sure you don’t include a space like I did.
Using 10.10.10.0/24, 10.10.30.0/24 still had it showing “Remote”.
Using 10.10.10.0/24,10.10.30.0/24 now shows local.

14

Thank you for the information. It took me a little while to circle back to this issue.

I found it interesting that the reverse proxy continued to work with a self-signed certificate on my main network and VLAN, but failed when accessed from the other VLAN/Gateway. That part had me scratching my head for a bit.

That said, your advice did resolve the problem. Updating the DNS resolver configuration, along with a few related tweaks, got everything working as expected.

15

Good old syntax issues :slightly_smiling_face:

Unfortunately, that wasn’t the root cause in my case. Removing the space didn’t resolve it for me, I think my setup introduced a bit more complexity than the typical VLAN configuration.

1 Like