Plex Constantly Loses Remote Access

Mine started in again don’t know why but for some very odd reason it wont let me DL the logs again, not going to struggle with it again ATM but I just looked at your logs you posted and added a UPNP IGD SNMP-UDP router rule and it fixed my Remote Access from popping off and on and from continually having to disable and re-enable to get it to connect, once I get my logs I’ll get them to you. Thanks for the help and assist.

So I ended up manually unpublishing and republishing the server every hour via a script. By no means a permanent solution, but it works.

Ill give that a go myself and see how it goes, I just dont understand why its suddenly started happening Ive never had the issue before up until the last month or so, and pretty much rebuilt my whole server from scratch and it worked for a bit, and then it started again, so weird!

Have been looking at the logs which cover Jan 21, 2019 05:35 to Jan 22, 2019 04:49

It looks like either some security block on WAN requests from outside to WAN port 32400 or the port forward in the router is no longer in place or going elsewhere

It should be a port forward for

  • Protocol tcp
  • forward wan/public port 32400 to lan/private port 32400 and passing it to 192.168.0.4

These logs extracts show the times when your public IP was not reachable through public port 32400 - which suggest either a firewall issue or the port forward in the router not done or lost

Jan 21, 2019 05:35:27.152 [0x70000e5be000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="9aa2395e-a9ba-4d8f-a0c6-c3384073caf3" connectivity="0" command="notifyConnectivity"/>'
Jan 21, 2019 05:37:24.294 [0x70000e5be000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="0304e063-7b5d-4ad1-b886-4f8c06680a2c" connectivity="0" command="notifyConnectivity"/>'
Jan 21, 2019 05:37:34.260 [0x70000e641000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="bb39b842-68e0-4d27-8464-f700e3185a77" connectivity="0" command="notifyConnectivity"/>'
Jan 21, 2019 05:37:42.624 [0x70000e641000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="855e6769-ac3c-4659-ad12-288e25c8910f" connectivity="0" command="notifyConnectivity"/>'
Jan 21, 2019 05:37:51.326 [0x70000e641000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="7db7be97-80fa-4e7e-8abc-fbcee77486aa" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:21:52.263 [0x70000e917000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="c161189c-e84d-44e6-af96-e85a50da6f92" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:23:51.199 [0x70000e99a000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="442d77d6-4030-4053-af21-149771c84b36" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:24:04.252 [0x70000e99a000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="a2174e03-187a-4953-bbd4-0982e4f2fcec" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:24:15.206 [0x70000e99a000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="3e63afb0-9fd0-488a-b983-5a81aed16dad" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:24:56.581 [0x70000fdee000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="1ac3fbe0-82a2-4f71-9547-280018575131" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:24:57.040 [0x70000fd6b000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="e9d58964-408a-47b3-a2a1-d695218bfac2" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:25:23.812 [0x70000fdee000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="40e75d5b-96da-4a79-818d-bc40f8165cdb" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:25:32.311 [0x70000fdee000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="c221571c-3fbe-4077-b315-ebbd81fe1082" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:25:39.190 [0x70000fdee000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="c95f8f76-b912-4722-ba5f-74bfed00fd9f" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:26:43.261 [0x70000fdee000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="0d16433c-5c21-4470-a787-f56aaf53ce67" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:26:54.289 [0x70000fd6b000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="079c8562-ddbc-4880-8ead-91e8dfaf7f80" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:27:05.183 [0x70000fdee000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="398ffc44-a295-420b-9e0d-b180e659af94" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:28:43.482 [0x70000fd6b000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="2a3156ca-3bdd-4e48-a2dd-9ba1cd7ffbe6" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:41:59.131 [0x70000fd6b000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="3c8e088d-eec1-4e69-9003-b8ebddb7b520" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:42:11.330 [0x70000fd6b000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="c4720612-8d49-482c-871b-0eb785cf0c2d" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:44:02.273 [0x70000fdee000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="b1720eb2-6313-4e6f-a9c3-9b57dac766a3" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:44:15.537 [0x70000fd6b000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="949aa3ba-7c12-49fb-85b5-b7c39170f3db" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:44:25.217 [0x70000fd6b000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="f552bad5-42f3-4ddc-9552-0d0c2dfb117f" connectivity="0" command="notifyConnectivity"/>'
Jan 22, 2019 04:44:33.503 [0x70000fd6b000] DEBUG - EventSource: Got event [data] '<Message address="84.209.xxx.xxx" port="32400" asyncIdentifier="db09907c-7f10-47b5-a4d3-d8719427475b" connectivity="0" command="notifyConnectivity"/>'

An observation - when disabling / enabling remote access or when clicking retry - please make sure you wait at least 30 seconds between clicks. There are timing issues and if you repeat the action with few seconds then may get failure to etsablish remote access. Whilst I could see that in the logs where repeated attempts within 3 seconds of previous attempt, it was not a factor in the problem

The server which is on 192.168.1.225 sends outan SSDP UDP Search Request on the local network and it is looking for a response from the main router identifying itself as the IGD and can then be configured to setup the automatoc port mapping. It looks like 192.168.1.2 responded but not the main router (which i presume is either 192.168.1.1 or 192.168.1.254)

you can avoid using automatic port mapping by

  • ensuring 192.168.1.225 IP never changes (DHCP Reservation etc…)
  • select a wan port to use which could be 32400 and forward it to local port 32400 for tcp to 192.168.1.225
  • in server settings for remote access / show advanced, tick the manually specify port and enter the wan port you decided to use and then retry and disable / enable remote access

Hi @sa2000

I forgot to report back to you, but I spent hours on my router and finally managed to do a Port Forward for Plex. Now, I never lose remote access and the icon is always green.

I have a Verizon Fios router and had to create a static IP for my desktop PC plex server first, and then open up a port. Then it has managed to stay stable!

Thank you @sa2000 for your help and reading my logs and also how much you are helping all other Plexers.

Unfortunately, that’s not what happens. It NEVER makes a remote connection possible. It simply says it’s not reachable outside my network.
It has ALWAYS been this way, I have never, in 9 months to a year, been able to connect outside.
And I went through the blogs suggestions. Step. By. Step.
No avail.
I honestly am at a loss.

I just bought a Lifetime Plex Pass because I wanted remote access. I can’t get it to work though. Hopefully I didn’t waste my money.

hoping someone can help me, as my remote access connection has gone from stable to intermittent to not available.

can someone please assist? attached are the logs

i’m currently running version Version 1.14.1.5488

i read briefly above to roll back to another version, but could not find a link. is that still working?

thanks!
p.s. while I am fairly familiar with technology, much of the deeper tech terms I am unfamiliar with. so please be patient with me.

Logs.zip (10.5 MB)

Is uPnP enabled in the router ? All attempts to auto map a port are failing

Jan 31, 2019 19:38:18.013 [11440] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:38:24.174 [11440] WARN - NAT: UPnP, error mapping port 29618, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:38:24.425 [11440] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:38:24.972 [11440] WARN - NAT: UPnP, error mapping port 10085, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:38:25.963 [8744] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:38:32.026 [8744] WARN - NAT: UPnP, error mapping port 24065, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:38:32.277 [8744] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:38:32.796 [8744] WARN - NAT: UPnP, error mapping port 11493, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:38:49.125 [4604] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:38:53.278 [4604] WARN - NAT: UPnP, error mapping port 19135, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:38:53.531 [4604] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:38:54.086 [4604] WARN - NAT: UPnP, error mapping port 12756, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:38:57.822 [8744] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:39:03.234 [8744] WARN - NAT: UPnP, error mapping port 23034, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:39:03.485 [8744] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:39:04.034 [8744] WARN - NAT: UPnP, error mapping port 24072, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:39:07.051 [4604] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:39:10.800 [4604] WARN - NAT: UPnP, error mapping port 15638, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:39:11.052 [4604] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:39:11.608 [4604] WARN - NAT: UPnP, error mapping port 18232, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:39:15.173 [3332] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:39:20.778 [3332] WARN - NAT: UPnP, error mapping port 20920, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:39:21.031 [3332] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:39:21.580 [3332] WARN - NAT: UPnP, error mapping port 28151, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:40:27.954 [8744] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:40:31.855 [8744] WARN - NAT: UPnP, error mapping port 12744, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:40:32.107 [8744] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:40:32.625 [8744] WARN - NAT: UPnP, error mapping port 15334, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:41:30.362 [10216] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:41:36.395 [10216] WARN - NAT: UPnP, error mapping port 29286, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:41:36.648 [10216] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:41:37.192 [10216] WARN - NAT: UPnP, error mapping port 14834, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:41:47.620 [3332] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:41:54.663 [3332] WARN - NAT: UPnP, error mapping port 19301, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:41:54.915 [3332] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:41:55.685 [3332] WARN - NAT: UPnP, error mapping port 25834, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:46:28.299 [14768] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:46:34.120 [14768] WARN - NAT: UPnP, error mapping port 23597, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:46:34.372 [14768] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:46:34.888 [14768] WARN - NAT: UPnP, error mapping port 19634, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:46:59.264 [14716] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:47:02.986 [14716] WARN - NAT: UPnP, error mapping port 28508, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:47:03.237 [14716] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:47:03.814 [14716] WARN - NAT: UPnP, error mapping port 11522, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:47:36.784 [14768] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:47:41.867 [14768] WARN - NAT: UPnP, error mapping port 15747, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:47:42.119 [14768] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:47:42.812 [14768] WARN - NAT: UPnP, error mapping port 17518, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:47:45.236 [14716] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:47:49.481 [14716] WARN - NAT: UPnP, error mapping port 29947, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:47:49.733 [14716] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:47:50.313 [14716] WARN - NAT: UPnP, error mapping port 10064, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:48:01.188 [14772] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:48:06.237 [14772] WARN - NAT: UPnP, error mapping port 26738, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:48:06.489 [14772] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:48:07.013 [14772] WARN - NAT: UPnP, error mapping port 27291, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:49:14.494 [9252] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:49:20.803 [9252] WARN - NAT: UPnP, error mapping port 29303, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:49:21.056 [9252] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:49:21.579 [9252] WARN - NAT: UPnP, error mapping port 18870, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:59:11.708 [4320] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:59:19.905 [4320] WARN - NAT: UPnP, error mapping port 19267, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Jan 31, 2019 19:59:20.156 [4320] DEBUG - NAT: UPnP, attempting port mapping.
Jan 31, 2019 19:59:22.835 [4320] WARN - NAT: UPnP, error mapping port 18033, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Check router uPnP status and ensure it is enabled.
If you cannot get uPnP to work, switch to a manual setup

  1. Make sure the 192.168.1.6 IP Address of the server is a DHCP Reservation in the roiuter
  2. Choose a public port to manually forward to the server. I will pick 32430 as an example
  3. Go to the Port Forward menu in the router (not Port Triggering but Port Forwarding)
  4. Set up this rule
    Port Forward, protocol = tcp, wan/public port = 32430, lan/private port 32400, forward to 192.168.1.6
    5, Save changes and ensure it is enabled
  5. Go to server settings in Plex Web and select remote access settings and Show Advanced.
  6. Tick Manually Specify Port and enter 32430 in the box. Click retry and then re-enable Remote Access

(You may need to create a firewall rule
inbound port rule
Protocol = tcp
programs = any
remote port = any
local port = 32400
remote IP = any

thanks for the quick response.
I do have UPnP enabled. I attached some screenshots. But I think I got by unchecking "Enable Automatic Cleanup of Old Unused UPnP Services, and changing the WAN Connection Publication to the one not shown in the screenshot.

The screenshot you got for Port Forwarding - does that include both manually setup Port Forwards and uPnP ones as well? How many show up for 192.168.1.6 ? The screen chopped off - may be the router reached a limit on number of uPnP port forwards

See how many show up for 192.168.1.6:32400 - Perhaps need to delete some or reboot the router and see what happens

I had this Remote Access problem a couple updates ago. It was patched a few weeks later. Now after updating to the latest release, this bug is back again.

@sa2000
I’m showing 256 instances of 192.168.1.6:32400.

I’ve rebooted several times, but that did not do anything. I thought about deleting those, but wasn’t sure. Can I delete them all?

That could be the problem.

The uPnP automatic port mapping is supposed to be temporary and they should not persist and should disappear after rebooting the router. If they are being created as permanent then that is wrong and we need to establish if this is an issue at Plex end or in the router.

So the same 256 mappings show up after rebooting the router? Or are they different set of 256 mappings?

Could you look into using wireshark to capture the port mapping sequence from Plex Media Server. Wireshark can be downloaded from here Wireshark · Download

Could you delete a couple of these 256 192.168.1.6:32400 mappings and save screenshots of the remaining 254 so i can easily identify new ones. Then run wireshark to capture all packets and go through disable /enable remote several times - keep a gap of 1 minute between each and at least 30 seconds between disable and enable.

At the end of that stop the wireshark capture and download the server logs and get screenshots of the port mappings in the router for 192.168.1.6:32400 - save the wireshark capture as pcap and note down the time for start and end of capture and zip the pcap and send me privately by private message/ And would need the logs zip and screenshots

Thanks

@sa2000 Thank you for the diligence keeping up with responses in this thread - it certainly takes time to dig through all of the logs and determine environmental variables that normally cause remote connectivity issues. The root cause sounds like a difficult problem to pinpoint, but I’d like to do my best in helping troubleshoot and provide meaningful feedback in hopes to find a solution.

I’ll provide some background on my connection, and start by saying I’ve designed L3-L7 WAN architectures for almost two decades. It takes me a while to report here on the forums until I’ve exhausted all efforts over time. As this relevant thread dates back to July 2018 with 8,700 views (thanks @slashmanmusic), I assume most appropriate to append my similar woes here - which have continued well over 6 months since the later PMS builds:

WAN/LAN/Host Architecture:

  1. WAN = 1Gb synchronous Google Fiber with consistent 910+ Mbps up/down // Mikrotik HEX router w/ public static IP on WAN interface inbound static NAT forward (redirect) TCP -> 32400 (static private IP of NAS running PMS). UPnP disabled & no double-NAT. I use a PoE L3 switch to trunk VLAN2 & CoS3 on Fiber Jack / Untagged VLAN2 on Router WAN port to eliminate use of primitive Google Fiber box.
  2. LAN = All devices gigabit CAT6 // private subnet: 10.10.X.X - outbound SrcNAT to public static IP on Mikrotik WAN interface. Very stable network with no connectivity issues outbound or inbound to other services including those also hosted on same NAS.
  3. Host = Synology DS918+ DSM 6.2.1 U4 BTRFS // Single LAN interface MTU 1500 with private static IP on 10.10.X.X // PMS 1.13.9.5456 (downgraded weeks back for a bit more stability) // Docker running Tautulli (no autocheck) // ETH0 manually selected in PMS “Preferred Network Interface” // NAS powered up 8AM - 2AM CST weekdays, 24/7 weekends.

SYMPTOMS
Similar to others on this thread, all external clients (60+ users) that manually put in my public IP/port can always connect with any Plex app. Those that rely purely on the Plex client to report the server address are unable to connect after approx. 4-8 hours of the server being online. PMS consistently connects HTTPS to 45.33.118.95 / pubsub02.pop.dfw.plex.bz

  • After 8 hours or less, when PMS starts showing “unavailable outside your network…”, and confirmed unavailable to everyone externally - it still has an active TCP 443 connection to pubsub02.pop.dfw.plex.bz… but also has created an separate TCP 443 connection to: 69.164.196.66 / relay03.pop.dfw.plex.bz.

  • If I click “Retry” in PMS remote access , it creates an additional TCP 443 to pubsub02.pop, removes the relay03.pop TCP connection… and issues a FIN to the original pubsub02.pop TCP connection. External Plex clients are now able to connect again - but only for another 4-8 hours.

TROUBLESHOOTING
I’ve tried many different tactics over several months, including changing back to TCP 32400 externally (no redirect), upgrading to latest public PMS release, NAS on 24/7, switching PMS preferred interface setting to “Any” vs “ETHO”, stopping Tautulli/Docker, scheduled router reboots, and changing TCP timeout values. None have made a difference.

@sa2000 I can PM logs to you when needed. Hopefully some of this data can provide insight.

thanks again for keeping with me and the thorough feedback.
after rebooting, those same mappings remained.

I deleted three mappings, and nothing seems to have changed (aside I’m now showing 253 mappings).

I’ll look into running the wireshark for you next week.

but as I stated earlier, the change I made to the UPnP seemed to have done the trick. But I still may delete out all of those mappings. it could be due to the “Enable Automatic Cleanup of Old Unused UPnP Services” is now unchecked or the “WAN Connection Publication” is set to “Publish only the main wan connection”

hopefully this will help others.

So with 253 entries only. disabling and re-enabling remote access still failed in same way as before with same error in the log?
WARN - NAT: UPnP, error mapping port xxxxx, error: Action Failed, controlURL: http://192.168.1.1:2555/upnp/1e6f331b-073f-a078-1aa5a57bd5ca135a/WANIPConn1.ctl.

Sorry I missed that. What change and are you saying remote access port mapping now working ? I am a bit confused here

It was my understanding that the mapping had a lifetime and an expiry period and that is what i wanted to see from the wireshark (and corresponding logs). Every hour we refresh the port mapping to avoid expiry - so may need wireshark for more than an hour to see what happens !

So what change do you observe in the list of uPnP mappings between Cleanup of Old Unused UPnP Services being ticked or unticked ? Is there a write-up about it in the user manual for the router?

Do you have multiple WAN connections? This should not matter if there is on;y one

Thank you for the detailed investigation. Issues could be due to different causes. I am always on the lookout for potential issues with the pubsub servers as we did have a problem months ago. The Plex client apps may start a server relay connection just to check the route or in event of failure to get a response in a given time. The relay connection would get closed down if not needed

With regards to pubsub, the P,lex Media Server picks the fastest georgraphically aligned server and this may get changed to another server later

The issues I am looking for are where we have a connection to a pubsub server but the periodic events are not received or when we ask for a connectivity we do not get an event for the outcome - whether successful or not.

so the only change I made to get it to work was unchecking “Enable Automatic Cleanup of Old Unused UPnP Services”. this change suddenly made my server visible outside my network. I got there by just trying different combinations.