I’m also experiencing no remote access. I have a double NAT situation, but port forwarding is all set up and I’ve only noticed this issue since upgrading this morning to 1.18.9.2571. Restarted everything a million times, disabled Windows firewall on the server PC. Nothing is working.
I am based in NZ so xFinity issues aren’t relevant. How can I go about getting this looked into?
I’m using Version 1.19.1.2645 - everything is as up to date as I can get it - I’m in NZ, I don’t think it is the ISP, everything worked fine, did the upgrade, now patiently waiting for the upgrade of the upgrade. Thanks my friends, soon as you like 
How is this STILL an issue?
Now I remember why I never update PMS and why I ran 1.14 for over a year.
This is definitely an issue on the Plex side. I have had remote access configured for 3+ years and never had an issue. My port forward is still active, as are all of the other port forwards I have configured on my router. I can see the plex.tv URLs from this list(https://s3-eu-west-1.amazonaws.com/plex-sidekiq-servers-list/sidekiqIPs.txt) being let through my firewall and directed to my Plex Media Server’s internal IP address, on port 32400.
Following the steps in this post - Remote access failure I can see all of my server URLs that are being published to plex.tv. I select the one that contains my external IP address and connect to it on a remote network JUST FINE. Yet Plex continues to tell me that my server is not accessible remotely & my users can not stream.
Yeh I’m having same issue. TO PLEX FIX IT OR IM CANCELLING DIRECT DEBIT! Obviously a Plex issue from the number of complaints.
I also have this issue. Happy to send logs @sa2000 would you like for me to send you logs? I have a QNAP as the server.
My remote access is non-functional as well (other than via relay, which is data limited). I host the Plex Server on a Mac running Catalina, and I’ve tried the following unsuccessfully:
Happy to send logs as well @sa2000
Logs covering time when the issue arises. With debug logging already enabled - preferably before restarting the server - and also router screenshots showing any DHCP Reservation, Port Forward, and the WAN IP Address on the internet connection status page
You can send me logs and router config details but anything to do with vpn, I would not be in a position to help - what is important for remote access is that the the wan IP address that plex sees is the one that can be reached from outside through the published external port and specified through manually specify port
THIS… +1 Running on OS X 10.15.4, with PMS 1.19.1.2645. Should there be ports other than TCP 32400 open??
Do you block any IP Addresses ? There could many different IP addresses used for connectivity testing for remote access
No. I only block ports.
@sa2000 I had a working config for a few years, now remote access has gone bonkers, and I have users complaining about remote streaming stuttering. MANY reason to explain remote stream issues, but for the remote access flapping on and off constantly, definitely doesn’t seem to be an issue on my end - unless the changes Plex made to tokens is what’s causing the issue.Plex Media Server Logs_2020-04-13_12-17-34.zip (3.1 MB)
Yep put me on the list as well exact same problem with 3 servers. Open port is confirmed to IP. Running Plex on QNAP servers different configurations hardware routers all three behave in the same manner.
So last night, I tried one more combination of settings that did get everything to work:
For anybody else troubleshooting, I added the VPN to attempt to get around CGNAT without purchasing a static IP, but this was not successful, and somewhere in the chain, the VPN was preventing access, even when all the other links in the chain were operational.
The Firewall setting had been external ports TCP 32400 - 32408 > 32400.
This firewall configuration stopped working for me over the past week-10 days.
Changed the range to TCP Any |> 32400 and it works again.
Would prefer not to have such a wide range of external ports open, however, lacking better TCP range information from Plex, at least this works again.
For clarity I have Plex Server on several PCs and a MACs.
Are you enabling debug logging after the problem arises and then disabling it again?
Logs show debug logging enabled at 17:23 on the 10th and then disabled again at 18:02 and then 3 days later on 13th it was enabled at 12:16.
I would really like to see debug logs throughout and together with info from you as to what time and day remote access was reported as dropped
I can see you disabled remote access just after enabling debug logging and then re-enabled.
Prior to this and I assume that was when the issue arose, I can see token errors in the server attempts to communicate with the plex.tv backend systems - but there is no context to these errors as debug logging was off - these errors were logged up to 15:30 on the 10th. The server security token was invalid - was there any editing of Preferences.xml ?
Please leave debug logging enabled all the time if you have issues that need to be investigated. And restart the server after that so fresh logs are created and debug logging would be in place from the start.
With regards to the period after that - there is evidence of connectivity tests to the server not getting through from the back end systems. Do you have any whitelisting of remote IP addresses in firewall rules?
I see you have syslog logging enabled for the port forward rule - see if there are any rejected
I have looked at your logs
None of the connectivity tests from our back end systems got through to PMS
I see you have loads of network adaptors
Which one is the port forward to ? and was the port forward still in place at the time
The following would be relevant if the port forward was to 192.168.3.109:
Is the port forward to another IP address ?
Apr 13, 2020 09:03:55.927 [0x7f2277ef7740] DEBUG - Network interfaces:
Apr 13, 2020 09:03:55.927 [0x7f2277ef7740] DEBUG - * 1 lo (127.0.0.1) (loopback: 1)
Apr 13, 2020 09:03:55.927 [0x7f2277ef7740] DEBUG - * 15 br0 (192.168.3.109) (loopback: 0)
Apr 13, 2020 09:03:55.927 [0x7f2277ef7740] DEBUG - * 16 docker0 (10.0.5.1) (loopback: 0)
Apr 13, 2020 09:03:55.927 [0x7f2277ef7740] DEBUG - * 17 lxcbr0 (10.0.3.1) (loopback: 0)
Apr 13, 2020 09:03:55.927 [0x7f2277ef7740] DEBUG - * 18 qvs0 (192.168.3.2) (loopback: 0)
Apr 13, 2020 09:03:55.927 [0x7f2277ef7740] DEBUG - * 19 qvs1 (192.168.4.1) (loopback: 0)
Apr 13, 2020 09:03:55.927 [0x7f2277ef7740] DEBUG - * 18 qvs0 (fe80::265e:beff:fe0f:9e97%qvs0) (loopback: 0)
Apr 13, 2020 15:44:25.587 [0x7f22656cb700] DEBUG - Network interfaces:
Apr 13, 2020 15:44:25.587 [0x7f22656cb700] DEBUG - * 1 lo (127.0.0.1) (loopback: 1)
Apr 13, 2020 15:44:25.587 [0x7f22656cb700] DEBUG - * 16 docker0 (10.0.5.1) (loopback: 0)
Apr 13, 2020 15:44:25.587 [0x7f22656cb700] DEBUG - * 17 lxcbr0 (10.0.3.1) (loopback: 0)
Apr 13, 2020 15:44:25.587 [0x7f22656cb700] DEBUG - * 18 qvs0 (192.168.3.2) (loopback: 0)
Apr 13, 2020 15:44:25.587 [0x7f22656cb700] DEBUG - * 19 qvs1 (192.168.4.1) (loopback: 0)
Apr 13, 2020 15:44:25.587 [0x7f22656cb700] DEBUG - * 18 qvs0 (fe80::265e:beff:fe0f:9e97%qvs0) (loopback: 0)
Apr 13, 2020 15:44:31.143 [0x7f22656cb700] DEBUG - Network interfaces:
Apr 13, 2020 15:44:31.143 [0x7f22656cb700] DEBUG - * 1 lo (127.0.0.1) (loopback: 1)
Apr 13, 2020 15:44:31.143 [0x7f22656cb700] DEBUG - * 15 br0 (192.168.3.106) (loopback: 0)
Apr 13, 2020 15:44:31.143 [0x7f22656cb700] DEBUG - * 16 docker0 (10.0.5.1) (loopback: 0)
Apr 13, 2020 15:44:31.143 [0x7f22656cb700] DEBUG - * 17 lxcbr0 (10.0.3.1) (loopback: 0)
Apr 13, 2020 15:44:31.143 [0x7f22656cb700] DEBUG - * 18 qvs0 (192.168.3.2) (loopback: 0)
Apr 13, 2020 15:44:31.143 [0x7f22656cb700] DEBUG - * 19 qvs1 (192.168.4.1) (loopback: 0)
Apr 13, 2020 15:44:31.143 [0x7f22656cb700] DEBUG - * 18 qvs0 (fe80::265e:beff:fe0f:9e97%qvs0) (loopback: 0)
Connectivity Tests at these times did not reach the server
Apr 13, 2020 09:04:15.321 [0x7f2267466700] DEBUG - EventSource: Got event [data] '<Message address="101.118.xxx.xxx" port="32400" asyncIdentifier="661f5752-fb44-4ef8-a7d8-c04ca7d0c987" connectivity="0" command="notifyConnectivity"/>'
Apr 14, 2020 09:04:07.371 [0x7f2267754700] DEBUG - EventSource: Got event [data] '<Message address="101.118.xxx.xxx" port="32400" asyncIdentifier="c0a4d537-55cf-46c4-93bc-1c8947a60ec3" connectivity="0" command="notifyConnectivity"/>'
Apr 14, 2020 18:45:27.936 [0x7f2267754700] DEBUG - EventSource: Got event [data] '<Message address="101.118.xxx.xxx" port="32400" asyncIdentifier="f3547f15-ef14-4c14-8be3-ed0c7d0aa7fa" connectivity="0" command="notifyConnectivity"/>'
When you have this problem - can you test the port forward with an attempt to connect to your server from outside - like this:
http://public-wan-ip:32400/web
If you get to an authentication challenge it means that the port forward is ok
But the test needs to be from outside your network as some routers block attempts to connect through the WAN IP address when on the local network
First up I appreciate your time cheers.
I have a static IP set for the server which is 192.16.3.2 the port which is forwarded is 32400.
Yesterday I could manually put the port in as well as WAN in my mobile phone would get a connection just would not do this automatically. The remote login for the PC was the same could not find the server.
However I tried it again last night got a remote connection " the green tick" it seems to be remotely connecting now however shows disconnected in settings.
I’ll get the logs and send them to you again and see if stays up for 12 hours.
Strangely enough another server I look after which has not had any changes made is remotely connecting as well now and it was not only two days ago. I was having some luck changing the DNS provider just to confused the problem further.
Thanks
Hi @sa2000
I was doing my own troubleshooting to see if I could get any further information on why remote access showed disconnected.
I did this to reproduce the issue in response to this thread. I enabled debug logging, as required, and then disabled, reenabled, and ran a retry after remote access was reported as down.
Yes, as detailed in another of my posts here, I did the token reset procedure as detailed in ChuckPA’s post in a synology thread. While this got my remote access working, I no longer had secure connections to my plex as the SSL cert was marked as revoked. Once I figured out the SSL cert was hosed, I ran through the process to reset it by setting secure connections to disabled, stopping plex and deleting it from the app.plex.tv, logging back into everything, and reenabling secure connections to Preferred, I got a new cert pushed down to me and i can now connect securely from app.plex.tv.
Done. Earlier I went ahead and enabled debug logging and restarted the plex service.
I have no blacklisting of anything except BOGON networks in my firewall.
Sure, plex_nat.txt Nothing is rejected. I do see other NATs happening from some of my remote users. I did not go through the IP list to disseminate which, if any, are from plex.tv servers. I grepped out one particular IP that was from a known user that was watching a movie as it didn’t seem imperative to include it.
I have been fiddling with MSS clamping since I’ve been stuck in quarantine, but I don’t believe it has anything to do with this issue as the issue started way before I started messing with MTUs to the internet. This all really feels like some sort of token issue.
A moment ago, I logged in to check remote access status to see if it was OK. It was green. Refreshed the page, back to red. Ran a retry, it flips to green for a split second, then right back to red. I do not run uPNP on my network whatsoever. It’s dangerous, IMO, to have ports opened to internal devices on my network and not know it.
Here’s the current logs. Happy to upload more if you want. I’m leaving debug enabled until this gets sorted.Plex Media Server Logs_2020-04-17_14-55-52.zip (6.4 MB)
I am not sure if this helps but I was having the same problem. I was getting a notification that it was losing remote access constantly. I had nomachine installed and I switched to teamviewer and it has been stable since. So I don’t know if your remote access program of choice is causing any interference.
