When installing the latest version of plex I tried to claim it using hostname.mydomain.net. instead of the IP of the device
However, this triggers some weird bug where you reach plex, you are able to login, however afterward plex will not be able to find the server (which is really weird since I’m using the thing itself)
After pulling out all my hair and “no soup for you” messages and digging through the logs I finally found some messages relating to an unknown hostname.mydomain.net. I, therefore, concluded that it’s impossible to claim the server using its domain name
After looking up it’s IP address from my DHCP server I could connect and claim it. After claiming it everything works fine (also when using it’s domain name)
TS here, I’ve reclaimed my account as I even deleted it thinking the issue was with my account.
To me this seems as a really weird security measure. To me it’s a big assumption that when someone uses dynamic names it must be that someone’s connecting from outside the local network. I know that having my own DNS (or actually unifi) resolve hostnames instead of using IP adresses is an exotic setup. But also not that uncommon in today’s superuser crowd
Or am i missing something?
Just to clarify. My router provides the DHCP server and uses DNSmasq to resolve hostnames on the domain to local ip adresses (192.168.x.x) Everything in this setup is run locally. Is this security measure still working as intended when taking this setup into account?
If it would be remote, you would ssh tunnel into the server and then claim it. Maybe you can try that too. But why do you need to claim it over the hostname? Does it work if you use the local IP of it?
I tried claiming it through ssh, but can’t remember the issue I ran into. Maybe while i was in there I first checked the logs and came up with the solution.
As mentioned, claiming it through local IP works fine. However, the domain name in question should also resolve to a local IP.
To me, and probably others, this wasn’t clear. Is it an idea to more specifically specify that FQDN’s do not work. Even if they resolve to an unrouted IP address?
For good measure I also just tested mDNS, but this also seems to have (it’s own) issues.
What i’m also curious about is how private networks are defined in this case. If one would use a more lenient subnet mask like 255.255.0.0 or even 255.0.0.0 with proper setup at both ends, would this work?
Nonetheless, using the ip adress directly solved this issue for me. I’m just trying to help the next guy who will encounter this.
Wait a sec. Chuck, AFAIK, symbolic names are never used by a TCP/IP network stack to determine whether or not a destination address is on the local network or on a remote network. That’s the purpose of a subnet mask. After masking off the network bits from both the local address and destination address, if the values are the same, then the packet can be sent directly to the destination, else it’s sent to a network gateway. (Okay, that’s a gross oversimplification, but covers most cases, especially home users who aren’t network nerds.)
mjkl, Plex uses RFC1918 test networks as their private network definition. For that matter, if you use any IPv4 addresses outside of that range, you’re internally duplicating addresses on the public Internet, and potentially could create yourself other problems. It’s rather important that the subnet mask match on all machines on a network. Example time…
Assume that your home network is 192.168.1.0/24 (subnet mask 255.255.255.0,) and all machines on your network (with the obvious exception of your firewall,) have a single address. In light of your comment, you change the subnet mask on your Plex server to 255.0.0.0 (aka a class A address.) Your Plex host will now think it can send directly to 192.168.199.4 (as an example) as the network part of the address matches. It sends the packet out, but as a direct send. There’s nothing on your local network, and it’s not sent to your firewall for forwarding, so it silently should get ignored.
Thanks for your reply! I indeed gave to generic example. When talking about 255.0.0.0 I was thinking about a corporate size subnet on the 10.0.0.0 range (do these subnetmask actually exist in real life?)
To give a deterministic example of my case:
Let’s again asume a network of 192.168.1.0/24 where my PC is 192.168.1.2 and the server is 192.168.1.3. My router/dhcp server/dns server is located at 192.168.1.1 Also i’ve registered the domain mydomain.net for my self and configured my DNS server to resolve all *.mydomain.net to local adresses automatically (using hostnames)
AFAIK anything about TCP/IP DNS (not much more than this) if try to visit the website server.mydomain.net it will first use DNS to resolve the FQDN to an IP adress. My router is able to handle this request itself and will return 192.168.1.3. From this point on TCP/IP will handle all traffic based on this IP address. And since 192.168.1.3 is on the same subnet. the network interface should be able handle traffic directly without routing.
However, from what I get a web browser will also put the FQDN in the HTTP Get request. The only thing i can imagine from here on in is that Plex also uses the FQDN in the HTTP Get to double check how a certain request came to be. And blocks it in this case. This confuses me as in my opinion FQDN is not per definition a different network. Perfect example is mDNS. A service for resolving FQDN’s for local purposes with zero configuration.
Please do point out any errors in this post, as this is just my 2 cents and I would hate to spread any misinformation
This sounds like a confusing way to do things and very much like a bug but it’s quite deliberate.
IPv4 is broken into 3 classes:
a. Class A - 1.x.x.x → 126.x.x.x
b. Class B - 128.0.0.0 → 191.x.x.x
c. Class C - 192.x.x.x → 223.x.x.x
Class A space is used by the main internet itself, extremely large companies, and whole governments. It’s also a very convenient way of partitioning the world’s traffic.
Class B space is used by large companies. Class B space allows for 65535 directly addressible hosts from the open internet although few are ever open.
Class C space is used by smaller companies. Class C space allows for 254 directly addressible hosts.
We consumers don’t need that much addressibility. Most of us only need a single point of presence to/on the internet. How to allow us to have multiple computers, all sharing the same address became a problem. To solve this, NAT (Network Address Translation) was created. We can have multiple LAN IP addresses sharing a single public (WAN) IP without collision.
Putting it to use
NAT (Network Address Translation) - A technology which allows multiple addresses in one space to share a single address in another address space. This is what allows us to have multiple devices in our homes while having bare minimal footprint on the limited IPv4 address space.
RFC-1918 defines the blocks of the IANA inernet address space which will never be routed over the internet.
ISPs apply RFC-1918 rules to our LAN side of the modem/router. Any RFC-1918 address defined on our LAN will never be routed to the Internet.
DNS maps names to addresses.
a. DNS works by starting at the local host
b. If local host can map name to an address, it does so and uses it.
c. If not, it passes the given name string up to the next higher DNS resolver.
d. Process continues until resolved or “NXDOMAIN” (not found).
Combine RFC-1918 + DNS =>
a. Local LAN hostnames will never exist in the Internet tables
b. Private space can have a ‘private domain’ (mDNS, etc) which is 100% isolated from everything else because nothing of the local LAN is ever going out to the Internet.
How Plex uses this:
Plex.tv operates in the global Internet address space (everyone can see it and it can see everyone).
Most of our servers are private in our homes but some are public. We need a uniform way of identifying all of them.
Everything on the Internet needs to be encrypted.
Some of the things in our home don’t support encryption very well.
Combine 1 + 2 + 3 above and get — Plex.tv → Private DNS server for Plex. The 4th requirement here is handled below.
Simplify software by converting all LAN IP addresses to names – universal format.
a. Chuckpa.server.hosting.com:32400
b. TVS1282.home.lan:32400
c. Map both names into UNIQUE private domain for “ChuckPa”; creating 23f4-9975dead-beef0000.plex.direct
d. Add Encryption certificate to that private domain. (Plex creates a certificate for every individual user)
e. Entries are defined in plex.tv for: Chuckpa.9975dead-beef0000.plex.direct TVS1282.9975dead-beef0000.plex.direct
e. All of Chuck’s machines now are secured and it doesn’t matter if on LAN or remote.
f. Plex/web asks Plex.tv “What machines does Chuck have and where are they?”
g. Plex.tv sends the list above.
Where the fun happens:
Lookup the numeric address of the desired device / server
How does that address map into RFC-1918.
a. If the address is an RFC-1918 address, it’s guaranteed to be LOCAL.
b. If the address is public (which is what you get from a FQDN ← security magic occurs right here), We treat as remote regardless of actual location. (assume hostile)
From your computer to your NAS (both on the same RFC-1918 network).
a. Already know it’s private and need not be super strict.
b. Your home lan provides its own basis for security
c. Setting up a new server succeeds without special effort because we trust RFC-1918 is in control.
If the server is remote, we have no trust and therefore
a. Can’t trust who’s trying to take control of an unsecured server. (setup)
b. Who the owner is if network/equipment fault has broken the trust relationship between server and Plex.tv
c. Therefore: SSH and log into the host’s username/password (the foundation of trust)
b. Create a SSH tunnel to it for the sole purpose of operating the GUI to administer it as if it were local LAN
The result:
When plex.tv and your PMS trust each other, you authenticating with Plex.tv joins that circle.
You can now use or administer the server via local LAN or when remote via http://app.plex.tv
Ha! You’re writing this from the point of a browser connecting to PMS. I was contemplating from the PoV of PMS. My nits about 2b have nearly completely withered away.
@mjkl, Chuck addressed your HTTP Get requests neatly in 2b. There is a bit of method in their madness, among other things, that’s where (I think) they’re fighting DNS rebinding attacks. It very much simplifies their logic/code to make the assumption that an FQDN request from your browser is probably a remote network. Nobody likes to type, and a hostname only should return a local address.
Personally, I dislike mDNS. Like a lot of other things, to me, it reeks of somebody trying to solve a problem they don’t understand. I’ll get off that soapbox, that discussion does not belong here.
Chuck, thank you. May I politely suggest that your write-up should be added to the FAQs in some fashion?
Running a real DNS ( like pfSense has ) provides the necessary DNS functionality the right way. Yes, mDNS is a bandaid without knowing if you need sutures or not.
Good eye on catching the DNS rebind management. You see why it’s done this way.
