[SOLVED] - Post Upgrade - Plex Remote Access Issues

Started by GuruLee, March 25, 2025, 01:13:53 PM

Previous topic - Next topic
March 31, 2025, 03:56:29 PM #15 Last Edit: April 02, 2025, 07:44:55 PM by GuruLee
UPDATE:

As a test, I switched from Plex remote access manual port forward using 32400 to Swag docker (ngnix) over port 443. Therefore, I properly disabled the remote-access settings on the Plex server and entered my URL under network settings as required.

***It works for me locally, from my cellular phone carrier off WIFI, and also from a work device that's on a full-tunnel VPN out of a Chicago location.
***Also, my other web apps using Swag (ngnix) are fine and remotely accessible as well for me over from all the same remote connections...

HOWEVER, my remote users continue to NOT be able to connect to Plex or my other web-apps via Swag (ngnix) from certain not all, ISP's, it hangs and eventually they get error in browser:

ERR_TIMED_OUT

I see the traffic in the firewall logs WAN interface with rdr rule label and its allowed.
I ruled out fail2ban, crowdsec, and zenarmor as being causes. Issue persists with those services uninstalled and disabled...

Any other ideas?
Protectli FW4C
Cybersecurity Practitioner, trail-runner, Mtb'er, self-hosted enthusiast, and audiophile.

I too run Plex.
I have two NAT's one for static NAT outbound and one for the incoming NAT (aka Port Forward).
I have a static WAN address assigned by my ISP.

Outbound static NAT
  • I have my firewall NAT outbound in Hybrid mode.
    Firewall > NAT > Outbound
  • I have added a manual static IP address for my Plex server (say 192.168.1.88)
  • I have a static outbound NAT for Plex.

**** Like this ****
Interface: WAN
Source: 192.168.1.88 (my Plex server LAN IP address)
Destination: *
Destination Port: *
NAT Address: Interface Address
NAT Port: *
Static Port: YES
Description: Static NAT for Plex Out

Inbound port forward NAT
  • Firewall > NAT > Port Forward
  • I have added a port forward for me Plex server (say 192.168.1.88)

**** Like this ****
Interface: WAN
Proto: TCP
Address: *
Ports: *
Address: This Firewall
Ports: the static port number you set inside Plex, typically 32400
IP: 192.168.1.88 (my Plex server LAN IP address)
Ports: the static port number you set inside Plex, typically 32400, the same as the first "Ports"
NAT Address: Interface Address
Description: WAN to Plex IN


This works for me great! I do not used "One-to-One" NAT at all.

April 03, 2025, 07:46:54 PM #17 Last Edit: April 03, 2025, 07:49:32 PM by jonny5
I will be making a blog entry about this eventually, but if you use Traefik as your reverse proxy, you can setup a TCP match for your plex.direct FQDN that Plex uses and allow a TLS passthrough that will finally show your remote availabilty as always Green

It is literally THIS ^ that causes the issue (and I have ran Nginx reverse proxy, got green, but it would fall off almost immediately.

I port forward 443 to 443, and 80 to 80 for the Traefik setup, and in Traefik if they are requesting my plex subdomain on 443 or 80 I forward them to 32400, and if they request the '*.*.plex.direct' fqdn, I have Traefik TCP (not HTTP) TLS passthrough (they are using their own Digicert SSL Cert) the connection to 32400 to the Plex server. ^_^
Custom: ASRock 970 Extreme3 R2.0 / AMD FX-8320E / 32 GB DDR3 1866 / X520 & I350 / 500GB SATA

April 04, 2025, 01:10:00 PM #18 Last Edit: April 08, 2025, 12:08:46 PM by GuruLee
Thank you all who responded with Enrichening info.!
Whats odd is, remote access to my Plex and my other web apps via ngnix is successful from these ISP's:

✅ Verizon
✅ Comporium
✅ TMobile
✅ Cyber Assets Fzco
✅ Cogent
✅ Palo Alto Networks

However,
For the other users that cannot reach my web-apps via Swag NGNIX behind Opnsense, I see the rdr nat and Wan rule logs reflect their connecting src IP being allowed in live logs...

* I don't see any IP bans in Fail2Ban either for latest tests
* Frontier, AT&T, and FiOS ISP users: get ERR_TIMED_OUT and cannot get to any of my web-apps.
* Disabling fail2ban does not resolve issue.
* Disabling crowdsec does not resolve issue.

For the remote users who cannot access my exposed apps over 443, they get this when doing a 'curl - v' against my URL:

Schannel: failed to receive handshake (35)

I'm left scratching my head.  Any ideas?
Protectli FW4C
Cybersecurity Practitioner, trail-runner, Mtb'er, self-hosted enthusiast, and audiophile.

This looks like it might be related to an MTU size on my WAN and Docker vlan interfaces since upgrading to 25.x.
After some testing, I lowered the MTU from 1492 to 1472 on both interfaces and as a result, one of my remote clients can now connect to Plex via web client.

More Troubleshooting needed...
Protectli FW4C
Cybersecurity Practitioner, trail-runner, Mtb'er, self-hosted enthusiast, and audiophile.

April 09, 2025, 02:18:29 AM #20 Last Edit: April 09, 2025, 12:57:03 PM by GuruLee
RESOLUTION:
Increasing the MTU size from 1492 (longtime setting) to 1500 on my WAN interface and changing the Docker VLAN interface from empty MTU to 1500 as well, resolved the issue for remote clients. They are now able to connect to Plex and the other web apps.
This appears to be related to kernel updates on Opnsense version 25 for FreeBSD 14 compatible.

Related: https://github.com/opnsense/src/issues/235
Protectli FW4C
Cybersecurity Practitioner, trail-runner, Mtb'er, self-hosted enthusiast, and audiophile.