I have the strangest problem and i’m just at a loss now for a solution - hence this post:
I have a Windows Plex Server running on my LAN, and my firewall is a PFsense doing regular NAT and portforwarding as well as reverse https proxying. The thing is:
0: EVERYTHING - server, klients, smartTV’s and such are signed in to my plex pass account.
1: My server is setup for required secure (as i’m a security maniac)
2: In my house I can sign in to https://servername:32400 without issue from a webbrowser.
3: I have also made a DNS redirect for http://plex.mydomain.com to https://plex.tv/web to make webaccess easy in new browsers. Login through https://plex.tv/web works perfectly
4: In my servers NETWORK -> CUSTOM SERVER ACCESS URL: I have entered https://internal.server:32400, https://plex.mydomain.com:443 to make internal and external discovery possible.
5: I have allowed “plex.direct” names as local lookup in my pfsense DNS service.
6: All my IOS clients discovers the server at home without issue - works perfectly
7: All my Windows 10 universal apps discovers the server at home without issue - works perfectly
8: My Samsung SmartTV’s with the v. 2.006 app “setup for secure” does not discover the server at boot. If i manually press discover again it works perfectly. But it’s forgotten at next start and I have to press the discover PMS button again. (ANNOYING!)
9: I have created a reverse HTTPS proxy rule in my firewall to forward plex.mydomain.com URL requests on 443 to my internal server on https://internal.server:32400
10: I cannot get Remote Access to register as working in the Plex Server Web interface. I have specified a manual port (443) but it just wont register as working.
11: But it does work. I can login easily in a webbrowser from the outside by using either https://plex.tv/web or https://plex.mydomain.com
12: All Windows 10 universal apps discovers the server from the outside and works perfectly.
13: IOS devices DOES NOT work from the outside. They cannot discover the server, and after several attempts i can get it working in indirect mode (not desirable).
What the hell is going on? It works on the inside and outside but 3 problems persists:
1: Samsung TV’s does not work at first boot - fails to discover the server (inside). Works after pressing the discover button again.
2: Remote Access will not register as working even though the HTTPS proxy works and external access works (except for IOS)
3: IOS clients does not work on the outside.
It used to work when running server 1.0.3 and a similar setup, but then I upgraded to 1.2.2 and setup “require secure” on the server. Then things started falling apart.
I have tried using a manual 32400 portforward in my firewall as well, but that won’t work either (cannot register for remote access and IOS fails - the rest still works in this scenario.
I’m a little confused about where to look in the logs as I don’t see much in the downloaded logfiles. I assume it should be in the “plex media Server” logfile as the rest are related to agents, media scanners and such right?
I then tried enabling additional logging in the GENERAL settings page, and I get a a whole lot of browser related activity logging when enabling remote access. I have attached the last piece of the log from when trying to enable remote access again, but the only thing in there i find odd is:
[3768] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (5c416b2e-d20a-4533-8640-956a8e44a270, expected a7f63234-241a-4b0c-8022-2d43aac04be2)
But please look through the attached log, and please give any pointers as to how I can get/generate better logdata for your analysis.
@sa2000 said:
A very complex setup. Will consult with others
Well, yes I see my description is long and complex, but in all honesty I think the only 3 things that makes my setup “complicated” compared to your average next-next-next installation is:
1: I have enabled the “Always Secure” setting on my internal server
2: I do not use a regular 32400 portforward in my firewall but rather a reverse proxy listening on port 443 (With a proper signed certificate that contains “plex.mydomain.com” as a certificate name). This means I have to setup a manual port in Plex Remote Access, and that I have to add: https://plex.mydomain.com:443 in the NETWORK → CUSTOM SERVER ACCESS URL List.
3: I have for ease of use (internally and externally) made a HTTP Redirect service for http://plex.mydomain.com to https://plex.tv/web so it get’s much easier and intuitive to access the web interface. But that should have absolutely no impact on anything regarding the issues I see.
So really it’s rather simple in my opinion, but ease of use is much better and so is security
@DerKeyser said:
but the only thing in there i find odd is:
[3768] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (5c416b2e-d20a-4533-8640-956a8e44a270, expected a7f63234-241a-4b0c-8022-2d43aac04be2)
There is a fix for the async identifier warnings in release 1.2.3 of Plex Media Server which is now available initially for Plex Pass and would be expected to become public once it had some exposure
@DerKeyser said:
Sorry, was away yesterday. but I’m back now.
I’m a little confused about where to look in the logs as I don’t see much in the downloaded logfiles. I assume it should be in the “plex media Server” logfile as the rest are related to agents, media scanners and such right?
I then tried enabling additional logging in the GENERAL settings page, and I get a a whole lot of browser related activity logging when enabling remote access. I have attached the last piece of the log from when trying to enable remote access again,[…]
Can you please upload the full log (hide/mask any sensitive information)?
One thing you could test is see if it works without the reverse proxy in play… set port forward in the router for something other then 443 i.e. and define that manually in plex. If that works then it might be related to the reverse proxy.
@DerKeyser said:
but the only thing in there i find odd is:
[3768] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (5c416b2e-d20a-4533-8640-956a8e44a270, expected a7f63234-241a-4b0c-8022-2d43aac04be2)
There is a fix for the async identifier warnings in release 1.2.3 of Plex Media Server which is now available initially for Plex Pass and would be expected to become public once it had some exposure
I tried the upgrade and that made no difference - It still will not register successfully in “Remote Access”
BUT: Something has changed with the 1.2.3 Build because I can now get it to register successfully for remote access if I manually open port 32400 in my router. That didn’t work either before. And with that open, I can get my IOS devices to discover it as well.
So one option is to just run over 32400 (which I would rather not), the other is finding out why it won’t work through my reverse proxy anymore. My first and best guess is that discovery from IOS does not access the server with the URL published in “CUSTOM SERVER ACCESS URL”. That way my reverse proxy see’s a wrong URL and denies the request.
Unfortunately I have very little logging options in my reverse proxy. Any chance you could recognize this from other situations?
To support my theory, I can say that if I leave the CUSTOM SERVER ACCESS URL registered “wrong” - that is with my https://plex.mydomain.com:443 entry, IOS still works right away when 32400 is open, but not over 443.
So IOS seems to ignore the discovery URL and use that to access the server.
Well, I have done some more testing, and there’s something wrong with how “Remote Access” is registered and used for discovery by clients (Combined with CUSTOM SERVER ACCESS URL). I can see dozens of post with people having similar problems since 1.1.x came out. Currently I have to manually specify port 32400 in my server remote access settings even though it should default to that if “custom port” is not selected. But none the less if I unclick the custom port setting, remote access will not register. My server is still available and works directly through 32400 in my firewall but plex says it’s not working. If I specify 32400 in the custom field it starts working.
My current theory is there’s some odd discovery data “stuck” on my plex account that stops all default behaviour from working. I have to specify everything manually, and still I can’t get it going over 443 (or any other port for that matter) instead of 32400.
Port 32400 is the default pre-set value in the box Manually Specify Port - it is not used as the default public port. The default is dynamically assigned uPnP port. Only if you tick the Manually Specify Port box would the default pre-set value in the box get used. It has always been that way and it has tripped up many users because the assumption was that it is the default port. It is only true for local port
@DerKeyser are you using upnp in you’re router? and if not are you manually specifying port forwarding?
If this is working with 32400 then it means you’re router/firewall is doing the port forwarding on 32400, which possibly is done manually.
That’s the main reason I asked if Remote Access worked directly to be sure things were ok regarding port forwarding.
However if you do use a reverse proxy in the local network, then even without remote access set, you should be able to use “REMOTE_IP:443” and reach the server from an external network, if all is ok with the reverse proxy config ofc.
And I just mean reach the webUI (you will ofc get a certificate error if the custom url is not set) but the point is at least that must work, and if that does work, than the issue should be in the reverse proxy setup.
In that case I would:
1 - Be sure you can reach LAN_IP:32400
2 - Be sure the proxy (what is it btw nginx? It might help to maybe post the config) can reach the LAN_IP:32400.
3 - Be sure you can reach the server using the reverse proxy on the LAN (assuming REVERSE_PROXY_LAN_IP:443 here)
Port 32400 is the default pre-set value in the box Manually Specify Port - it is not used as the default public port. The default is dynamically assigned uPnP port. Only if you tick the Manually Specify Port box would the default pre-set value in the box get used. It has always been that way and it has tripped up many users because the assumption was that it is the default port. It is only true for local port
Ahhhh, well that explains a lot regarding the need to use the “specify port manually” feature
I thought plex would always instruct the firewall (and hence my plexaccount) to use 32400 via uPnP. And since I am not using uPnP on my firewall, i could just open it manually like i’m doing now. But this makes sence, and I now understand the need to specify it manually.
@mikec_pt said: @DerKeyser are you using upnp in you’re router? and if not are you manually specifying port forwarding?
If this is working with 32400 then it means you’re router/firewall is doing the port forwarding on 32400, which possibly is done manually.
That’s the main reason I asked if Remote Access worked directly to be sure things were ok regarding port forwarding.
However if you do use a reverse proxy in the local network, then even without remote access set, you should be able to use “REMOTE_IP:443” and reach the server from an external network, if all is ok with the reverse proxy config ofc.
And I just mean reach the webUI (you will ofc get a certificate error if the custom url is not set) but the point is at least that must work, and if that does work, than the issue should be in the reverse proxy setup.
In that case I would:
1 - Be sure you can reach LAN_IP:32400
2 - Be sure the proxy (what is it btw nginx? It might help to maybe post the config) can reach the LAN_IP:32400.
3 - Be sure you can reach the server using the reverse proxy on the LAN (assuming REVERSE_PROXY_LAN_IP:443 here)
I’m not using uPnP, but it works when manually specifying 32400 (which i have opened and forwarded manually). But doing the same thing with 443 instead and having that pointed to my reverse proxy does not work - as far as enabling remote access goes.
But it actually does work from the outside when set for 443. I can access my webGUI just fine, and the windows universal app connects right away and works.
The only problem is IOS apps. They stop working when using 443 and goes to indirect mode instead.
But doing the same thing with 443 instead and having that pointed to my reverse proxy does not work
But the same thing with 443 with no reverse proxy in the middle does work correct?
Would you mind sharing the proxy config? Is it nginx? If so please share the config (In PM if you prefer) and I might be able to help.
If I redirect port 32400 on my router to the plex machine, then all is working fine.
best regards,
Daniel.
my plex server config:
remote access:
use public port: 32400
network:
local GDM: enable
own URL for this server: https://plex.mydomain.net/
networks without authentication: 127.0.0.1/255.255.255.255
HTTP Pipelining: enabled
my nginx host config:
server {
listen 80;
listen *:443 ssl;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_certificate /etc/letsencrypt/live/plex.mydomain.net/cert.pem;
ssl_certificate_key /etc/letsencrypt/live/plex.mydomain.net/privkey.pem;
server_name plex.mydomain.net;
root /var/www;
index index.php index.html index.htm;
# for letsencrypt no https redirect
location '/.well-known/acme-challenge' {
break;
}
# redirect all http => https
location '/' {
if ($scheme = 'http') {
rewrite ^ https://$server_name$request_uri? permanent;
}
}
#plex config
location '/plex' {
rewrite ^ https://$server_name/web permanent;
}
location /web {
access_log /var/log/nginx/plex.access.log combined;
error_log /var/log/nginx/plex.error.log;
if ($http_x_plex_device_name = '') {
rewrite ^/$ http://$http_host/web/index.html;
}
# set some headers and proxy stuff.
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# include Host header
proxy_set_header Host $http_host;
# proxy request to plex server
proxy_pass https://192.168.1.123:32400;
proxy_redirect off;
proxy_buffering off;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_read_timeout 36000s;
}
}
By no means and I trying to hijack this post, I will create a new forum post if necessary.
I have almost the exact same setup as DerKeyser and the same problem in that my Plex server is always “Not available outside of your netwok” when I try to setup Remote Access.
I have my firewall forwarding port 444 (currently unused port to make packet capturing easier) to my Nginx proxy that is listening on that same port. The proxy then is setup to terminate SSL and then proxy traffic to my plex server (over https).
I’ve enabled debugging logs in Plex and also in Nginx. From what I can see even though I’ve specified “Custom server access URLs” in my Plex config, whenever I click “Enable Remote Access” the Plex service attempts to contact my proxy server at my ..plex.direct address.
I can only assume that since my Nginx virtualhost is configured for plex.mydomain.com that the traffic is not getting forwarded because the SSL connection fails.
I’ve attached the Plex Media Server log and the Nginx log.
Also, I’ve tried changing my “Secure connections” setting from Preferred to Required, but the outcome is the same. However, if I set it to Disabled and perform the Remote Access test, the Plex service attempts to contact my IP directly on port 444 without a hostname.
Is there a way to get the Plex service to use my custom server access urls when checking for Remote Access?
That’s an interesting log from your nginx, and for a second I thought you solved the problem with showing that my reverse proxy needed the additional config to accept *.plex.direct URL’s to complete the remote Access setup and have it register the new name in the server discovery lookup at plex.tv.
But unfortunately it still doesn’t work, so I’m guessing plex.tv (and fx. the IOS client) does not accept a certificate mismatch (they were looking for xxxxxxxxx.plex.direct and instead found my reverse proxy’s wildcard.mydomain certificate.)
NOTE: I did test that my proxy accepts the yyy-yyy-yyy-yyy.xxxxxxxxxxxxx.plex.direct URL from an external access test (where yyy-yyy-yyy-yyy is my Public IP address and xxxxxxxx is the Hash assigned to me by plex’s certificate solution).
I noticed the later PMS editions under NETWORK (Advanced) allows you to setup the PMS to use your own certificate and domainname (Instead of the xxxx.plex.direct certificate i assume).
I’m guessing this is whats really needed to get this working. I can only imagine that would create the correct discovery URL’s as all access has to use my certificate name from then on in order not to trigger a certificate mismatch.
I would love to test it… but… I only have a wildcard certificate and while I love plex, I do not trust them with the private key to my wildcard certificate. So i’m not prepared to install my certificate and test if that’s really the way to solve this issue.
Do any of you guys have the ability to issue a test certificate for your domain and test if this will make it work over a reverse SSL proxy (with the same or a wildcard domain certificate)?
I was previously using a self signed certificate and specifying a custom domain name. I just uploaded my LetsEncrypt certificate that lives on my proxy to Plex (just in case it did not like my self signed one) and the results were the same. From the logs below it appears that Plex was able to load my certificate and did not complain, but the Plex service is still trying to access {ip}.{uuid}.plex.direct when attempting to enable Remote Access.
Excellent analysis. So basically we cannot get a reverse SSL proxy to work because the “remote access setup” procedure insists on using the (ip).(uuid).plex.direct URL which requires a certificate we do not have and hence cannot put on our proxy.
It seems the procedure has no tolerance for a certificate error which would otherwise allow it all to work.
So the question is: How do we get plex to support using a custom URL for the remote access setup procedure - and for server discovery/clients (like IOS and such)?
Edit: I have crossposted a link to this thread in “general discussions (plex pass)” where I had a dedicated thread on the reverse proxy problem. Lets hope we can get some attention there
