SSH tunnel to Plex server worked for players the other day, now it won't. Why?

I need to access my Plex server from Rokus and android players at two locations. I have no desire or intention to poke a hole in my firewall for the Plex port or get the corporate Plex servers involved in any way, so I’m not going to use the Remote Access feature.

Instead I set up an SSH tunnel from location B to location A (where the server is). It’s running on an always-on machine (“the bridge”) physically connected to location B’s LAN with a command that looks like:

ssh -p [location A ssh port] -L 0.0.0.0:32400:[plex server IP on LAN A]:32400 [location A IP]

For anyone not up on their SSH, that makes [the bridge]:32400 forward all traffic from LAN B to [plex server]:32400. As far as anything on LAN B is concerned, there’s a plex server running on [the bridge]:32400.

This worked great when I first set it up the other day. The only oddity was that the players didn’t detect the server on the network automatically like they would any other server I started up here - I had to use the “manual setup” feature and add [the bridge’s IP]. I still don’t understand why. If I start a Plex server on my laptop at location B they all see it immediately. As far as they’re concerned this shouldn’t look any different. It should be completely transparent to them.

The connection went down briefly the other day as I restarted the router for unrelated reasons. When it came back up I ran the command to establish the tunnel again. It connected to location A fine, and in a web browser I can access [the bridge IP]:32400 and get the Plex web ui with no problem.

But none of the Rokus or android devices at location B can see the Plex server anymore. They all claim the server is offline, even when I tell them to retry the connection. [the bridge IP] hasn’t changed, and they all still have it configured in their manual setup. Absolutely nothing about the connection, the network setup or the Plex server has changed.

If I watch the ssh tunnel session in a terminal, I occasionally see traffic from my laptop (where I have Plex web open for the server) but I never see traffic from the IPs of the Rokus or android devices, even when I’ve just told them to refresh. They’re obviously not even trying to connect to [the bridge ip].

Plex must be monkeying around trying to “magically” do something behind the scenes instead of just a straightforward connection to the port like you would expect. I’ve noticed that when I’m testing with my laptop, if I connect to the web interface on the real Plex server and then switch and connect to the one on my laptop, I still see the real server’s libraries and settings until I explicitly switch to the laptop’s. Even though it’s my laptop’s instance of Plex I’m looking at.

Call me crazy, but when I connect to an instance of a web app I expect to be managing that instance, not logging into some weird floating umbrella app that’s trying to manage every instance of that web app I own. Anyway, I can only speculate that something like that is related to the problem.

I found similar issues in the forum (like this one) but nothing helpful. The resolution there was “an upgrade fixed it”, but that’s from 2015 and I’m running 1.21.0.3616.

This same tunnel setup would work fine with virtually any other web app. I’ve got several others running this way with absolutely no problems. But as always Plex has to do something weird and break everything…

To sum up:

  • Port 32400 isn’t being blocked by the ISP or router - or if it was it would be irrelevant. The actual connection is to my ssh port, which is not blocked and working fine.

  • There’s no problem with the tunnel or the Plex server - I can connect to the server on port 32400 through the tunnel just fine as long as I do it from a web browser.

  • Nothing has been changed on the server.

  • Nothing has been changed on the apps.

  • It worked just fine a couple days ago.

Tearing my hair out.

Edits - forum ate a bunch of my markup

Without getting in to the why’s and how’s of Plex clients’ server discovery process for now (it doesn’t involve scanning the local network for servers listening on TCP port 32400), have you tried deleting your manual connection information from the clients and re-adding it? When the clients lost connectivity to the server via the manual connection settings they may have fallen back to their normal server discovery process. Setting aside expectations that they would eventually attempt the manual connection again, reconfiguring it may force the issue.

I believe it’s because players use SSDP to detect available servers on the network.
Allow multicast on port UDP-1900 through the tunnel and it will detect the server.

That’s not a bad idea, just be aware of a couple of gotchas if you try it:

  1. Tunneling UDP over an SSH tunnel requires some additional hoop-jumping.
  2. When the server responds to the SSDP query, the contact information it provides will be for its IP address, not that of the SSH proxy.

Point two will require a route to be available on your router to reach the network the server is on. Not insurmountable, but it’s some more work on your end.

The permanent solution I was going to propose was to configure a custom server access URL on the server: Settings -> (Show Advanced) Network). This URL would look something like:
http://ip.address.of.sshproxy:port

Plex servers publish their connection information to Plex, Inc.'s servers. Normally, they just publish the local and (optionally) public IP addresses. Configuring a custom server access URL adds that to the list. When your clients log in to your account, they receive a list of servers to which your account has access. This custom URL will be among them. This of course means that you must sign your clients in to your account, and not be using them as guests.

[Edit]
Added :port to the end of the custom server access URL example.

Good point, so he would have to mask the IP

…have you tried deleting your manual connection information from the clients and re-adding it? When the clients lost connectivity to the server via the manual connection settings they may have fallen back to their normal server discovery process. Setting aside expectations that they would eventually attempt the manual connection again, reconfiguring it may force the issue.

I’ll try some more when I get off work but I’m not sure that’ll help. I totally wiped the config of the plex app on my android phone (on wifi at location B right now) and redid the setup from scratch, including the manual connection, and it still won’t connect.

The permanent solution I was going to propose was to configure a custom server access URL on the server: Settings -> (Show Advanced) Network ). This URL would look something like:
http://ip.address.of.sshproxy

Plex servers publish their connection information to Plex, Inc.'s servers. Normally, they just publish the local and (optionally) public IP addresses. Configuring a custom server access URL adds that to the list. When your clients login in to your account, they receive a list of servers to which your account has access. This custom URL will be among them. This of course means that you must sign your clients in to your account, and not be using them as guests.

That’s a good idea. Will having multiple addresses in that plex inc list for the server confuse my devices at location A? Or will they be smart enough to use the local IP only since they can reach it?

How long should it be before that custom url takes affect? I made the change, saved it, waited a few minutes, and tried the nearest Roku which still says the server is offline.

I removed the manual IP setting I’d set up in case that was confusing things, since it should be getting the IP from my Plex account now. Didn’t help.

I even completely signed out of Plex on the Roku and signed back in. It forces me to reconfigure everything when I do that, so I assumed surely it would force a fresh server list from the Plex account. And it lists all 3 of my servers (a couple of laptop servers that are rarely on and the real server I’m trying to hit) but they’re all shown as offline. Just a lot of spinning indicators from the UI as it presumably tries to continue contacting them in the background.

I actually have it working on my phone now. I’ll check the other devices later.

I tried messing with some other settings in the advanced Network settings:

  • defining the preferred network interface (even though there’s only one available in the server’s jail and only one in the list)

  • Adding ip/netmasks for both LAN A and LAN B in “LAN Networks” - 192.168.1.0/255.255.255.0,10.0.0.0/255.255.255.0 (it was blank before)

  • Adding both the ssh tunnel host from LAN B AND the normal IP from LAN A to “Custom server access urls” - before it was just the tunnel host IP and before you mentioned it it was blank.

  • Explicitly adding the :32400 port to those urls

I’m not sure if one of those things made the difference or if it just took that long for the original custom url change to make it up to Plex Inc. But after all that, signing out on my phone and signing back in brought up the server immediately.

I’ll keep an eye on it to see what happens with the other devices and whether the phone quits working. Thanks for your help!

It should happen nearly immediately. However, I did leave something out of that example URL. You may need to specify the port:
http://ip.address.of.sshproxy:32400

[Edit}
Ah, I see you already discovered this. The docs state that 32400 is used by default if the port isn’t specified. In my quick test here I found that not to be the case.

Adding the clients’ network to the LAN Networks setting will ensure that it doesn’t get treated as remote as far as bandwidth restrictions are concerned; it’s a good thing to add just for that reason. It wouldn’t have affected connectivity though.

I suspect what allowed the clients to connect was explicitly specifying the port in the custom access URL. It’s supposed to default to 32400 if one isn’t specified, but it may not have.

You’re probably right. I saw somewhere that it’ll default to the port set in your Remote Access settings, but since I have Remote Access disabled it could just be ignoring it.

Anyway, just confirmed a Roku is working now so that must have been it. A bit mystified how I got it working the first time without this config, but it feels more intentional this time so hopefully it will hold up indefinitely.

Thanks again!

No problem, glad it worked.

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