PMS: Version 1.14.1.5488 on Ubuntu 18.04
Roku: OSv9
A while ago I installed OpenVPN on the Ubuntu server running PMS. I allow the Ubuntu unlimited access to anything on the local subnet (192.168.1.xxx). Anything to the outside world gets sent through OpenVPN’s connection.
On occasion OpenVPN’s internet connection seems to lock up and require restarting. Local connections are fine during this time. But during the time that OpenVPN’s connection is locked-up, the Roku (on the local subnet) loses the ability to find the PMS on the Ubuntu server. If I restart OpenVPN’s connection the Roku can then find the PMS.
Why do I need to have a functioning internet connection for my local Roku to stream from my local Ubuntu server?
I’ve read in other posts that you need to add the authorization through the below settings:
However, this doesn’t fix the problem.
I’ve also read in other posts that the external internet connection shouldn’t be necessary once the Roku has authorized the first time with the access code.
So I’m not sure why the external internet connection going down is hosing my local connection.
One other point: With the new Roku app version it wouldn’t play smoothly/kept buffering unless I set the Plex Roku App to “Allow Insecure Connections” => “Always”, it would NOT work if it was set to either “Never” or “On Same Network”.
Does this point to Roku / Ubuntu not seeing themselves on the same network for some reason? PMS is set to allow 192.168.1.0/255.255.255.0 without authorization. The Roku address is 192.168.1.200, so it should see itself as in the same subnet. However, evidence from this issue and the recent new Roku version debacle seem to point to some issue causing them to consider themselves not on the same network.
I think I found it. It was the OpenWRT router “Rebind Protection”
Changing the setting to:
Fixes the problem. Without the setting it shows the connection as “relayed connection”, but with the setting it shows it as “local”.
I still don’t understand why the Roku is using the external IP address rather than simply address it through it’s local address and avoid all this mess.
If Secure (encrypted) Connections are enforced, the clients must talk to the server via it’s domain name on the plex.direct domain.
They cannot simply use the IP because there is no (valid/publicly trusted) cryptographic certificate possible for a private IP. If there is no certificate, there can be no encryption.
But to be able to use the domain name, this domain name must resolve to the local/private IP address of your server. Which is what the poorly implemented ‘DNS rebinding protection’ of your router did not allow, before you created the exemption rule in its settings.
I was not familiar with how Plex is implementing the secure connection but I know that I’m able to establish a secure connection between my desktop computer and my Ubuntu server with SSH via keys that I’ve generated and placed on my server. So perhaps it isn’t possible to accomplish with official certificates, but there’s no reason why Plex can’t implement a secure connection between two parties on a private network.
OpenWRT uses dnsmasq (the same as DD-WRT apparently). The reviews about OpenWRT always indicate it is a solid choice for router firmware. I’ve been happy with their configuration for years. What evidence are you referring to when you say the DNS package it is using is ‘poorly implemented’?
