Server Version#: 1.21.4.4079
Player Version#: Same? It’s the web interface
When I first setup my Plex server (a few weeks ago now) I was following all the steps until I got to “follow the setup wizard that appears”. And it never did. I read online that you have to “be on the same network” as the Plex server for the Setup window to appear. I was. I finally found someone say that you have to browse it by IP address and it checks that the IP you used is in the same network as you are. So I changed from http://plex.internal:32400/web to 192.168.x.x:32400/web and tada! everything works.
So my question is, why? What on earth is Plex doing that the hostname/IP I use to connect to it affects whether “I’m on the same network” or not? I can only assume the purpose of “must be on the same network” is some kind of security feature, but if that is the case this seems like someone implemented the feature very poorly. Plex should be entirely capable of detecting its own IP address (barring Docker, which could be annoying, but you could manually provide the ip to that as a setting) and subnet. So why can’t it just compare my IP to that? What does hostname, which is client controlled data, have to do with determining network location?
Can anyone explain the value of this restriction and what value it provides and why using client-provided data for it isn’t purpose-defeating?
I used to think it was messed up too. It’s not.
Is it super strict and maybe too strict, possibly.
The very first thing to check , which answered the question for me, is:
Sign into host
at command line: hostname
Does it return ‘plex.internal’ ?
If it doesn’t then PMS is going to treat plex.internal (which it gets in the HTTP header) as “not me” (proxy handling).
Consider:
I have a FQDN (with cert) LAN which has a PMS host accessible via the edge.
First window shows the hostname as PMS sees itself on that machine. QNAP does not return FQDN in a hostname query
Second window shows what my browser gets after querying the LAN DNS resolver which is the FQDN.
When checking the value returned from hostname() with the string passed in the header , Do they match ?
If no, then it’s “non-local” (remote) . PMS makes the assumption that it’s being accessed from somewhere which required a FQDN to get to it. It won’t let you claim by FQDN. This behavior isn’t new. When PMS is in a remote VPS server, you’ve always needed to claim it via SSH-tunnel.
If, however, the strings match, then PMS then checks IPs. At that point it would make final validation of RFC-1918 and it would work as you are hoping it would.
Long story short?
Claim by IP address or SSH-tunnel ; This is how it’s always been.
Once claimed, it doesn’t care how you access it; IP or FQDN
Hmm, if that’s true and it’s a negative check rather than positive, then maybe sending a spoofed Host header in the setup request wouldn’t actually do anything. I didn’t actually check this, I was just making an assumption since I’ve seen similar types of (poor) checks in software in the past.
I’ll verify that spoofing an IP address in the Host header doesn’t work some time with a fresh install maybe. Thanks for the response!
