Remote Access keeps disconnecting

@cwickstylz said:
I am, as well, currently having issues with this…

I have 2x IBM System X Servers, running PMS, with static IP addresses, a Meraki MX84 security appliance as my gateway, with properly forwarded ports (and open to the outside), yet PMS continues to have issues around remote access.

From what I have gathered thus far, PMS is having trouble using the static IP addresses for my primary network adapter(s), 10GbE with these links set at the highest priority & IPv4 Metric within Server 2016, yet for some odd reason, prefers to use another internal IP address(s) for PMS, rather than the primary 10GbE.

Example:
Host 10GbE IP address of 192.168.1.2 & fallback/Hyper-V 4GbE Bond (LACP) IP of 192.168.1.20, Plex likes the .20 address EVERY FRIGGIN TIME. No rhyme or reason, but I cannot create another rule on my Meraki, allowing for the same local port to be routed to another IP address, so I literally have to manually disable the .20 adapter, retry for remote access with it off, PMS finds & ok’s remote access, and then I flip the adaptor back on. Works for a while, but randomly PMS grabs the .20 address, again, and we start over.

No clue as to why PMS is preferring the Hyper-V adaptor with lower priority & higher IPv4 Metric within my infrastructure…

Any thoughts around this one guys?

On Windows you can get Plex Media Server to ignore a specific network card if you make sure it does not have a default gateway defined in tcp ip 4 properties.

@sa2000 said:

@cwickstylz said:
I am, as well, currently having issues with this…

I have 2x IBM System X Servers, running PMS, with static IP addresses, a Meraki MX84 security appliance as my gateway, with properly forwarded ports (and open to the outside), yet PMS continues to have issues around remote access.

From what I have gathered thus far, PMS is having trouble using the static IP addresses for my primary network adapter(s), 10GbE with these links set at the highest priority & IPv4 Metric within Server 2016, yet for some odd reason, prefers to use another internal IP address(s) for PMS, rather than the primary 10GbE.

Example:
Host 10GbE IP address of 192.168.1.2 & fallback/Hyper-V 4GbE Bond (LACP) IP of 192.168.1.20, Plex likes the .20 address EVERY FRIGGIN TIME. No rhyme or reason, but I cannot create another rule on my Meraki, allowing for the same local port to be routed to another IP address, so I literally have to manually disable the .20 adapter, retry for remote access with it off, PMS finds & ok’s remote access, and then I flip the adaptor back on. Works for a while, but randomly PMS grabs the .20 address, again, and we start over.

No clue as to why PMS is preferring the Hyper-V adaptor with lower priority & higher IPv4 Metric within my infrastructure…

Any thoughts around this one guys?

On Windows you can get Plex Media Server to ignore a specific network card if you make sure it does not have a default gateway defined in tcp ip 4 properties.

Unfortunately, if I remove the default gateway, I also lose Internet connectivity for all VM’s using that network adaptor. If the VM’s were just using internal connectivity this wouldn’t be a problem, but some do require outside network access to the Internet…

Without the gateway, the network adapter IP Address would need to be static and set as a DHCP Reservation in the router for that static IP Address - or an IP Address outside the DHCP Range but within the subnet.

Would this not work?

@sa2000 said:
Without the gateway, the network adapter IP Address would need to be static and set as a DHCP Reservation in the router for that static IP Address - or an IP Address outside the DHCP Range but within the subnet.

Would this not work?

Tried it. I have static IP’s set for both hosts, both network adaptors, so I can turn on or off DHCP & get the same result (in theory), but if I remove the gateway setting from an adaptor in Server 2016, that adaptor will no longer have a path outside the network to the Internet…

@cwickstylz said:

@sa2000 said:
Without the gateway, the network adapter IP Address would need to be static and set as a DHCP Reservation in the router for that static IP Address - or an IP Address outside the DHCP Range but within the subnet.

Would this not work?

Tried it. I have static IP’s set for both hosts, both network adaptors, so I can turn on or off DHCP & get the same result (in theory), but if I remove the gateway setting from an adaptor in Server 2016, that adaptor will no longer have a path outside the network to the Internet…

Thanks for the feedback. There is a feature request to make use of the metric value (priority)

Have you looked into swapping the connections round ? Knowing that PMS always picks the other one

@sa2000 said:

@cwickstylz said:

@sa2000 said:
Without the gateway, the network adapter IP Address would need to be static and set as a DHCP Reservation in the router for that static IP Address - or an IP Address outside the DHCP Range but within the subnet.

Would this not work?

Tried it. I have static IP’s set for both hosts, both network adaptors, so I can turn on or off DHCP & get the same result (in theory), but if I remove the gateway setting from an adaptor in Server 2016, that adaptor will no longer have a path outside the network to the Internet…

Thanks for the feedback. There is a feature request to make use of the metric value (priority)

Have you looked into swapping the connections round ? Knowing that PMS always picks the other one

That would be PHENOMENAL if you could somehow choose and/or use the IPv4 metric to essentially force PMS to use one adaptor or another! I’d venture a guess that this feature/functionality would certainly help with a LOT of the people on this thread, as I’m sure quite a few might have multiple adaptors & are maybe experiencing the very same issue I have here, but haven’t dug deep enough to figure out that it’s forcing the wrong adaptor on them, and then their port forwarding is meaningless, and so on…

I have not thought about switching the adaptors around, as I currently have redundant 10Gb links connecting into the core of my network, a pair of Juniper EX’s in a Virtual Chassis, and then I use the 4x onboard NICs, bound by LACP, 2x ports on each of the pair of Junipers, for switch redundancy. Is it brutal overkill, yes, absolutely, but is there a logical reason to use a 4Gb LAG vs. a 10Gb LAG (20Gb in theory, using LACP, Windows actually shows it as a 20Gb LAG)…no, would pretty much defeat the purpose & whole reasoning behind designing my Plex environment around 10Gb.

Thank you for all your feedback & certainly hope this feature request can make it into a build sooner, rather than later. It’s really a PITA having to constantly worry about remote access dropping, BUT thankfully I do have PlexPy setup, so through PushBullet, it will notify me, quite often, when remote access drops…

SO…I have some progress on this issue…

I have found that if you go into the Windows adaptor settings & set a lower metric for the adaptor you would like to use & a higher metric for the one you would like Plex to disregard, FOLLOWED by a CMD, with elevated privileges, “route /f” command to flush the routing tables, then a restart, PLEX WILL CHOOSE THE HIGHER METRIC’D ADAPTOR!!!

Whoo hoo!

Again, this could be a likely candidate for widespread connection issues with users that have multiple network adaptors, whether it’s something crazy like my LACP’d 4Gb Hyper-V links (4x 1GbE) being preferred over my 10Gb adaptor(s) or somebody with a simple desktop running PMS, that has an Ethernet port & wireless built in, where Windows decides, for whatever silly reason, it’s likes the wireless adaptor better…

Anyways, knock on wood, but the above appears to be working & forces PMS to use the adaptor I choose, persisting after a reboot.

Best of luck folks!

@cwickstylz said:
SO…I have some progress on this issue…

I have found that if you go into the Windows adaptor settings & set a lower metric for the adaptor you would like to use & a higher metric for the one you would like Plex to disregard, FOLLOWED by a CMD, with elevated privileges, “route /f” command to flush the routing tables, then a restart, PLEX WILL CHOOSE THE HIGHER METRIC’D ADAPTOR!!!

Whoo hoo!

Again, this could be a likely candidate for widespread connection issues with users that have multiple network adaptors, whether it’s something crazy like my LACP’d 4Gb Hyper-V links (4x 1GbE) being preferred over my 10Gb adaptor(s) or somebody with a simple desktop running PMS, that has an Ethernet port & wireless built in, where Windows decides, for whatever silly reason, it’s likes the wireless adaptor better…

Anyways, knock on wood, but the above appears to be working & forces PMS to use the adaptor I choose, persisting after a reboot.

Best of luck folks!

Thanks for the feedback. I have added it to the previous info for the development team. May be it re-ordered the list of adapters

I lied…It survived a reboot yesterday, but low & behold, I got a PushBullet notification waiting for me this AM from PlexPy that remote access was down on 1x host…and you guessed it, PMS wanted that other adaptor again!

Ugh…Yeah, please share with dev team on having PMS rely on IPv4 metric, as it’s truly a PITA constantly having to disable an adaptor to restore remote access…

Thanks!

I have the same issue as well. Everyday I have to remote access disconnects multiple times.

@SALTFAM said:
I have the same issue as well. Everyday I have to remote access disconnects multiple times.

You are probably using uPnP automatic port allocation rather than a manually specified public port and a port forward setup in the router.

There is a lot of evidence of the unreliability of the uPnP port mapping - this has been raised with the development team to see how to mitigate against the issues that arise because of, for example, routers taking too long to respond to SSDP searches.

The recommendation is to have a Port Forward in the router to local port 32400 and forward that to the local IP of the server, ensuring that this local IP address is reserved / permanent and also that the server has only one active IP Address. Then to manually specify the public port in the server remote access advanced settings

Nighthawk X10 R9000 plex keep disconnecting remote access everyday!
I have 2 more servers running in the same network i from my PC and the other is running on my Drobon5 with no issues at all!
recently got the Nighthawk X10 R9000 to run plex with different media for some friends and family but I notice that every morning remote access disconnects and I have to login to the router check settings and available remote still shows on but not available outside the network then I disable plex on the router then enable it again and voila! working again!
Current Plex version: 1.7.5.4035-313f93718 Jun 28, 2017 on the router.
I even try manually port but still the same problem and I don’t no if the problem is with the router or the server it self.

Hi Elan, nice to salute you, hopefuly i can get a little hand here, ive tried to enable remote server access, everything its set in the router, but it said connected and then suddenly it disconnects, im now sure what part of the log file has the issue, meanwhile im copying some part of the file:

Jul 30, 2018 21:41:04.257 [2592] VERBOSE - We want 60 seconds ahead, last returned was 411.202000 and max is 485.735000.
Jul 30, 2018 21:41:04.257 [2592] VERBOSE - It took 0.0 sec to serialize a list with 0 elements.
Jul 30, 2018 21:41:04.257 [6016] DEBUG - Completed: [::ffff:127.0.0.1:61286] 206 PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) 2ms 342 bytes (range: bytes=0-)
Jul 30, 2018 21:41:04.758 [6016] VERBOSE - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Jul 30, 2018 21:41:04.759 [6016] VERBOSE - Auth: Came in with the master token, authorization succeeded.
Jul 30, 2018 21:41:04.759 [5020] DEBUG - Request: [::ffff:127.0.0.1:61287 (Loopback)] PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) Signed-in Token (rochoventura)
Jul 30, 2018 21:41:04.759 [5020] VERBOSE - * User-Agent => Lavf/58.9.100
Jul 30, 2018 21:41:04.759 [5020] VERBOSE - * Accept => /
Jul 30, 2018 21:41:04.759 [5020] VERBOSE - * Range => bytes=0-
Jul 30, 2018 21:41:04.759 [5020] VERBOSE - * Connection => close
Jul 30, 2018 21:41:04.759 [5020] VERBOSE - * Host => 127.0.0.1:32400
Jul 30, 2018 21:41:04.759 [5020] VERBOSE - * Icy-MetaData => 1
Jul 30, 2018 21:41:04.760 [5020] VERBOSE - * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Jul 30, 2018 21:41:04.760 [5020] VERBOSE - * progress => 6.7
Jul 30, 2018 21:41:04.760 [5020] VERBOSE - * size => -22
Jul 30, 2018 21:41:04.760 [5020] VERBOSE - * remaining => -1
Jul 30, 2018 21:41:04.760 [5020] VERBOSE - We want 60 seconds ahead, last returned was 411.202000 and max is 485.735000.
Jul 30, 2018 21:41:04.760 [5020] VERBOSE - It took 0.0 sec to serialize a list with 0 elements.
Jul 30, 2018 21:41:04.761 [5136] DEBUG - Completed: [::ffff:127.0.0.1:61287] 206 PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) 1ms 342 bytes (range: bytes=0-)
Jul 30, 2018 21:41:05.264 [6016] VERBOSE - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Jul 30, 2018 21:41:05.264 [6016] VERBOSE - Auth: Came in with the master token, authorization succeeded.
Jul 30, 2018 21:41:05.264 [2592] DEBUG - Request: [::ffff:127.0.0.1:61288 (Loopback)] PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) Signed-in Token (rochoventura)
Jul 30, 2018 21:41:05.264 [2592] VERBOSE - * User-Agent => Lavf/58.9.100
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * Accept => /
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * Range => bytes=0-
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * Connection => close
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * Host => 127.0.0.1:32400
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * Icy-MetaData => 1
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * progress => 6.7
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * size => -22
Jul 30, 2018 21:41:05.265 [2592] VERBOSE - * remaining => -1
Jul 30, 2018 21:41:05.266 [2592] VERBOSE - We want 60 seconds ahead, last returned was 411.202000 and max is 485.735000.
Jul 30, 2018 21:41:05.266 [2592] VERBOSE - It took 0.0 sec to serialize a list with 0 elements.
Jul 30, 2018 21:41:05.266 [6016] DEBUG - Completed: [::ffff:127.0.0.1:61288] 206 PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) 2ms 342 bytes (range: bytes=0-)
Jul 30, 2018 21:41:05.588 [6016] VERBOSE - WebSocket: processed 1 frame(s)
Jul 30, 2018 21:41:05.771 [6016] VERBOSE - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Jul 30, 2018 21:41:05.771 [6016] VERBOSE - Auth: Came in with the master token, authorization succeeded.
Jul 30, 2018 21:41:05.772 [0540] DEBUG - Request: [::ffff:127.0.0.1:61289 (Loopback)] PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) Signed-in Token (rochoventura)
Jul 30, 2018 21:41:05.772 [0540] VERBOSE - * User-Agent => Lavf/58.9.100
Jul 30, 2018 21:41:05.772 [0540] VERBOSE - * Accept => /
Jul 30, 2018 21:41:05.772 [0540] VERBOSE - * Range => bytes=0-
Jul 30, 2018 21:41:05.772 [0540] VERBOSE - * Connection => close
Jul 30, 2018 21:41:05.772 [0540] VERBOSE - * Host => 127.0.0.1:32400
Jul 30, 2018 21:41:05.773 [0540] VERBOSE - * Icy-MetaData => 1
Jul 30, 2018 21:41:05.773 [0540] VERBOSE - * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Jul 30, 2018 21:41:05.773 [0540] VERBOSE - * progress => 6.7
Jul 30, 2018 21:41:05.773 [0540] VERBOSE - * size => -22
Jul 30, 2018 21:41:05.773 [0540] VERBOSE - * remaining => -1
Jul 30, 2018 21:41:05.773 [0540] VERBOSE - We want 60 seconds ahead, last returned was 411.202000 and max is 485.735000.
Jul 30, 2018 21:41:05.774 [0540] VERBOSE - It took 0.0 sec to serialize a list with 0 elements.
Jul 30, 2018 21:41:05.774 [5136] DEBUG - Completed: [::ffff:127.0.0.1:61289] 206 PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) 2ms 342 bytes (range: bytes=0-)
Jul 30, 2018 21:41:06.275 [6016] VERBOSE - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Jul 30, 2018 21:41:06.276 [6016] VERBOSE - Auth: Came in with the master token, authorization succeeded.
Jul 30, 2018 21:41:06.277 [5020] DEBUG - Request: [::ffff:127.0.0.1:61290 (Loopback)] PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) Signed-in Token (rochoventura)
Jul 30, 2018 21:41:06.277 [5020] VERBOSE - * User-Agent => Lavf/58.9.100
Jul 30, 2018 21:41:06.277 [5020] VERBOSE - * Accept => /
Jul 30, 2018 21:41:06.278 [5020] VERBOSE - * Range => bytes=0-
Jul 30, 2018 21:41:06.278 [5020] VERBOSE - * Connection => close
Jul 30, 2018 21:41:06.278 [5020] VERBOSE - * Host => 127.0.0.1:32400
Jul 30, 2018 21:41:06.278 [5020] VERBOSE - * Icy-MetaData => 1
Jul 30, 2018 21:41:06.278 [5020] VERBOSE - * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Jul 30, 2018 21:41:06.279 [5020] VERBOSE - * progress => 6.7
Jul 30, 2018 21:41:06.279 [5020] VERBOSE - * size => -22
Jul 30, 2018 21:41:06.279 [5020] VERBOSE - * remaining => -1
Jul 30, 2018 21:41:06.280 [5020] VERBOSE - We want 60 seconds ahead, last returned was 411.202000 and max is 485.735000.
Jul 30, 2018 21:41:06.280 [5020] VERBOSE - It took 0.0 sec to serialize a list with 0 elements.
Jul 30, 2018 21:41:06.280 [5136] DEBUG - Completed: [::ffff:127.0.0.1:61290] 206 PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) 4ms 342 bytes (range: bytes=0-)
Jul 30, 2018 21:41:06.786 [6016] VERBOSE - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Jul 30, 2018 21:41:06.786 [6016] VERBOSE - Auth: Came in with the master token, authorization succeeded.
Jul 30, 2018 21:41:06.787 [4120] DEBUG - Request: [::ffff:127.0.0.1:61291 (Loopback)] PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) Signed-in Token (rochoventura)
Jul 30, 2018 21:41:06.787 [4120] VERBOSE - * User-Agent => Lavf/58.9.100
Jul 30, 2018 21:41:06.787 [4120] VERBOSE - * Accept => /
Jul 30, 2018 21:41:06.787 [4120] VERBOSE - * Range => bytes=0-
Jul 30, 2018 21:41:06.787 [4120] VERBOSE - * Connection => close
Jul 30, 2018 21:41:06.788 [4120] VERBOSE - * Host => 127.0.0.1:32400
Jul 30, 2018 21:41:06.788 [4120] VERBOSE - * Icy-MetaData => 1
Jul 30, 2018 21:41:06.788 [4120] VERBOSE - * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Jul 30, 2018 21:41:06.788 [4120] VERBOSE - * progress => 6.7
Jul 30, 2018 21:41:06.788 [4120] VERBOSE - * size => -22
Jul 30, 2018 21:41:06.788 [4120] VERBOSE - * remaining => -1
Jul 30, 2018 21:41:06.789 [4120] VERBOSE - We want 60 seconds ahead, last returned was 411.202000 and max is 485.735000.
Jul 30, 2018 21:41:06.789 [4120] VERBOSE - It took 0.0 sec to serialize a list with 0 elements.
Jul 30, 2018 21:41:06.789 [5136] DEBUG - Completed: [::ffff:127.0.0.1:61291] 206 PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) 3ms 342 bytes (range: bytes=0-)
Jul 30, 2018 21:41:07.295 [6016] VERBOSE - Auth: We found auth token (xxxxxxxxxxxxxxxxxxxx), enabling token-based authentication.
Jul 30, 2018 21:41:07.295 [6016] VERBOSE - Auth: Came in with the master token, authorization succeeded.
Jul 30, 2018 21:41:07.295 [5020] DEBUG - Request: [::ffff:127.0.0.1:61292 (Loopback)] PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) Signed-in Token (rochoventura)
Jul 30, 2018 21:41:07.295 [5020] VERBOSE - * User-Agent => Lavf/58.9.100
Jul 30, 2018 21:41:07.295 [5020] VERBOSE - * Accept => /
Jul 30, 2018 21:41:07.295 [5020] VERBOSE - * Range => bytes=0-
Jul 30, 2018 21:41:07.295 [5020] VERBOSE - * Connection => close
Jul 30, 2018 21:41:07.295 [5020] VERBOSE - * Host => 127.0.0.1:32400
Jul 30, 2018 21:41:07.295 [5020] VERBOSE - * Icy-MetaData => 1
Jul 30, 2018 21:41:07.296 [5020] VERBOSE - * X-Plex-Token => xxxxxxxxxxxxxxxxxxxx
Jul 30, 2018 21:41:07.296 [5020] VERBOSE - * progress => 6.7
Jul 30, 2018 21:41:07.296 [5020] VERBOSE - * size => -22
Jul 30, 2018 21:41:07.296 [5020] VERBOSE - * remaining => -1
Jul 30, 2018 21:41:07.296 [5020] VERBOSE - We want 60 seconds ahead, last returned was 411.202000 and max is 485.735000.
Jul 30, 2018 21:41:07.296 [5020] VERBOSE - It took 0.0 sec to serialize a list with 0 elements.
Jul 30, 2018 21:41:07.296 [5136] DEBUG - Completed: [::ffff:127.0.0.1:61292] 206 PUT /video/:/transcode/session/htlucf7edgdo5oc146n30a47/bd8db21f-d813-4358-ba06-807126d71cd4/progress?progress=6.7&size=-22&remaining=-1 (18 live) 1ms 342 bytes (range: bytes=0-)

wel im not going to switch my internet provider the provider where im now at has almost no single dc issue and good speed i know it’s not my fault it worked befor great it starts appearing with new plex updates it’s on there side not ours.

This happens to me all the time. Usually after a software update. I can usually get it fixed by resetting my UPnP (disable/enable) but this time I can’t and have been having issues for a week or more.

The Plex server never crashes and my uptime is unquestionable. If you want logs, just tell me where to look.

And by software update, I mean Plex server software.

SOLUTION that worked for me.

I have windows 10 1903. Plex 4.20.2 - Pretty new OS and server version installed Feb 2020 from bare metal. Linksys WRT 1900 doing the routing/fw duties.

So, I tried everything in this thread, nothing was working for me. I would get the symptom where it goes green then red.

What ended up working was putting a port FORWARD instead of just same port to same port. I was using 32400 for both inside and outside ports, but when i put 4044 inside (applied to the plex server) and had my fw translate that port to 32400 on the outside (internet) then it stuck and has not gone back since.

Also in my win10 fw i put the exe to be allowed, not the port. That prob didnt matter but at any rate don’t forget your local OS FW!