Jump to content
Not connected, Your IP: 52.14.240.178
robzeta

ANSWERED Help with setting up external access Plex server

Recommended Posts

Posted ... (edited)

Hello,
I cant manage to access my Plex server with VPN, port 8084 is ready for use in client area:

Client area:
image.png.d6e610b7cf4f8958b39b0ad0b6922f68.png
Plex settings:
image.thumb.png.89690e759732fd1cabeae0ed8c3f8a9a.png

Router settings:
image.png.5458b527853627c6835726a5413d9977.png


Please help a noob how to forward properly :) What values should I change on the 3 locations? Im running the plex server aswell as the vpn connection on my Synology Nas
 

Edited ... by robzeta

Share this post


Link to post

no need to do anything on your router so remove what you did there for security.  your image of plex remote access settings shows that remote access is working.  if you click the "test open" button what happens?

Share this post


Link to post
2 hours ago, go558a83nk said:

no need to do anything on your router so remove what you did there for security.  your image of plex remote access settings shows that remote access is working.  if you click the "test open" button what happens?


I removed the settings on router now, thanks. Plex only shows fully connected until you browse another page in the plexsettings, after that I get "Not available outside your network". When i try "test open" button I get "Connection refused (111)" 

I read somewhere that you need to set a external port on Plex in the in the 20,000 to 50,000 range, tried with port 39196 that I have available in client area but same problem. Should I try to request another port?

Portforward for rTorrent etc working, problem is just with Plex.

image.png.8524cb8e9bbb1c772e3716312c171c64.png
image.thumb.png.55d692575ac207ecb76de78203140855.png

 

Share this post


Link to post
@robzeta

Hello!

Port 39196 reserved to your account is UDP only, so failure on TCP is expected. If Plex needs TCP as well please act accordingly on your account port panel. Furthermore, port 39196 is forwarded to your VPN IP address port 32400, so Plex will never receive any packet on port 39196. This explains also the connection refused error on port 39196 (a test which our port tester runs anyway): your system receives packets on port 32400 and correctly resets the connection. Adjust this setting too.

Kind regards
 

Share this post


Link to post
3 hours ago, Staff said:
@robzeta

Hello!

Port 39196 reserved to your account is UDP only, so failure on TCP is expected. If Plex needs TCP as well please act accordingly on your account port panel. Furthermore, port 39196 is forwarded to your VPN IP address port 32400, so Plex will never receive any packet on port 39196. This explains also the connection refused error on port 39196 (a test which our port tester runs anyway): your system receives packets on port 32400 and correctly resets the connection. Adjust this setting too.

Kind regards
 

I don't know what you're seeing regarding TCP and UDP for the port forward, but it's testing both TCP and UDP according to the images.  Also, plex always listens at 32400 but an external port of 39196 mapped to 32400 internal is probably what the user has setup and that should work.  That's why you must instruct plex that the external port opened is 39196 and not the default 32400.

Share this post


Link to post
1 hour ago, go558a83nk said:

I don't know what you're seeing regarding TCP and UDP for the port forward, but it's testing both TCP and UDP according to the images.  Also, plex always listens at 32400 but an external port of 39196 mapped to 32400 internal is probably what the user has setup and that should work.  That's why you must instruct plex that the external port opened is 39196 and not the default 32400.

Hello!

Yes, as we wrote (and you couldn't know, but now you know) @robzeta had forwarded, on the AirVPN port panel, remote port 39196 to local port 32400. Therefore Plex, which was configured to listen to public port 39196, could never receive packets. Also (and you couldn't know it as well) the forwarding was active only for UDP (note that the port tester performs a test only in TCP and correctly returned error 111 as expected). Now, @robzeta has deleted port 39196 altogether, so let's wait for the new tests.

Another clarification, this time for us: in the Plex documentation here https://support.plex.tv/articles/200289506-remote-access/ we read:

 

Quote

 

Prerequisites

Before proceeding:

  1. Ensure your Plex Media Server is signed in to your Plex account (Remote Access requires signing in)

 


Therefore we guess that the Media Server refuses to listen if you don't have an account or you did not sign this account in to some other service managed by Plex Inc.? Can you confirm?

Kind regards
 

Share this post


Link to post

Think I finally made it work now with another custom port, have full access now externally and port responding open :) Can’t really tell what’s the reason it suddenly working, thanks for your help anyway.

Share this post


Link to post
1 hour ago, Staff said:

Hello!

Yes, as we wrote (and you couldn't know, but now you know) @robzeta had forwarded, on the AirVPN port panel, remote port 39196 to local port 32400. Therefore Plex, which was configured to listen to public port 39196, could never receive packets. Also (and you couldn't know it as well) the forwarding was active only for UDP (note that the port tester performs a test only in TCP and correctly returned error 111 as expected). Now, @robzeta has deleted port 39196 altogether, so let's wait for the new tests.

Another clarification, this time for us: in the Plex documentation here https://support.plex.tv/articles/200289506-remote-access/ we read:

 


Therefore we guess that the Media Server refuses to listen if you don't have an account or you did not sign this account in to some other service managed by Plex Inc.? Can you confirm?

Kind regards
 

Maybe being signed in is the problem. I can assure you that remote port 39196 and local port 32400 is perfectly fine.  Plex always listens at 32400 on localhost/LAN, but typically we cannot reserve 32400 with the AirVPN system.  So we create the rule with 32400 internal, and tell plex what external port we've been assigned.  Plex accommodates this with the "manually specify public port" option for these cases where default 32400 is not being used on the WAN.

Share this post


Link to post
19 hours ago, go558a83nk said:

Maybe being signed in is the problem. I can assure you that remote port 39196 and local port 32400 is perfectly fine. 


Hello!

That's not true in general. It's true only if Plex listens to the "public" (as it is called in Plex settings) port 32400 too. With the previous configuration the VPN client received packets on tun interface (the VPN virtual network adapter) port 32400, while Plex listened to port 39196. Now the user has resolved the problem through the provided suggestion, i.e. the remote port is forwarded to the tun interface port which is the public listening port on Plex, NOT 32400.

To be clear: now the Plex server listens to public port 2***7. The port panel of the user is configured to forward remote port 2***7 to client port 2***7 (same port number). Everything works as expected.

If the VPN server remote port were forwarded to VPN client port 32400, the same problem would occur, as the packets would arrive on tun interface port 32400. Plex would not listen to tun interface port 32400. It would therefore see nothing on VPN interface port 2***7, the port it listens to ("public port"). Please make sure you understand that physical interface port 32400 is not VPN interface port 32400 and that Plex listens always to port 32400 of the physical interface while you are free to configure any public port you wish.

It's important to understand all of this. We have reviewed some old tickets related to Plex problems caused by exactly this misunderstanding. As an additional didactic aid, please visualise the flow of incoming packets when the listening programs are running on the same system that's connected to the VPN: when such packets pass through the system's physical interface, the underlying header and payload are still encrypted, so the port set of the physical interface never plays a role in the incoming virtual private network packets.
 
20 hours ago, robzeta said:

Think I finally made it work now with another custom port, have full access now externally and port responding open :) Can’t really tell what’s the reason it suddenly working, thanks for your help anyway.


Here above you find the explanation, it might come handy to you and any other Plex user.

Kind regards
 

Share this post


Link to post
image.png.448c1dba1fb7ada560f16eb9da3d94de.png
image.thumb.png.0a0ce6db72143eedcd485af0a01ef3b6.png
image.png.83d0f9c92f81bc1105ac13e2746c5a28.png

this is my experience but @Staff seems to be saying this isn't the way it works.  27183 mapped to 32400 on Air's servers, pfsense is instructed to forward port 32400 on the VPN interface to my laptop:32400 where plex is listening.  I have to instruct plex that the actual public port is not 32400 but 27183.  Note that by manually specifying public port plex does not change the private port it listens on - it's always 32400.




image.png.72c4bbd45807f9e4622044ae0f30b9b7.png
image.thumb.png.8794a9975860bf70081f3f1c234ad139.png

I could make the port forwarding rule on the Air web site 27183-27183 and then change my port forwarding rule in pfsense to VPN interface:27183-laptop:32400 and that would work also.

So, you can see why I say what I say.  I'd have to look more into behaviors when the VPN client is on the same device as the plex server but one thing holds true, I know : plex always listens at localhost:32400.

image.png.70ec09f115c17dd3f34d2ac12c975d5c.png

https://support.plex.tv/articles/200931138-troubleshooting-remote-access/
So I really see it as impossible that a port forwarding rule 2***7 forwarded to 2***7 works unless somewhere else in the chain 2***7 forwarded to 32400.

 

Share this post


Link to post
@go558a83nk

Hello!

😋 You are mentioning a case requiring a specific pre-routing and a specific forward rule on your pfSense machine which takes care of the additional forwarding strictly needed in this case. It's the pfSense machine with acts as a router, builds a NAT for any other device and also connects to the VPN server as its virtual upstream. pfSense then decides how the NAT operates, for example it pre-routes and forwards incoming packet reaching its VPN interface port 32400 to 192.168.1.4:32400 (port 32400 of the IP address of the physical interface of the machine running Plex).

By the way nothing changes indeed: when you modified your AirVPN account port panel, note that you were obliged to modify the pfSense rule as well (you changed XUANGE_WG interface port 27183 to 32400), otherwise the rule would have never been fired, as nothing was sent to port 27183, and you would have had the same problem of the OP, obviously.

The main difference with @robzeta setup which must be taken into account to offer correct suggestions is that robzeta's Plex receives packets on its sytstem's virtual tun interface (therefore "External port" in Plex settings terminology), while in your setup Plex receives packets on the physical network interface ("Internal port", in Plex terminology) thanks to the in-between NAT built by your router, but the principles are all the same.

The original problem could be resolved therefore in two alternative ways:
  1. modify Plex settings to have it listen to port 32400 even as "external port" and leave VPN remote port "re-mapped" to client port 32400
  2. modify the port panel to forward remote VPN port 39186 to VPN client port 39186 (same numbers, no "re-mapping") and leave Plex listen to "external port"  39186

robzeta resolved by applying the 2nd method.

Kind regards
 

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Security Check
    Play CAPTCHA Audio
    Refresh Image

×
×
  • Create New...