Plex not honoring IP ranges for local connections without auth

Plex Media Server
1

Server Version#: 1.21.1.3766
Player Version#: 4.43.4

I just added a custom domain using nginx as a reverse proxy. I can connect to Plex from inside and outside my network through the new FQDN, but I noticed that the option “List of IP addresses and networks that are allowed without auth” doesn’t seem to be having any effect any longer when attempting to use the web UI.

For specifics on that, I have the field set to “172.26.0.0/15” so that it catches both my regular traffic and my subnet that I use when I VPN in to my network. When I turn on verbose logging, I can see clients properly being recognized via the X-Forwarded-For and X-Real-IP headers:

Dec 13, 2020 19:34:28.689 [0x7f673bfff700] VERBOSE - X-Forwarded-For: 172.27.255.183
Dec 13, 2020 19:34:28.689 [0x7f66fd7fa700] VERBOSE - * X-Forwarded-For => 172.27.255.183
Dec 13, 2020 19:34:28.689 [0x7f66fd7fa700] VERBOSE - * X-Real-IP => 172.27.255.183

However, clients such as that one are unable to access the server contents without logging in. When unauthenticated, they just get the list of Plex picks of the week, holiday therapy, etc., with no options in the hamburger menu for selecting anything on the server (just a “Your Media” button that does nothing).

Am I doing something wrong here?

2

Are there other errors in the logs?

A leading or other embedded space will cause failure

Turning VERBOSE off is usually the best way to start debugging these

3

I only turned verbose on to check to make sure it was getting the right IP info. I turned it back off immediately after.

The only errors I have in my logs are from what looks like Plex trying to read UPNP device info from my Unifi Cloud Key, for some reason:

Dec 13, 2020 22:32:30.144 [0x7f671dffb700] ERROR - SSDP: Error parsing device schema for http://172.27.100.101:8080/upnp

Other than that, I’m not getting anything at the error or warning level. I also double-checked the data in that configuration field, and there aren’t any leading or trailing spaces or other characters.

4

Unifi doesn’t use standard SSDP replies. PMS prints them in the logs – spam . ignore

IIRC, you cant mask the X-Forwarded-For attribute the way you’re thinking.

What you can do is create a virtual adapter (alias address) on the host.

By doing this, the host is natively on that net and X-Forwarded won’t matter.

I also think it’s a lot easier to do than coercing VPNs to suppress all the extra info they put into packets.

5

experiment with multiple /24 or /16 ranges. A long time ago it only worked with /24 ranges so possible it’s still not working right and uncommon masks may still break things.

6

Here’s the easy way to create a virtual adapter on Debian.
Redhat is almost identical.

7

The VPN doesn’t terminate on this host (it terminates on my pfSense host, which has routing set up to allow VPN clients to access the Plex host), and I’m not using it for testing this right now anyway (though I imagine I’d see the same results). It worked fine over my VPN in the past, though.

I’m seeing this problem testing on the same subnet, with a client directly attached to the network, so it shouldn’t be a VPN issue.

8

Thank you for that.

I also have a pfSense box.

Now I understand. Create the virtual adapter on the PMS host. It will go 100x easier.

9

No dice, unfortunately. /16s and /24s don’t seem to do anything, and even entering the exact IP address of the client without any CIDR notation doesn’t work.

10

I’m . . . not really sure what that would accomplish here. If I’m seeing the issue on a client directly attached to the same subnet, I don’t know what good a virtual adaptor would do.

11

If you’re seeing the issues with a client, in the proper subnet, have the issues… you should stop there and figure that out.

What I can offer is :

I am getting an internet upgrade on Tuesday (from DSL to Cable and switching providers).

When complete, I’m going to re-establish the IPSEC tunnel I have to another site.

While not identical to your VPN, it shares a lot of the same configuration and mapping requirements

With the tunnel up, we can access each others’ systems with no special configuration of PMS.

12

Yeah, it’s the same-subnet traffic I’m trying to figure out. I have no idea whether it works over my VPN right now (I haven’t tried), but I doubt it will until I get that sorted.

However, re-reading your first comment where you mentioned a virtual adaptor, it sounds like maybe Plex might not use X-Forwarded-For for this purpose? If that’s the case, I’m going to have to rethink what I’m doing, since the reason I’m using it is so I can send everything through port 443, which is in use with other FQDNs on the same host (and which is forwarded from my public IP address to the host Plex and nginx run on).

So, yeah, maybe Plex doesn’t do what I want it to with this. That would be unfortunate, but would explain the behavior I’m seeing.

13

The pfsense knows the ip addr on the other side for the route table (assigned to that tunnel adapter). My friend does the same for his (He uses 10.1x.x, I use 192.168.x.x)

Both of us have FQDNs on our pfsense boxes.
We only use that for the WAN -> WAN part of setting up the tunnel.

Once there, My host table and his host table fall into the route tables each pfsense sets up.

I will show you screenshots when up

This isn’t a PMS problem. This is a networking problem.

14

I did some more digging, and found this when I turned debug logging back on:

DEBUG - Request came in with unrecognized domain / IP ‘plex.my.fqdn.com’ in header Host; treating as non-local

So, I need to either find a way to configure Plex to recognize the FQDN as valid, or I need to update my nginx config to fill in a value in the Host header that it’ll recognize.

15

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.