Remote Access issues

I’ve never had a single issue with remote access until upgrading to 1.18+ earlier in the week. There are dozens upon dozens of posts with users experiencing the same issue.
There is this thread - Remote Access connects for about 15 seconds then disconnects - which dates back to 2017, but is still active with people on the newest versions of PMS experiencing issues.
Here is a problem specific to QNAP devices - Remote Access Qnap
Here is another one, this one specific to Windows Server (also version 1.18) - Suddenly Remote access isn't working - Outside network appears and then fails
Or this one - Remote access failure
Or this one - No remote Access

I have had port forwarding/remote access configured on my Plex server for literally YEARS. And have never had an issue. I also can access my server directly using https://DOMAIN_NAME:32400 so I KNOW that the port forward is working correctly.

I have followed troubleshooting steps to get access to the list of URLs that Plex is publishing to plex.tv by visiting this URL - https://plex.tv/pms/resources.xml?includeHttps=1&X-Plex-Token=PLEX-TOKEN. I get the list of URLs that plex.tv has recognized, pull my public URL/IP address and access it just fine when off my home network.

Please don’t try to hijack another thread and feel bad if your “injunction” isn’t dealt with (at least not up to your expectations). There’s always been tons of “me too” posts that turn out to be totally different situations.

So… let’s do this properly and start with YOUR situation.

  1. tell us about your specific setup (e.g. what platform are you running your PMS on, what version of PMS do you have installed…)
  2. same about your network setup – single router or multiple separated subnets etc.
  3. How have you setup your remote access – you mention you “had” port forwarding
  4. is your port forward still visible from outside your home network? You can verify this e.g. using canyouseeme.org
  5. do you have any active “security apps” that could interfere with Plex’ communication?
  6. anything else that might be relevant to your case

Tom, I do apologize for my heated response in the other thread and I appreciate you taking the time to separate this one out and help me with my issue.

  1. tell us about your specific setup (e.g. what platform are you running your PMS on, what version of PMS do you have installed…)

    • FreeNAS 11.3U2.

    • PMS 1.18.9.2578

  2. same about your network setup – single router or multiple separated subnets etc.

    • Single router, no separated subnets, no vlans, etc. Running latest version of pfSense.
  3. How have you setup your remote access – you mention you “had” port forwarding

    • I have a manual port forwarding rule setup on pfSense, and I consistently see the rule pass in the firewall logs. I have had this rule in place since I implemented pfSense almost 2 years ago. I have numerous other firewall rules that are working as expected. I have “manually specified port” selected in the Plex settings, where I use port 32400. I have had this set for years. Since updating to 1.18 earlier this week, I had users report issues.
  4. is your port forward still visible from outside your home network? You can verify this e.g. using canyouseeme.org

    • Yes, I have verified this.
      image
  5. do you have any active “security apps” that could interfere with Plex’ communication?

    • pfSense firewall, but as stated above I consistently see the Plex rule pass. I do not have the Plex firewall rule limited by source IP address.
  6. I did have issues updating my existing plex instance from 1.14 (or 1.16, I can’t recall) so I decided to do a fresh jail, installed plex 1.18+ there, and moved all application data to the new jail. I am wondering if something screwy happened during this, I am going to investigate further at the jail level. (Rubber duck debugging at its finest.)

Mod-Edit: shifted the response bullet points by 1 level to improve readability

I forgot asking… could you also add a brief comment on the actual symptoms?
I take it for granted that Plex shows “your server is not available outside your home network” – I also take it, you tested with an actual remote device and couldn’t play any media / see your library from there. Any special error messages?

Also… just to be sure…
Did you establish a port forward in your router (as in forwarding requests to the router’s public IP on a certain port to the device running your Plex Media Server at its internal IP address and port 32400). I’m just asking because a firewall rule is not a port forward… that’s just ensuring your communication isn’t blocked on the way on :wink:

As part of rebuilding your PMS on 1.18+ in a new jail. Have you verified the new jail is listening to the communication on port 32400 and passing that to the PMS running inside?

Actual symptoms are pretty much what you stated. Plex Remote Access will show ‘not available outside your home network.’ I got a report from one remote user that he could not see my server at all. I was watching locally with no issues, but I went out of my network via LTE and verified that I also could not see any media/the server as well. Disabling Remote Access & re-enabling would show the server as available again but it would only last for 2 minutes or so.

Yes, I do have both a port forward & a firewall rule :slight_smile:

Here is a netstat showing the jail listening on 32400:

root@hl-plex:~ # netstat -an | grep 32400
tcp4       0      0 192.168.1.5.32400      192.168.1.1.56299      ESTABLISHED
tcp4       0      0 192.168.1.5.32400      192.168.1.16.46130     TIME_WAIT
tcp4       0      0 192.168.1.5.32400      34.245.172.51.45340    ESTABLISHED
tcp4       0      0 192.168.1.5.32400      XX.XX.XX.XXX.56006     ESTABLISHED
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14860        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14859        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14857        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14855        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14854        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14850        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14849        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14847        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14845        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14843        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14842        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14841        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14810        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14808        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14805        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14803        TIME_WAIT
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14802        TIME_WAIT
tcp4       0      0 192.168.1.5.32400      192.168.1.16.46102     TIME_WAIT
tcp4       0      0 192.168.1.5.32400      192.168.1.1.31301      ESTABLISHED
tcp4       0      0 127.0.0.1.32400        127.0.0.1.14354        TIME_WAIT
tcp4       0      0 192.168.1.5.32400      XX.XX.XX.XXX.56001     FIN_WAIT_1
tcp4       0      0 192.168.1.5.32400      192.168.1.24.53590     ESTABLISHED
tcp4       0      0 127.0.0.1.32400        127.0.0.1.62802        FIN_WAIT_2
tcp4       0      0 127.0.0.1.62802        127.0.0.1.32400        CLOSE_WAIT
tcp4       0      0 192.168.1.5.32400      XX.XX.XX.XXX.55961     ESTABLISHED
tcp4       0      0 192.168.1.5.32400      XX.XX.XX.XXX.55960     ESTABLISHED
tcp4       0      0 192.168.1.5.32400      XX.XX.XX.XXX.55959     ESTABLISHED
tcp4       0      0 192.168.1.5.32400      XX.XX.XX.XXX.55958     ESTABLISHED
tcp4       0      0 192.168.1.5.32400      XX.XX.XX.XXX.55934     ESTABLISHED
tcp4       0      0 192.168.1.5.32400      192.168.1.100.34199    ESTABLISHED
tcp4       0 482692 192.168.1.5.32400      192.168.1.100.34196    ESTABLISHED
tcp4       0      0 127.0.0.1.32400        127.0.0.1.62543        ESTABLISHED
tcp4       0      0 127.0.0.1.62543        127.0.0.1.32400        ESTABLISHED
tcp4       0      0 192.168.1.5.32400      XXX.X.XXX.XXX.51156    ESTABLISHED
tcp4       0      0 192.168.1.5.32400      192.168.1.16.44064     ESTABLISHED
tcp4       0      0 127.0.0.1.32400        127.0.0.1.42481        ESTABLISHED
tcp4       0      0 127.0.0.1.42481        127.0.0.1.32400        ESTABLISHED
tcp4       0      0 192.168.1.5.32400      192.168.1.16.44032     ESTABLISHED
tcp4       0      0 192.168.1.5.32400      192.168.1.18.33138     ESTABLISHED
tcp4       0      0 192.168.1.5.32400      192.168.1.24.50126     FIN_WAIT_2
tcp4       0      0 *.32400                *.*                    LISTEN

As I was reviewing logs, etc. in the new jail, I saw that the system was “getting a new IP address” from dhclient. Even though I have a static IP address set for the jail via the FreeNAS UI. So I double checked my DHCP Leases on pfSense and sure enough, I see a DHCP lease… Even though Plex is not running/listening on the IP address my DHCP server says it has. Even an ‘ifconfig’ in the jail doesn’t show the IP address shown by pfSense DHCP server.

I then realized that I have a DHCP reservation for my plex server and I didn’t update the MAC address with the one of the new jail. I updated the DHCP reservation’s MAC address and restarted the jail. No updates in /var/log/messages claiming a ‘false’ IP address, no DHCP lease in pfSense, except for the static IP reservation that I am expecting. Remote Access has remained stable for the last 20 minutes. I am cautiously optimistic that this was the issue. I have tested externally, as well as had my user that reported the issue yesterday test - both successful.

fingers crossed…
that’s why I said those perceived spikes in issues tend to turn out very specific/individual issues – and we’re fixing them one at a time :wink:

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.