Remote Connection Always Indirect; Port Test Green for Split Second then Red

General Discussions
1

I had a computer failure so I had to completely rebuild my plex server from scratch. Luckily had backups of everything so restoring it was simple, except for this one issue.

Plex version: 1.7.6.4058
Debian 9 fresh install

  • Under Server–>Remote Access it says “Not available outside your network”.
  • I have manually specify public port checked and on 32400.
  • Port forwarded on router and online tests confirm it is open and forwarded correctly
  • Confirmed I do not have a double NAT issue
  • When I click “RETRY” button on the Remote Access Page, it tests the port, completes and turns green for a split second. Then it turns red
  • I tried enabling UPNP on my router, unchecked the manually port and reboot the server. UPNP port opens on router, but Plex still says Remote Connection Not available.

What I found happens is Plex will route my connection through some Linode server they have to still allow streaming, but the quality is poor compared to what happens with a direct stream.

Without going into it, this also causes issue with my Wake on Land setup for Plex. Because the connections are indirect through Linode, my router doesn’t detect the Plex request on the correct port, so the WOL command is never issued.

Is this a know issue? Any thoughts or a previous version that might correct this issue?

Please note, I have not had to change anything else on my network except the Plex server. All router setup and forwarding was working perfectly.

2
3

Thanks for the response. My router has plex.direct part of its domain whitelist, and this is my routers DNS setup (already rebooted). This is the default setup for OpenWRT router with my ISP added at the end. These are the router settings I’ve been using for 8 months with no issue.

DNS forwardings
127.0.0.1#5300
/0.openwrt.pool.ntp.org/8.8.8.8
/1.openwrt.pool.ntp.org/8.8.8.8
/2.openwrt.pool.ntp.org/8.8.8.8
/3.openwrt.pool.ntp.org/8.8.8.8
74.40.74.40
74.40.74.41

4

The point is to not use the DNS server of your provider. Because provider’s DNS server often don’t resolve domains on the .direct TLD reliably.

Are you using custom domains, VPNs or custom encryption certificates? Reverse Proxies etc pp ?

5

Understood. I replaced 74.40.74.40 and 74.40.74.41 with 8.8.8.8 and 8.8.4.4, but still no luck. I added those provider IPs a month ago b/c I was having DNS issues until they were added.

And I didn’t setup anything extra on this server like VPN or custom certificates. I did the basic Debian 9 install, installed the newest plex server software, and then did a restore of my plex data backup. Everything worked immediately except this Remote Access part.

Searching the forums seems like this issue has come up a lot lately.

6

I get this in my Plex Media Server.log when I run the test. I do not use NAT-PMP or uPNP, so this might be a normal message since it’s a manual port foward.

Jul 26, 2017 14:11:00.804 [0x7fb51ffff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (2e5c55a3-3283-48fb-9fa0-3543ad781fef, expected 4a0044f3-d429-42b5-be56-a53bc7b5d521)
Jul 26, 2017 14:11:03.876 [0x7fb5193fe700] WARN - NAT: PMP, got an error: Not Supported by gateway.

7

pinging @ChuckPA because I am not a Linux guy.

8

NAT-PMP… Not supported by gateway tells me it’s attempting to use UPnP. The best method to use is static port forwarding from the modem/router.

Before committing to this approach, I would like to see the full logs ( dialog between PMS and the router ) in this sequence.

Turning green and then red is an indicator of the connection but the Async ID changes the indicator. If PMS were static ported at this point, shutting down, restarting, and letting it come back to green on its own, for a few ping sessions will cement it.

9

Did you activate jumbo packets?

What size is your MTU on the server?
What is the maximum usable packet size you can send over your internet connection without getting fragmentation?
http://www.dslreports.com/faq/695

10

@ChuckPA : I don’t know why it would try UPnP? I have manually specify port checked. I will turn on debug and run a port test and post the contents of Plex Media Server.log after.

@OttoKerner I didn’t enable jumbo packets or change any default network stuff. That is all beyond me. Running that ping on the page returned results:

plex@plexbox:/var/log$ ping -s 1472 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1472(1500) bytes of data.
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=52 time=36.5 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=52 time=35.5 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=52 time=36.5 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=52 time=36.5 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=5 ttl=52 time=34.6 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=6 ttl=52 time=35.5 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=7 ttl=52 time=36.1 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=8 ttl=52 time=35.1 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=9 ttl=52 time=36.0 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=10 ttl=52 time=37.0 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=11 ttl=52 time=35.9 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=12 ttl=52 time=33.8 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=13 ttl=52 time=34.6 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=14 ttl=52 time=42.2 ms
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=15 ttl=52 time=36.6 ms

11

@nbyloff said:
@OttoKerner I didn’t enable jumbo packets or change any default network stuff. That is all beyond me. Running that ping on the page returned results:
plex@plexbox:/var/log$ ping -s 1472 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1472(1500) bytes of data.
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=52 time=36.5 ms

That appears to look normal.
I’ll leave to @ChuckPa, because my knowledge is exhausted now.

12

@ChuckPA: Attached the log entries when I clicked retry port. UPNP has been disabled on the router for months. I can re-enable it if you’d like me to test something. Also, I don’t see any personal info below, hopefully I cleaned it all out. :smile:

edit Removed file

13

I would like you to turn on Debug logging and restart PMS. This provides me with the most information about its actions.
After the reboot, Please collect the full set (Settings - Server - Help - Download Logs) and attach the ZIP file here. I will be able to see the history of the last 5 restarts and what you’ve attempted along with the results.

14

@ChuckPA : attached logs. I’ll remove these log files from this post once you have what you need.

Edit: Log files removed by Moderator at user request

15

Thank you for those logs… Having been ‘info’ mode. I see nothing of what has been happening. They all short and without much information except the oldest one.

It contains:

Jul 25, 2017 21:38:46.047 [0x7f61497fe700] INFO - Plex Media Server v1.7.6.4058-8fa494d15 - ubuntu PC x86_64 - build: linux-ubuntu-x86_64 ubuntu - GMT -05:00
Jul 25, 2017 21:38:46.048 [0x7f61497fe700] INFO - Linux version: 4.9.0-3-amd64 (#1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26)), language: en-US
Jul 25, 2017 21:38:46.048 [0x7f61497fe700] INFO - Processor AMD Ryzen 5 1600 Six-Core Processor            
Jul 25, 2017 21:38:46.048 [0x7f61497fe700] INFO - /usr/lib/plexmediaserver/Plex Media Server
Jul 25, 2017 21:38:46.136 [0x7f6145ffd700] INFO - Successfully retrieved OCSP response
Jul 25, 2017 21:38:48.023 [0x7f6142ffd700] INFO - LibraryUpdateManager path watching is disabled
Jul 25, 2017 21:38:49.170 [0x7f6140ffd700] INFO - Sync: downloaded 0 sync list(s) with 0 sync items(s): 0 new, 0 updated, 0 deleted
Jul 25, 2017 21:38:49.449 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (955d0e41-df81-494a-b694-5e663b7d1b3c, expected 909bb7d4-eb9e-4d1d-9b5c-f7fc3a5bf3c1)
Jul 25, 2017 21:38:51.276 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (75eb1fc8-c589-4f7d-8ca0-06dffa598e1e, expected fdc89a74-f2f5-4ff2-9b7b-b8c438687b68)
Jul 25, 2017 21:38:55.754 [0x7f61313ff700] ERROR - [PlexRelay] kex protocol error: type 7 seq 11
Jul 25, 2017 21:38:56.267 [0x7f61343ff700] INFO - [PlexRelay] Allocated port 1165 for remote forward to localhost:32401
Jul 25, 2017 21:39:04.854 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (b6058d2e-3424-4a29-95b9-91de377c9828, expected 197deb4f-7151-4de2-bf8c-e38eed971ffd)
Jul 25, 2017 21:39:06.335 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (197deb4f-7151-4de2-bf8c-e38eed971ffd, expected f4e891ce-05c6-4b46-8061-49b92b71008f)
Jul 25, 2017 21:39:07.534 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (2f132494-4bcd-4aad-a1ad-6e537dccf41a, expected 2e7a90f1-f383-48e8-a9ac-927e61c29ec4)
Jul 25, 2017 21:39:14.644 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (e1df2a0d-63bc-4873-8a3d-02513fa6cad2, expected 2e7a90f1-f383-48e8-a9ac-927e61c29ec4)
Jul 25, 2017 21:39:15.289 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (fb7cdccc-562f-45a9-b64c-87f7bba4c310, expected 2e7a90f1-f383-48e8-a9ac-927e61c29ec4)
Jul 25, 2017 21:39:19.547 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (909bb7d4-eb9e-4d1d-9b5c-f7fc3a5bf3c1, expected 2e7a90f1-f383-48e8-a9ac-927e61c29ec4)
Jul 25, 2017 21:39:20.221 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (3a0681fb-027b-414a-ab72-8196097bdc68, expected 2e7a90f1-f383-48e8-a9ac-927e61c29ec4)
Jul 25, 2017 21:39:28.367 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (327f5436-b1dc-4748-94f6-8bc0d7dd68c0, expected 2e7a90f1-f383-48e8-a9ac-927e61c29ec4)
Jul 25, 2017 21:39:36.439 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (f4e891ce-05c6-4b46-8061-49b92b71008f, expected 2e7a90f1-f383-48e8-a9ac-927e61c29ec4)
Jul 25, 2017 21:39:43.537 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (327f5436-b1dc-4748-94f6-8bc0d7dd68c0, expected 2e7a90f1-f383-48e8-a9ac-927e61c29ec4)
Jul 25, 2017 21:39:44.017 [0x7f61313ff700] WARN - NAT: PMP, got an error: Not Supported by gateway.
Jul 25, 2017 21:39:44.268 [0x7f6144de8700] WARN - NAT: PMP, got an error: Not Supported by gateway.
Jul 25, 2017 21:39:45.187 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (d68cd9ae-652f-4329-849b-d93b3f80a88a, expected 405f8422-e336-4b4e-a81c-08a3198416c7)
Jul 25, 2017 21:39:45.252 [0x7f6144de8700] WARN - NAT: PMP, got an error: Not Supported by gateway.
Jul 25, 2017 21:39:45.860 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (405f8422-e336-4b4e-a81c-08a3198416c7, expected 092b5b55-d517-452d-8bb3-42342e1290b9)
Jul 25, 2017 21:39:52.284 [0x7f61357ff700] WARN - PubSub: Received notifyConnectivity event with incorrect async identifier (cd399566-782b-4566-8add-c1cd088fa8be, expected 0b020c12-6408-4a50-8e2e-3be218e0d8c8)
Jul 25, 2017 21:39:52.305 [0x7f6145ffd700] WARN - NAT: PMP, got an error: Not Supported by gateway.

You can see PMS thinks it’s sending out requests but nothing is coming back. This is implying something nuts with networking.
Are you using Jumbo packets? Plex Relay, which is available, is the only mechanism which works when jumbos are in use.

Lastly, if you’re command line savvy, I am willing to hand-craft a Preferences.xmlfile for you based on your current one.

This would mean you send me yours in PM, including the desired manual external forwarded port you are using. I will edit the file to reflect this and convince PMS it does not need to hunt for the connection at start. It may flash / be red during until it settles but with a few ‘retries’ (about 30 seconds apart), it will ‘lock in’. Once locked in, it will stay. It is made permanent by letting it stay active (without touching) for a full “Plex.tv connectivity test” cycle (about 30 minutes) before shutting down PMS through the normal systemctl daemon.

16

I would say no on the Jumbo packets. I can look and see if Debian set this up by itself, but I don’t even know what that is so the Debian install would have had to enabled it by default.

I PM’d you my Preferences.xml. I am manually using 32400. Thank you so much for the help!

17

@ChuckPA

With regards to nat-PNP not supported by gateway this has nothing to do with setting up manual / static ports on the router or in plex

I have had static DNS in plex and assigned the port manually in plex forever and my log is continuously spammed with

NAT: PMP, got an error: Not Supported by gateway.

Because plex server is not smart enough to understand that when a manual port is being set in plex media server it should not be trying upnp

Upnp is disabled due to its security issues and unreliable nature… yes plex insists obviously in trying to continue to use it even when being instructed that manual settings are enabled…

I have brought this up numerous times and even with Elan… and … as usual… its yet to be addressed …

I still have remote available despite these log errors even though plex still reports its using an adapter that it cant possibly reach the internet with… I have been told by sa2000 that plex listens on all adapters and that the adapter/address displayed on PMS means nothing. It will try all paths until its gets on the internet… probably not best practices to be telling the admin it’s doing one thing but under the hood really doing whatever it wants.

18

Hey nbyloff, just for kicks, can you go here and run a test to ensure that someone other than yourself can validate 32400 being accessible from the outside? Just to ensure it isn’t a goofy networking thing? The status should say Open

https://www.grc.com/x/portprobe=32400

19

@jondrum418 said:
Hey nbyloff, just for kicks, can you go here and run a test to ensure that someone other than yourself can validate 32400 being accessible from the outside? Just to ensure it isn’t a goofy networking thing? The status should say Open

GRC | ShieldsUP! — Single Port Probe  

It shows the port as open currently.

Sorry it’s taken me so long to reply. I have been on vacation. I tried using ChuckPA’s custom Preferences.XML, and had a my server completely rebuilt with a new motherboard while I was out. I just reinstalled Ubuntu 16.04 today, but Plex is giving me this weird error. ChuckPA suggested eventually it would self correct itself. I am going to let it sit for about a week to see if it does.

If not, I will just assume I’m going to have to wait until they get time & resources to fix this bug.