I have a Windows Server 2012 R2 running PMS 0.9.12.19. I’ve been trying to streamline my connections as I have several clients connected to me at various times over an OpenVPN connection. Double encryption of the traffic does not seem necessary.
When I disable secure connections on the server, the PI’s are unable to connect to the server at all. This includes my local PI’s which are not connecting through the VPN tunnel. Am I overlooking a setting or are the PI’s no longer allowing unsecured connections to the server?
@benjaminwolf:
I agree with @NedtheNerd that there’s nothing to configure in RasPlex to affect this.
It must be something else in your network or firewall configuration that interferes with this traffic.
My own PMS server is running with secure connections disabled on a Win7pro system, and there is no problem accessing it from any of the RPi devices used. Currently these include an RPi1B and an RPi2 in my home (same LAN as PMS), as well as a remote RPi1B in my brother’s home in another suburban of Stockholm and a remote RPi1B+ in the home of one of my nieces, in a different city.
The only clear difference between my setup and yours is that I don’t use OpenVPN (though there may of course be other differencies not mentioned in this thread).
@NedtheNerd
I’ve done a more formal test and the Pi2’s definitely cannot reach the server when Secure Connections are set to Disabled. Interestingly, some old PI Logs show connection problems with http connections several months ago. The Secure Connections were set to Preferred during this period, so I didn’t notice there was an issue.
@Dlanor
The OpenVPN is only for remote clients and there is no firewall on the server. The local PI2’s do not pass through the tunnel but still suffer from the problem. What version of PMS are you using? And have you had your Secure Connections set to Disabled for a long time? I’m wondering if perhaps PMS is just disabling Secure Connections without enabling http. If you’re using grandfathered settings, maybe you don’t suffer from this issue. Or maybe I have some corruption of this setting.
@11alastair11
Looks like the same problem. PMS is having trouble with certain clients with HTTP connections. I never had a browser problem or Roku client problems when using unencrypted connections however. Which made me think it was a Rasplex issue.
@all
Perhaps this has to do with the subnet white list? aka “List of networks that are allowed without auth”?
Mine is set to: 127.0.0.1/255.255.255.255,192.168.5.0/255.255.254.0,10.8.1.0/255.255.254.0
127.0.0.1/255.255.255.255 - local host
192.168.5.0/255.255.254.0 - local network
10.8.1.0/255.255.254.0 - OpenVPN clients
@benjaminwolf :
I’m still using PMS 0.9.12.19, as I consider all later versions to be in a beta state.
(Which is why they are not linked for auto-update by Plex Inc, even those not PlexPass exclusive.)
I’ve had secure connections disabled in PMS since shortly after they were implemented.
This setting was motivated by playback issues for high bitrate videos on RPi1 devices.
But I did have secure connections enabled for a short period (so no ‘grandfather’ settings).
As for the subnet whitelist, I have it set to forbid unauthenticated access everywhere, except on the PMS computer, using the ‘localhost’ address, so my complete whitelist string looks like this:
127.0.0.1/255.255.255.255
@dlanor
I’ve since moved to 0.9.15.0.1621-344f193 prerelease. I’ve removed my subnet whitelist except for the localhost with no results. Not sure what’s happening here. May need a new temp PMS install to test if it’s related to some corruption or bad global.
@benjaminwolf:
Your posts in this thread mention no other Plex clients than RasPlex.
Please check if the same problem applies to other Plex clients or not.
If other clients suffer from the same issue that would definitely clear RasPlex from being a suspect in this.
I also recommend that you doublecheck that your Windows system has not auto-reverted to some silly defaults for the network type choice and firewall. That has happened to me a few times, where changing some other setting had the side effect of also making Win7pro revert to defining my LAN as a “Public Network” and blocking some traffic with the auto-enabled Windows Firewall (which I don’t normally use, keeping it disabled). On a few other occasions Windows has instead reverted my network type from “Work network” to “Home network” while simultaneously reverting my workgroup name to the default “WORKGROUP”, and this has affected the ability to fileshare properly with non-Windows devices.
@dlanor
It’s on a domain network and the firewall on the server is disabled. I’ve re-confirmed this so we can discount it as an issue.
I can connect via a web browser to non-encrypted http from another computer. Local iOS and official roku clients work fine with non-encrypted connections as well. Just the PI’s are having trouble connecting to the PMS.
@benjaminwolf:
Can you please try with “Plex Home Theater” or “OpenPHT” application on a PC, so we can consider whether the problem was introduced in porting the code for RPi. OpenPHT and RasPlex share common source code for the main application, so if they behave differently then the problem is isolated to the RPi specific code portions. But if both suffer from the same problem, then the problem should relate to PMS access API usage common to both platforms.
That said, the issue must also involve something unusual in your network setup (at least as a trigger for the problem), since few others seem to have the same issue.
@dlanor
Just tried OpenPHT latest version on another machine and it lost connection as soon as I disabled secure connections. Seems this is definitely related to the software port.
@benjaminwolf said: @dlanor
Just tried OpenPHT latest version on another machine and it lost connection as soon as I disabled secure connections. Seems this is definitely related to the software port.
Disagree, both OpenPHT on two MacBooks and Rasplex on one RPi2, two RPi1 and 2 RPi0 can all connect with Secure Connections=Disabled on both of my Plex Media Servers. @dlanor has also stated that he has no problems connecting with them disabled either.
The suggestion that this is due to software ‘porting’ is ludicrous, the problem is more likely within your internal network.
@benjaminwolf said: @dlanor
Just tried OpenPHT latest version on another machine and it lost connection as soon as I disabled secure connections. Seems this is definitely related to the software port.
Actually it’s the other way around.
If you get the same problem both with the PC version of the program and with the RPi version, then the port of the program from one platform to the other can not be responsible.
The PHT coding itself, as used for both PC OpenPHT and RPi RasPlex implementations could be involved, but not as the main cause of the problem, since that should affect many more users.
I remain convinced that it must be something about your network configuration that is chiefly responsible for the problem, though it may be triggered (incorrectly) by some protocol or API usage specific to the PHT clients.
You did mention that your PMS server is on a ‘domain network’, which is not the normal usage for a home LAN, and thus one major difference between your network and those of most other Plex users. I’m not sure exactly what effect that could have, but it’s worth looking into. Other things worth double-checking are the network routing details and default gateway definitions of each device (especially if any are defined manually, rather than by DHCP).
@dlanor
The domain network is simply a network that announces it’s part of the domain. It won’t have any changes to the routing. It maybe router related but it’s odd that it’s specifically blocking OpenPHT client connections. The question is: “What’s different about the way OpenPHT initiates an http connection from the other clients?”
@NedtheNerd
I misspoke when I used the term ‘software port’. But I’m only having the problem with a single client. I should of said, ‘this is definitely related to OpenPHT’. Something about this client is different. Now I can very well have a network issue interfering. But there is something different about the way OpenPHT is making it’s HTTP connections that is triggering that condition whether it’s related to a bad or corrupt PMS installation, a virtual network, or my physical network. I’ve already confirmed that by the fact other clients are working with unsecured connections.
@ ALL
I’ll research my network setup and see if there’s anything here I can see that maybe causing the problem. I may need to just capture the different client’s traffic to the server and see what’s different. Thanks for the help so far. Hoping to get this sorted soon.
Discovered part of the problem. Turns out the Virtual router for an old version of Virtualbox 5.0.8 installed on the server was conflicting. The virtual NIC for the router may have been receiving the traffic instead of the physical NIC, which is where PMS resides. I’m not sure why unsecured packets were being routed there specifically for the OpenPHT clients as opposed other unsecured client traffic because of the debug logs.
The debug logs reported the correct physical server address, but if they were communicating with the virtual NIC, they would have both addresses. Maybe likely PMS is identifying the virtual NIC to OpenPHT for non-ssl traffic, then OpenPHT is logging the physical IP address. Perhaps the other clients fail over to alternate plex.tv supplied addresses and OpenPHT does not. If the Virtual NIC address was the first delivered in a list of addresses by Plex.tv and it did not try another, it could of caused the entire issue.
Does OpenPHT manually identified server setting override addresses delivered via plex.tv? The PI’s were using manually specified IP addresses and still could not reach the server.
