Server Will Not Stay Connected to Remote Access

@ralberts said:
For what it’s worth, I’ve been having the same problem since I updated to the newest Plex server version. Never been an issue before, now it’s a pain in the behind.

I would suggest switching to a manually specified port and a port forward in the router until the issue with uPnP automatic port mapping is understood and identified.

Since my last post above, I have seen loss of port mapping when using uPnP and this is being investigated at the moment.

So steps to follow

  1. Ensure the local IP Address of the server is fixed - eg use of DHCP Reservation in the router
  2. Setup a port forward in the router to port forward a public / wan port to private / local port 32400 (tcp). The public / wan port does not have to be 32400 - unless you have a router that does not allow you to have different port numbers for wan/public and local/private. The port forward is to go to the local IP of the server
  3. Select Manually Specify Port on the server remote access advanced settings page and enter the public / wan port selected for the port forward to local port 32400 and click Apply

You may need to disable and re-enable Remote Access. There are timing issues when switching from automatic to manual but these should get overcome after a while. Avoid clicking Retry too many times or in quick succession.

I am having a problem with remote access staying accessible outside my network when forwarding port 32400 on my router to my Plex server or even using UPnP. When specifying a port, it connects for a split second then disconnects and stays disconnected. When using UPnP instead of forwarding port it seems to stay connected longer but also disconnects eventually. I have rebooted router and plex when trying each. Below are my details.

QNAP 251+ Firmware 4.3.3
D-Link DIR-655 Firmware 2.12 Rev B1
Plex Version 3.9.1

Some router screenshots …

When I check manually specify public port and click Apply it briefly shows …

Then a second later shows …

Below is Plex Media Server.log when I change to manually specified public port. Highlighted a few lines that may be of interest. I really don’t know enough to figure out what is going on in the log but I see a warning entry that seems to suggest after changing port Plex’s server is expecting one async identifier but get another but have no idea if that has anything to do with my issue.

Aug 06, 2017 13:23:09.420 [0x7fce8c2fb700] DEBUG - MyPlex: Sending Server Info to myPlex (user=johnkelly@hotmail.com, ip=, port=32400)

Aug 06, 2017 13:23:09.422 [0x7fce8c2fb700] DEBUG - HTTP requesting POST https://plex.tv/servers.xml?auth_token=xxxxxxxxxxxxxxxxxxxx&async=1&asyncIdentifier=98f67cfe-39e1-4bd1-89b0-0a97aa255265
Aug 06, 2017 13:23:09.428 [0x7fce8e047700] DEBUG - EventSource: Got event [data] '<Message address="" port="0" asyncIdentifier="7a34a93a-479b-4a9c-bf11-cfaec8cda5c4" connectivity="0" command="notifyConnectivity"/>'
Aug 06, 2017 13:23:09.702 [0x7fce963ff700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:09.702 [0x7fce963ff700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:09.702 [0x7fce963ff700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:09.702 [0x7fce8d1a1700] DEBUG - Request: [192.168.1.103:51646 (Subnet)] GET /myplex/account (7 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:09.705 [0x7fce963ff700] DEBUG - Completed: [192.168.1.103:51646] 200 GET /myplex/account (7 live) TLS GZIP 2ms 600 bytes (pipelined: 2)
Aug 06, 2017 13:23:10.202 [0x7fce96111700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:10.202 [0x7fce96111700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:10.202 [0x7fce96111700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:10.202 [0x7fce83223700] DEBUG - Request: [192.168.1.103:51646 (Subnet)] GET /myplex/account (7 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:10.205 [0x7fce96111700] DEBUG - Completed: [192.168.1.103:51646] 200 GET /myplex/account (7 live) TLS GZIP 2ms 600 bytes (pipelined: 3)
Aug 06, 2017 13:23:10.385 [0x7fce8c2fb700] DEBUG - HTTP 201 response from POST https://plex.tv/servers.xml?auth_token=xxxxxxxxxxxxxxxxxxxx&async=1&asyncIdentifier=98f67cfe-39e1-4bd1-89b0-0a97aa255265
Aug 06, 2017 13:23:10.386 [0x7fce8c2fb700] DEBUG - MyPlex: Published Mapping State response was 201
Aug 06, 2017 13:23:10.386 [0x7fce8c2fb700] DEBUG - MyPlex: Got response for 72b523fdd5eb2b26e22db1f85df092046295aa59 ~ registered :0

Aug 06, 2017 13:23:10.387 [0x7fce8e047700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (7a34a93a-479b-4a9c-bf11-cfaec8cda5c4, expected 98f67cfe-39e1-4bd1-89b0-0a97aa255265)

Aug 06, 2017 13:23:10.387 [0x7fce8c2fb700] DEBUG - MyPlex: Updating device connections (from timer: 0)

Aug 06, 2017 13:23:10.387 [0x7fce8c2fb700] DEBUG - HTTP requesting PUT https://plex.tv/devices/72b523fdd5eb2b26e22db1f85df092046295aa59?Connection[][uri]=http://192.168.1.100:32400&httpsEnabled=1&httpsRequired=0&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx

Aug 06, 2017 13:23:10.391 [0x7fce963ff700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:10.391 [0x7fce963ff700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:10.391 [0x7fce963ff700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:10.391 [0x7fce96111700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:10.391 [0x7fce96111700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:10.391 [0x7fce96111700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:10.391 [0x7fce8e911700] DEBUG - Request: [192.168.1.103:51646 (Subnet)] PUT /myplex/refreshReachability (7 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:10.391 [0x7fce8d1a1700] DEBUG - Request: [192.168.1.103:51645 (Subnet)] PUT /myplex/refreshReachability (7 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:10.391 [0x7fce8e911700] DEBUG - MyPlex: Requesting reachability check.
Aug 06, 2017 13:23:10.394 [0x7fce8e911700] DEBUG - HTTP requesting PUT https://plex.tv/api/servers/72b523fdd5eb2b26e22db1f85df092046295aa59/connectivity?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx&asyncIdentifier=f2d3d15c-50a9-4b6c-9122-0a927b2172bc
Aug 06, 2017 13:23:10.701 [0x7fce963ff700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:10.701 [0x7fce963ff700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:10.701 [0x7fce963ff700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:10.702 [0x7fce8da6b700] DEBUG - Request: [192.168.1.103:51640 (Subnet)] GET /myplex/account (7 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:10.704 [0x7fce963ff700] DEBUG - Completed: [192.168.1.103:51640] 200 GET /myplex/account (7 live) TLS GZIP 2ms 648 bytes (pipelined: 7)

Aug 06, 2017 13:23:11.298 [0x7fce8c2fb700] DEBUG - HTTP 200 response from PUT https://plex.tv/devices/72b523fdd5eb2b26e22db1f85df092046295aa59?Connection[][uri]=http://192.168.1.100:32400&httpsEnabled=1&httpsRequired=0&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx

Aug 06, 2017 13:23:11.493 [0x7fce8e911700] DEBUG - HTTP 200 response from PUT https://plex.tv/api/servers/72b523fdd5eb2b26e22db1f85df092046295aa59/connectivity?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx&asyncIdentifier=f2d3d15c-50a9-4b6c-9122-0a927b2172bc`
Aug 06, 2017 13:23:11.494 [0x7fce8d1a1700] DEBUG - MyPlex: Requesting reachability check.
Aug 06, 2017 13:23:11.495 [0x7fce963ff700] DEBUG - Completed: [192.168.1.103:51646] 200 PUT /myplex/refreshReachability (7 live) TLS GZIP 1104ms 268 bytes (pipelined: 4)
Aug 06, 2017 13:23:11.496 [0x7fce8d1a1700] DEBUG - HTTP requesting PUT https://plex.tv/api/servers/72b523fdd5eb2b26e22db1f85df092046295aa59/connectivity?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx&asyncIdentifier=62413001-0d34-40d2-9c4d-309fc60968e1
Aug 06, 2017 13:23:11.613 [0x7fce8e047700] DEBUG - EventSource: Got event [data] '<Message address="" port="0" asyncIdentifier="f2d3d15c-50a9-4b6c-9122-0a927b2172bc" connectivity="0" command="notifyConnectivity"/>'
Aug 06, 2017 13:23:12.365 [0x7fce8d1a1700] DEBUG - HTTP 200 response from PUT https://plex.tv/api/servers/72b523fdd5eb2b26e22db1f85df092046295aa59/connectivity?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx&asyncIdentifier=62413001-0d34-40d2-9c4d-309fc60968e1

Aug 06, 2017 13:23:12.366 [0x7fce8e047700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (f2d3d15c-50a9-4b6c-9122-0a927b2172bc, expected 62413001-0d34-40d2-9c4d-309fc60968e1)

Aug 06, 2017 13:23:12.368 [0x7fce96111700] DEBUG - Completed: [192.168.1.103:51645] 200 PUT /myplex/refreshReachability (7 live) TLS GZIP 1976ms 268 bytes (pipelined: 4)
Aug 06, 2017 13:23:12.504 [0x7fce8e047700] DEBUG - EventSource: Got event [data] '<Message address="" port="0" asyncIdentifier="62413001-0d34-40d2-9c4d-309fc60968e1" connectivity="0" command="notifyConnectivity"/>'
Aug 06, 2017 13:23:12.504 [0x7fce8e047700] DEBUG - PubSub: Got notified of reachability: 0 for :0
Aug 06, 2017 13:23:12.509 [0x7fce96111700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:12.509 [0x7fce96111700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:12.509 [0x7fce96111700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:12.509 [0x7fce83223700] DEBUG - Request: [192.168.1.103:51645 (Subnet)] GET /myplex/account (7 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:12.512 [0x7fce96111700] DEBUG - Completed: [192.168.1.103:51645] 200 GET /myplex/account (7 live) TLS GZIP 2ms 656 bytes (pipelined: 5)
Aug 06, 2017 13:23:12.554 [0x7fce963ff700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:12.554 [0x7fce963ff700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:12.554 [0x7fce963ff700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:12.554 [0x7fce8da6b700] DEBUG - Request: [192.168.1.103:51645 (Subnet)] GET /myplex/account (7 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:12.557 [0x7fce963ff700] DEBUG - Completed: [192.168.1.103:51645] 200 GET /myplex/account (7 live) TLS GZIP 2ms 656 bytes (pipelined: 6)
Aug 06, 2017 13:23:15.044 [0x7fce963ff700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:15.044 [0x7fce963ff700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:15.044 [0x7fce963ff700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:15.044 [0x7fce8e911700] DEBUG - Request: [192.168.1.103:51645 (Subnet)] GET /player/proxy/poll?deviceClass=pc&protocolVersion=1&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (7 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:15.045 [0x7fce8e911700] DEBUG - Beginning read from two-way stream.
Aug 06, 2017 13:23:15.758 [0x7fce96111700] DEBUG - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Aug 06, 2017 13:23:15.758 [0x7fce96111700] DEBUG - Auth: authenticated user 1 as JohnCKelly
Aug 06, 2017 13:23:15.758 [0x7fce96111700] DEBUG - Auth: Came in with a super-token, authorization succeeded.
Aug 06, 2017 13:23:15.758 [0x7fce8d1a1700] DEBUG - Request: [192.168.1.103:51649 (Subnet)] GET /diagnostics/logs (8 live) TLS GZIP Signed-in Token (JohnCKelly)
Aug 06, 2017 13:23:15.759 [0x7fce8d1a1700] DEBUG - Diagnostics: Building logfile zip

The ‘async identifier’ warnings are timing issues to do with multiple requests - like these

Aug 06, 2017 13:23:10.391 [0x7fce8e911700] DEBUG - Request: [192.168.1.103:51646 (Subnet)] PUT /myplex/refreshReachability (7 live) TLS GZIP Signed-in Token (JohnCKelly)

Aug 06, 2017 13:23:10.391 [0x7fce8d1a1700] DEBUG - Request: [192.168.1.103:51645 (Subnet)] PUT /myplex/refreshReachability (7 live) TLS GZIP Signed-in Token (JohnCKelly)

They should cause no harm other than status indication (green/red) may be wrong and should eventually settle down provided one does not keep on clicking on the buttons or not leave time gap of say 30 seconds between clicks of the Retry button

The above snippet shows - regardless of the async ident problem, that all connectivity attempts failed
e,g,

40d2-9c4d-309fc60968e1
Aug 06, 2017 13:23:11.613 [0x7fce8e047700] DEBUG - EventSource: Got event [data] '<Message address="" port="0" asyncIdentifier="f2d3d15c-50a9-4b6c-9122-0a927b2172bc" connectivity="0" command="notifyConnectivity"/>'

We need to go through disabling remote access and then re-enabling it.
Avoid switching back and forth between manual and automatic port selection and stick with one approach - recommended one is the port forward case and manually specify port ticked and your 32400 public port set in the box

Things to check first and eliminate

  • Jumbo Frames - off and MTU Size at or below 1500 (there is a detailed test here to establish what it should be set to http://forums.plex.tv/discussion/comment/1393261/#Comment_1393261)
  • Only one local IP active on the server
  • check for double nat. check that your dlink router wan/internet ip address is the 24.xx.xx.xx that Plex Media Server is seeing

After eliminating the above and making any changes, shut down Plex Media Server
and re launch it

Wait 5 minutes
Ensure manually specify port is set and 32400 in the box

Then disable remote access
wait for it come back and then wait 1 minute

Enable Remote Access
wait for it to come back and then wait 1 minute
Refresh the browser with F5
If status is wrong, click Retry once
Wait 1 minute
Refresh the browser

still a problem get the full Plex Media Server.log - zip it and attach with the screenshot of the status

Thanks for reply. I verified jumbo frames are off on the NAS and NAS and router have MTU set to 1500. The NAS only has one local IP 192.168.1.100. The D-Link router WAN/IP is the same 24.xx.xx.xx address that the Plex Media Server is seeing.

I rebooted NAS, Plex server came back online at around 12:38 and followed all your step by step instructions but it still shows as “not available outside your network”. I have attached the full Plex Media Server.log.

Forgot screenshot …

@JohnCKelly said:
Thanks for reply. I verified jumbo frames are off on the NAS and NAS and router have MTU set to 1500. The NAS only has one local IP 192.168.1.100. The D-Link router WAN/IP is the same 24.xx.xx.xx address that the Plex Media Server is seeing.

I rebooted NAS, Plex server came back online at around 12:38 and followed all your step by step instructions but it still shows as “not available outside your network”. I have attached the full Plex Media Server.log.

All the attempts to connect to the server were failing, eg

Aug 07, 2017 12:45:52.430 [0x7f04bbaf9700] DEBUG - EventSource: Got event [data] '<Message address="24.xx.xx.xx" port="32400" asyncIdentifier="bb4ff499-428e-488a-9c83-2abe69bec4df" connectivity="0" command="notifyConnectivity"/>'

The connectivity tests would come in from WAN IP normally starting 54.xx.xx.xx or 50.x.xx.xx
There were no connectivity="1" events

Do you have anything in the router blocking specific IPs?

May be router needs reboot?

I have not entered anything in router to block those or other IPs. Because there are so many router settings I may have tinkered with over the years, I restored the default router settings and rebooted everything then readded the port forward and IP reservation and rebooted router again. I switch to using manually specified IP and checked the router log and see the following lines:

Aug 7 15:02:30 info [ 350.960000] '[DROPPED-PACKET]:'IN=eth0.1 OUT= SRC=54.171.83.143 DST=24.xx.xx.xx PROTO=TCP SPT=27791 DPT=32400

Aug 7 15:02:22 info [ 342.950000] '[DROPPED-PACKET]:'IN=eth0.1 OUT= SRC=54.171.83.143 DST=24.xx.xx.xx PROTO=TCP SPT=27791 DPT=32400

Aug 7 15:02:16 info [ 336.940000] '[DROPPED-PACKET]:'IN=eth0.1 OUT= SRC=54.171.83.143 DST=24.xx.xx.xx PROTO=TCP SPT=27791 DPT=32400

Aug 7 15:02:15 info [ 335.940000] '[DROPPED-PACKET]:'IN=eth0.1 OUT= SRC=54.171.83.143 DST=24.xx.xx.xx PROTO=TCP SPT=27791 DPT=32400

If these dropped packet log lines have anything to do with the issue, do you know what is the cause and how I can prevent such? When I don’t manually select the IP in Plex, they do not seem to appear in log.

Well done. It is the dropping of these packages that is causing the problem

Firewall / security setting in the router?

What router make / model?

Need to find all the security settings in the router to see which is leading to the packets being blocked

D-Link DIR-655 below is a screenshot of the firewall settings screen, I have not modified anything on it since restoring settings.

You have Enable SPI which you can read about here

looking up the others

User Manual
ftp://ftp.dlink.ru/pub/Router/DIR-655/Description/DIR-655_manual_A2_1%5B1%5D.01(EU).pdf

Page 41

Sounds like you need NAT ENDPOINT FILTERING to be Endpoint independent for TCP
I am not concerned about UDP for now - not for this issue

Do this change first
restart the router
and if problem remains then try disabling Enable SPI - but may be the NAT Endpoint filtering change is adequate

I changed NAT ENDPOINT FILTERING to be Endpoint Independent for TCP rebooted router without effect. Tried changing it to Address Restricted and rebooted router and it is staying connected for the first time ever. That setting looks like it is the same as Port and Address Restricted in that the incoming traffic must match the IP address of the outgoing connection as the manual mentions but the port does not have to match which I guess is what makes it work. Thanks for your help.

The 54.xx.xx.xx incoming connection attempts would not be responses to outgoing request to that IP.

What about this combination
Endpoint Independent for NAT Endpoint Filtering and not enabling SPI?

Ah I see, yeah I replied too soon, while remote access stayed connected longer than it had in past, it eventually lost remote access and when I checked the router log it had dropped the same connection again. Tried disabling SPI and checking Endpoint Independent for TCP and rebooted router it showed remote access momentarily then disconnected. Checked router log and it still showed it dropping connections from 54.xx.xx.xx.

Could it the 5 minute dropping of the port?

Endpoint Independent
Any incoming traffic sent to an open port will be forwarded to the application that opened the port. The port will close if idle for 5 minutes.

Anyway - i believe we are in the right area. is the router up to date with firmware?

Drastic action - resetting the router to factory defaults and recreating the dhcp reservations and port forward
Seeing also what the defaults end up as for SPI and NAT Filtering

Can we disable NAT Filtering as well as SPI

I am going to bed - it is almost 3am

I would not think it would have to do with the 5 minute thing as it connects and disconnects within 1-2 seconds. The router has the latest firmware. I already reset the router to factory defaults and recreated the dhcp reservations and port forward. The defaults are as they appear in following screenshot. I don’t see any option to try and disable NAT filtering but happy to try if you can advise where I can do so when you return. I’ll keep testing and if I figure out anything that works will update thread.

Pages 30 and 31 of the manual i linked earlier mention two similar features - one is Virtual Server and the other Port Forwarding - can you see what you have for Virtual Server - there is also Application Rules which appears to be Port Triggering -which we do not want

So we could try this
Instead of Port Forward setup - you can try Virtual Server setup
Name Plex Media Server
IP Address: 192.168.1.100
Public Port 32400
Private Port 32400
Traffic Type TCP
Schedule Always
Allow All

And delete the port forward and see if it is different behavior with Virtual Server

Other things to check out
On each tab selector in left hand column, go through and see what you have set

Application Rules - we do not want any Port Triggering (so nothing should be here)
Access Control Filters
Inbound Filter

At the end of the day you could ring DLINK support and say it is dropping these packets when i have no NAT End Point Filtering (i,e, set to Endpoint Independent for TCP) and have Enable SPI unticked

You are sure you did this right ? for TCP Endpoint / not UDP

Ok, I feel really dumb! It occurred to me that the router was simply acting like it was not applying the port forward I created so I went and verified the settings and then noticed the unlabeled column containing checkable boxes ( see port forward screenshot in first post) was not checked on the rule I created. That’s right, it was simply not enabled! I clicked the checkbox, saved and rebooted router and it has maintained a remote connection. While the column is unlabled and there is no mention of it in the manual on page 32 I now see a small note about it in the page that loads when one clicks the More … link so that is my bad for not reading it more carefully or just realizing that was what they were for. Thanks for your help, don’t think I would have gotten to this point had you not kept my hopes alive that we could solve this. :slight_smile: