New Linux Plex Server - No Remote Access

Server Version#: 4.121.1
Player Version#: 4.121.1
OS: Ubuntu 22.04
Hardware: Intel 14 core 64GB RAM 10 x 2TB SSD R5
Network: 2 x 10Gb LACP
UFW : Disabled for now
Apparmor: disabled for now
New: New server and two new 10Gb Brocade ICX switches

First posting to this forum so… Greetings… And I hate to dog pile on a topic seeming to be beaten like a dead duck… but… … not seeing trees for forest here: Goal is to document workflow to root cause for a bit more advanced / complex system.

I use to run plex on raspberry PI 4 with small nas appliance with 1Gb software nic but it was too much for it to run current movies, and NIC transfers was creating problems. I had a two more VMs also as front ends and they were ok… but I wanted to remove LAN transfer latency, as well as handle higher resolution movies. So I built a new one … it plays local but has a lot of 20second play then studder, and remote … again same experience. So I am assuming this is because its using gateway service to play and that is creating issue

But after a few weeks, still not able to get remote access to work.

Packet flow:
ISP/WAN IP → IP on WAN of PFsense interface → NAT rule 32403 TCP to 32400 to 172.16.100.110 + FW rule 32400 from * to * allow to 172.16.100.110 → 1Gb LAN → 10Gb Switch supporting Jumbo frames → 2 x 10Gb LAG → 10Gb NIC in host + VLAN tagged interface + bridge for KVM etc + IP of host 172.16.100.110

I know that is a more complex setup than your average bear… but… that is what I need for that server to also host my other environments of systems.

Test Cycle:

Shell on Server

cd /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs
mv *.log /tmp/
systemctl restart plexmediaserver.service 
systemctl status plexmediaserver.service 
< active (running) since Fri 2023-12-29 08:30:04 EST; 7s ago>
netstat -an | grep 32400
tcp        0      0 0.0.0.0:32400           0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:32400         127.0.0.1:50390         TIME_WAIT  
tcp        0      0 127.0.0.1:50368         127.0.0.1:32400         TIME_WAIT  
tcp        0      0 127.0.0.1:32400         127.0.0.1:50332         TIME_WAIT  
tcp        0      0 172.16.100.110:32400    172.16.100.32:20419     FIN_WAIT2  
tcp        0      0 127.0.0.1:32400         127.0.0.1:50360         TIME_WAIT  
tcp        0      0 172.16.100.110:32400    172.16.100.158:40986    ESTABLISHED
tcp        0      0 172.16.100.110:53374    108.234.144.117:32400   ESTABLISHED
tcp        0      0 127.0.0.1:50374         127.0.0.1:32400         TIME_WAIT  
tcp        0      0 172.16.100.110:53364    108.234.144.117:32400   TIME_WAIT  
tcp        1   5076 172.16.100.110:32400    172.127.119.208:62345   CLOSING    
tcp        0      0 127.0.0.1:32400         127.0.0.1:50342         TIME_WAIT  
tcp        0      0 172.16.100.110:32400    172.16.100.32:52867     TIME_WAIT  
tcp        0      0 127.0.0.1:32400         127.0.0.1:50302         TIME_WAIT  
tcp        0      0 127.0.0.1:32400         127.0.0.1:50358         TIME_WAIT  
tcp        0      0 172.16.100.110:32400    172.16.100.32:20455     FIN_WAIT2  
tcp        0      0 172.16.100.110:32400    172.16.100.32:20422     FIN_WAIT2  
tcp        0      0 172.16.100.110:32400    172.16.100.32:20446     ESTABLISHED
tcp        0      0 127.0.0.1:32400         127.0.0.1:50326         TIME_WAIT  
tcp        0      0 127.0.0.1:32400         127.0.0.1:50362         TIME_WAIT  
tcp        0      0 127.0.0.1:32400         127.0.0.1:50316         TIME_WAIT 

GUI in plex

Settings → Remote Access → Manual port 32403 → Retry → flips green for 2 seconds then back to fail.

< collect logs in GUI >

Log Review

Not sure in forum how to attached to thread as zip but cut out what I think is relevlant:
“Plex Media Server.log” seems to be the relevant log for this issue and search for “32403”

7944726328] DEBUG - Completed: [172.16.100.32:20509] 200 GET /myplex/account (6 live) #b7 TLS GZIP 2770ms 4051 bytes (pipelined: 55)
Dec 29, 2023 08:31:55.692 [139697839762232] DEBUG - Request: [172.16.100.32:20509 (Subnet)] GET /myplex/account (6 live) #b8 TLS GZIP Signed-in Token (LordVisigoth) (Microsoft Edge)
Dec 29, 2023 08:31:55.694 [139697944726328] DEBUG - Completed: [172.16.100.32:20509] 200 GET /myplex/account (6 live) #b8 TLS GZIP 1ms 4053 bytes (pipelined: 56)
Dec 29, 2023 08:31:55.694 [139697907448632] DEBUG - [Req#6d] MyPlex: Sending Server Info to myPlex (user=nobody@gmail.com, ip=108.234.x.x, port=32403)
Dec 29, 2023 08:31:55.695 [139697907448632] DEBUG - [Req#6d/HCl#5c] HTTP requesting POST https://plex.tv/servers.xml?auth_token=xxxxxxxxxxxxxxxxxxxx
Dec 29, 2023 08:31:55.920 [139697839762232] DEBUG - Request: [172.16.100.32:20509 (Subnet)] GET /myplex/account (6 live) #ba TLS GZIP Signed-in Token (LordVisigoth) (Microsoft Edge)
Dec 29, 2023 08:31:55.922 [139697946835768] DEBUG - Completed: [172.16.100.32:20509] 200 GET /myplex/account (6 live) #ba TLS GZIP 1ms 4053 bytes (pipelined: 57)
Dec 29, 2023 08:31:56.187 [139697916107576] DEBUG - [HttpClient/HCl#5c] HTTP/2.0 (0.5s) 201 response from POST https://plex.tv/servers.xml?auth_token=xxxxxxxxxxxxxxxxxxxx
Dec 29, 2023 08:31:56.187 [139697907448632] DEBUG - [Req#6d] MyPlex: Published Mapping State response was 201
Dec 29, 2023 08:31:56.187 [139697907448632] DEBUG - [Req#6d] MyPlex: Got response for 1538de5a43d1b68f1ed0498e9f12c1ec1a0f223a ~ registered 108.234..x.x:32403
Dec 29, 2023 08:31:56.187 [139697907448632] DEBUG - [Req#6d] MyPlex: updating mapped state - current state: 'Mapped - Not Published'
Dec 29, 2023 08:31:56.187 [139697907448632] DEBUG - [Req#6d] MyPlex: mapping state set to 'Mapped - Publishing'.
Dec 29, 2023 08:31:56.187 [139697907448632] DEBUG - [Req#6d] MyPlex: async reachability check - current mapped state: 'Mapped - Publishing'.
Dec 29, 2023 08:31:56.187 [139697907448632] DEBUG - [Req#6d] MyPlex: Requesting reachability check.
Dec 29, 2023 08:31:56.187 [139697907448632] DEBUG - [Req#6d/HCl#5d] HTTP requesting PUT https://plex.tv/api/servers/1538de5a43d1b68f1ed0498e9f12c1ec1a0f223a/connectivity?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx&asyncIdentifier=e330a39b-00c9-4b0f-a03e-5efdfacbef8c
Dec 29, 2023 08:31:56.326 [139697916107576] DEBUG - [HttpClient/HCl#5d] HTTP/2.0 (0.1s) 200 response from PUT https://plex.tv/api/servers/1538de5a43d1b68f1ed0498e9f12c1ec1a0f223a/connectivity?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx&asyncIdentifier=e330a39b-00c9-4b0f-a03e-5efdfacbef8c (reused)
Dec 29, 2023 08:31:56.327 [139697907448632] DEBUG - [Req#6d] MyPlex: Updating device connections (from timer: 0)
Dec 29, 2023 08:31:56.327 [139697907448632] DEBUG - [Req#6d/HCl#5e] HTTP requesting PUT https://plex.tv/devices/1538de5a43d1b68f1ed0498e9f12c1ec1a0f223a?Connection[][uri]=http://108.234..x.x:32403&Connection[][uri]=http://172.16.100.110:32400&httpsEnabled=1&httpsRequired=0&dnsRebindingProtection=0&natLoopbackSupported=0&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx
Dec 29, 2023 08:31:56.420 [139697839762232] DEBUG - Request: [172.16.100.32:20509 (Subnet)] GET /myplex/account (6 live) #bc TLS GZIP Signed-in Token (LordVisigoth) (Microsoft Edge)
Dec 29, 2023 08:31:56.421 [139697946835768] DEBUG - Completed: [172.16.100.32:20509] 200 GET /myplex/account (6 live) #bc TLS GZIP 1ms 4109 bytes (pipelined: 58)
Dec 29, 2023 08:31:56.474 [139697916107576] DEBUG - [HttpClient/HCl#5e] HTTP/2.0 (0.1s) 200 response from PUT https://plex.tv/devices/1538de5a43d1b68f1ed0498e9f12c1ec1a0f223a?Connection[][uri]=http://108.234..x.x:32403&Connection[][uri]=http://172.16.100.110:32400&httpsEnabled=1&httpsRequired=0&dnsRebindingProtection=0&natLoopbackSupported=0&X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (reused)
Dec 29, 2023 08:31:59.455 [139697854626616] DEBUG - [NSB/SSDP] Parsing SSDP schema for http://172.16.100.7:9080
Dec 29, 2023 08:31:59.466 [139697916107576] DEBUG - [HttpClient/HCl#5f] HTTP/1.1 (0.0s) 200 response from GET http://172.16.100.7:9080 (reused)
Dec 29, 2023 08:32:01.451 [139697946835768] DEBUG - [EventSourceClient/pubsub/45.56.115.195:443] EventSource: Got event [data] '<Message address="108.234..x.x" port="32403" asyncIdentifier="e330a39b-00c9-4b0f-a03e-5efdfacbef8c" connectivity="0" command="notifyConnectivity"/>'
Dec 29, 2023 08:32:01.451 [139697946835768] DEBUG - [EventSourceClient/pubsub/45.56.115.195:443] PubSub: Got notified of reachability for async identifier e330a39b-00c9-4b0f-a03e-5efdfacbef8c: 0 for 108.234..x.x:32403 (responded in 5125 ms)
Dec 29, 2023 08:32:01.451 [139697946835768] DEBUG - [EventSourceClient/pubsub/45.56.115.195:443] MyPlex: reachability check - current mapping state: 'Mapped - Publishing'.
Dec 29, 2023 08:32:01.451 [139697946835768] DEBUG - [EventSourceClient/pubsub/45.56.115.195:443] MyPlex: mapping state set to 'Mapped - Not Published (Not Reachable)'.
Dec 29, 2023 08:32:01.458 [139697839762232] DEBUG - Request: [172.16.100.32:20509 (Subnet)] GET /myplex/account (5 live) #c1 TLS GZIP Signed-in Token (LordVisigoth) (Microsoft Edge)
Dec 29, 2023 08:32:01.459 [139697946835768] DEBUG - Completed: [172.16.100.32:20509] 200 GET /myplex/account (5 live) #c1 TLS GZIP 1ms 4118 bytes (pipelined: 59)

A bit vague…

nmap of server on LAN scan of host

Scanning pandora.penguinpages.local (172.16.100.110) [1000 ports]

Discovered open port 22/tcp on 172.16.100.110
Discovered open port 111/tcp on 172.16.100.110
Discovered open port 5900/tcp on 172.16.100.110
Discovered open port 3389/tcp on 172.16.100.110
Discovered open port 139/tcp on 172.16.100.110
Discovered open port 445/tcp on 172.16.100.110
Discovered open port 9090/tcp on 172.16.100.110
Discovered open port 9091/tcp on 172.16.100.110
Discovered open port 5901/tcp on 172.16.100.110
Discovered open port 2049/tcp on 172.16.100.110
Discovered open port 6547/tcp on 172.16.100.110
Discovered open port 873/tcp on 172.16.100.110
Completed SYN Stealth Scan at 08:38, 0.09s elapsed (1000 total ports)

Above not what I expected… every port BUT 32400… ??

I went back to old plex pi host and reinstalled plex and re-activated it on 32402 It also has same symptom. But I did not think to “save it” in old working state so as to have solid baseline, so re-install and configure and forwarding rules put back… But tried it to rule out 10Gb / LAG / VLAN interface + bridge etc… So I can’t know, but I don’t think its that.

nmap on PI

Discovered open port 22/tcp on 172.16.100.20
Discovered open port 111/tcp on 172.16.100.20

Again, not what I expected… port 32400 not showing.

If I go to URL :

http://server.local.ip.address:32400/clients

401 Unauthorized

But so does PI system… so… Not sure what “…Plex App doesn’t appear in the XML there…” means but my guess is not a 401… an example response success would help :slight_smile:

Question:

Is there a more technical debug workflow on host validate workflow… This document is a good start… but could use a bit more technical test steps…

Also have

  1. pfSense
  2. 10G BaseT switch
  3. Bonded 2x 10Gb NIC on host NAS.

Rules:

  1. Don’t overthink it. Complex VLAN/subnet configurations make messes.
  2. Don’t use Jumbo Frames

pfSense:

  1. DNS resolver (you should already have this)

  2. Simple NAT Port Forward rule for 32400/TCP
    (I use a different port)

You need your PlexToken with that URL.

I do appreciate your response and perspective Let me just put back some notes and clarifications

I agree KISS is always best, but I have only 2 x 10Gb SFP ports on that server and its the backbone as a NAS with NFS of my K8 clusters. So I do LACP, and I need to have storage and mgmt split and also have VLAN for containers:

100 - 172.16.100.x/24 - VM / Data / Plex / Mgmt
101 - Storage - NFS , object
103 - containers (they need other overlay networks so had to isolate.

The question of Jumbo frames… I was not clear with plex of “will not work” or… may not work / take some tuning.

Switches are Changing the MTU (ruckuswireless.com)

So Jumbo is switch wide setting then limit down by physical interface.

VSAN / Nutanix require jumbo frames for HCI… so I have to have jumbo frames for most of the systems.

If I turn it off , it will be on physical port and as such its possible, but prefer not unless that is only means to get it to function…

As for “DNS resolver” setting you showed in screenshot… I am not sure where that is set… I assume this just is statement of making sure DNS is setup such as …

cat /etc/resolve.conf
search penguinpages.local
nameserver 172.16.110.241
nameserver 172.16.110.242

I did originally use simple forwarding logic of 32400… I took down and deleted the three old plex… removed from account, and then instead of 32401-3 , dropped down to just 32400 but that made no difference… But that would be end goal :slight_smile:

Thanks for screen shots.

Can you clarify a few things on your setup:

  1. Are jumbo frames “dead on arrival” or just problematic?
  2. I noted that via nmap 32400 is showing as service binding to nics in kernel, but nmap did not show on scan 32400 open… which I scratch my head at… but both systems showed same
  3. http://server.local.ip.address:32400/clients “You need your PlexToken with that URL.” Not sure what you mean in that my test was / is wrong. Is this an API GW where connection will only show positive result if provided challenge with token… can you post a “good result” baseline and how to get that?
  4. Can you test above out via WAN then to demonstrate forwarding. Seems logical…

Jumbo frames won’t work – You’ll get a lot of fragmentation and stuttering.
This happens because you have no control of the TCP/IP stack in your player devices.

They run at stock 1500 MTU.
Plex.tv also uses 1500 MTU.

You can only use Jumbo Frames when you have full control of every device in the path from source → destination inclusive.

People see it… think it’s ok … but in practice find it ineffective.
I once had a ‘storage VLAN’ on separate adapters at MTU 9000. The performance increase at 10G wasn’t worth the trouble to setup and maintain as an isolated storage network (fully isolated from the main). Setting up LACP bond at 1500 MTU gave far better performance.

As for pfSense -

  • Services → DNS Resolver → This is where you put the DNS rebinding rule to allow plex.direct

  • With it in the pfSense, you don’t need to do anything on any host – assuming you use the pfSense as your DNS resolver / server / gateway

  1. In your Preferences.xml, you’ll find PlexOnlineToken. You’ll want that value (not including quotes)

  2. http://server-address:32400/clients/?X-Plex-Token=PASTE_TOKEN_HERE
    You’ll get results like:

<MediaContainer size="1">
<Server name="Roku Ultra" host="192.168.0.35" address="192.168.0.35" port="8324" machineIdentifier="---redacted---" version="7.12.4.8870-bb1854ae0-Plex" protocol="plex" product="Plex for Roku" deviceClass="stb" protocolVersion="1" protocolCapabilities="timeline,playback,navigation,playqueues"/>
</MediaContainer>

^^ This will work via LAN or WAN. (Think of how Tautulli works) :slight_smile:

I use netstat instead of nmap when looking at the server

[chuck@glockner Plex Media Server.2007]$ netstat -an | grep 324
tcp        0      0 127.0.0.1:32401         0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:32400           0.0.0.0:*               LISTEN     
tcp        0      0 192.168.0.20:32400      192.168.0.60:32870      ESTABLISHED
tcp        0      0 192.168.0.20:43484      192.168.0.17:32400      ESTABLISHED
tcp        0      0 192.168.0.20:46492      192.168.0.71:32400      ESTABLISHED
tcp        0      0 192.168.0.20:32400      192.168.0.71:40174      ESTABLISHED
tcp        0      0 192.168.0.20:39030      192.168.0.50:32400      ESTABLISHED
tcp        0      0 192.168.0.20:32400      192.168.0.50:39608      ESTABLISHED
tcp        0      0 192.168.0.20:32400      192.168.0.13:40582      ESTABLISHED
tcp        0      0 192.168.0.20:32400      49.191.202.17:60598     ESTABLISHED
tcp        0      0 192.168.0.20:32400      192.168.0.13:59062      ESTABLISHED
tcp        0      0 192.168.0.20:32400      10.1.0.14:35294         ESTABLISHED
tcp        0      0 192.168.0.20:32400      192.168.0.44:55994      ESTABLISHED
tcp        0      0 192.168.0.20:32400      192.168.0.13:59674      ESTABLISHED
tcp        0      0 192.168.0.20:51412      192.168.0.60:32400      ESTABLISHED
tcp        0      0 192.168.0.20:32400      49.191.202.17:53176     ESTABLISHED
tcp        0      0 192.168.0.20:32400      49.191.202.17:60593     ESTABLISHED
tcp        0      0 192.168.0.20:32400      192.168.0.17:54178      ESTABLISHED
udp        0      0 0.0.0.0:32410           0.0.0.0:*                          
udp        0      0 0.0.0.0:32412           0.0.0.0:*                          
udp        0      0 0.0.0.0:32413           0.0.0.0:*                          
udp        0      0 0.0.0.0:32414           0.0.0.0:*                          
unix  2      [ ]         DGRAM      CONNECTED     32459    /var/lib/samba/private/msg.sock/3611
unix  2      [ ACC ]     STREAM     LISTENING     32462    /var/run/samba/winbindd/pipe
unix  2      [ ]         DGRAM      CONNECTED     32467    /var/lib/samba/private/msg.sock/3663
unix  2      [ ACC ]     SEQPACKET  LISTENING     16324    /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     32463    /var/lib/samba/winbindd_privileged/pipe
unix  3      [ ]         STREAM     CONNECTED     32469    
unix  3      [ ]         STREAM     CONNECTED     32465    
unix  3      [ ]         STREAM     CONNECTED     32466    
unix  3      [ ]         STREAM     CONNECTED     32470    
[chuck@glockner Plex Media Server.2008]$ 

( I removed the WAN IPs of those currently playing from my server )

Coming back to this topic

I have disabled all jumbo frames from environment.

I have, as noted a fairily complex server: 10Gb +LCAP + VLANs + Bridge + IP +Plex :slight_smile:

I have re-established my old Raspberry pi (was working before change of network switches and new Plex server)… but it also is no longer able to "connect remotely.

Ex: PI IV system: 172.16.100.20 → 3400 NAT → 3400 firewall forward to 172.16.100.20

same result if I try on main host

I saw section about pfsense → DNS resolver advanced

I have never messed with this on my pfsense. is this needed? And setting “private-domain” is that not for intranet zone, but does this need to be declared (my DNS servers are elsewhere in my home environment , not pfsense.

server:include: /var/unbound/pfb_dnsbl.*conf

pfsense uses unbound.

you show here, you’re using unbound.

the private-domain declaration tells unbound to allow domain ‘plex.direct’ to overlay the LAN. without it, many hosts will fail to work correctly due to DNS-rebinding protection in the DNS Resolver (Modem/router)

“…unbound to allow domain ‘plex.direct’ to overlay the LAN…”

By overlay I assume you do not mean subverting anything related to my intranet DNS zone default.

Ex:
lab.local

So hosts would be…
(router) rt1.lab.local
(NAS/Plex) pandora.lab.local
(old plex/PI) hypnos.lab.local

Is the outcome / goal that my host is addressable by the router as a host within subnet “plex.direct”

Ex: pandora.plex.direct

If that is requirement… that … is rather odd… And If I have to do that, I may just add static record in pfsense vs trying to substantiate a zone for that.

If this is not a zone thing, but more of a record reference pfsense handles… would it then look like below (leaving unbound alone but adding reference as posted)

server:include: /var/unbound/pfb_dnsbl.*conf
private-domain: "plex.direct"
so-reuseport: no

All hosts / players on your home network will be accessible as a ‘plex.direct’ “fqdn” host. (part of the domain)

is this some kind of new requirement?

It use to work… without that.

My inbound also has other domains… so not sure if this means pfense will append each record request inbound that stub zone record.

Ex:


Intenet ----> pfesense router


resolve name:  pandora.plex.direct 
  -> router response :  172.16.100.110  A record  pandora.plex.direct

BTW… I did add

image

still get (both servers as i flit nat forward) disconnected state

I also did a baseline to test forwarding service from external server through WAN into 32400 TCP which forwards to plex host

Setup packet capture on pfsense firewall: wan inteface tcp 32400

External Host: telnet 32400

plex host: tcpdump port 32400

I get session request as well as other banter from second plex server … I am starting to think more this is something with plex.

You do not create the entries for plex.direct. Plex.tv and PMS do.

  • PMS manages them.
  • What you don’t want happening is DNS-Rebinding BLOCKING.

I am getting the impression that you’re overthinking or trying to over-manage this.
It’s not necessary and totally counterproductive

I have my own FQDN (which pfsense manages)
– with 2 subnets (192.168.0.0 main -and- 192.168.65.0 guest)
– with 3 VLANs (VLAN IDs managed/controlled by the switch)

Pfsense does the Let’s Encrypt ACME work plus WAN IP publication for the FQDN.

Pfsense manages the entire LAN (both my and Plex development systems)
Everything is addressable by short hostname or my FQDN full name.
It manages DHCP reservations as well as dynamic pool assignments.

Literally, Pfsense (layers 3 and above) and the switch (layers 1 & 2) is all I need.

==================================================================
Only PMS and LAN players use plex.direct. We should never touch it except to ensure we do not have DNS rebinding being blocked.

My ‘private-domain: “plex.direct”’ directive in the DNS resolver is how I allow plex.direct to coexist with my FQDN.

Regarding Remote Access

  1. There is no need for firewall
    – My VLAN switch isolates LAN traffic
    – Pfsense blocks all other traffic without a PASS rule

  2. There is only 1 NAT Port-Forwarding rule in Pfsense

  • I tell Plex.tv which WAN port to use
  • The NAT port forward rule
    – Traffic received at WAN Address
    – Destination port = PMS port
  • Is redirected to PMS LAN IP, port 32400

With this, Remote Access is enabled and stays enabled immediately.

I believe what I do have is KISS… yet it is NOT working. Hense the request for help with debug. :slight_smile:

WAN with one NAT rule

WAN 32400 TCP forward to Plex server

Firewall rule to be clear

plex set to remote 32400

goes green 3-4 seconds then back to red.

Others using AT&T Fiber also banter on this… but its same:

‎Plex - Remote Access | Page 3 | AT&T Community Forums (att.com)

IP Passthrough is set to enable and so no other configurations on that side

image

Much of the rest of the above post is to try to create baseline because changes were switches, AND server. So adding back in old PI / server with single Gb nic was to try to reflect its likly NOT the plex hosts.

The packet capture was to convey 32400 was ingressing through WAN bridge → pfsense → plex host

But trying to get reason why then it keeps failing

Everything you show me here is exactly as it should be and matches what I have.

We’re getting down to “Something Stupid” level now –

  1. The ATT modem/router is confirmed passthrough (yes I see it shown above)
    – Your pfsense shows the correct WAN IP in the Interfaces widget ?
    ( when mine gets whacked out, I see it give me 192.168.100.2 – which is NAT – and why I use 192.168.0.0 as my main subnet – NAT is easily spotted )

  2. The host’s firewall is disabled / inactive ?

  3. There’s nothing in between the Pfsense & host except a switch which is NOT packet / VLAN filtering? (both on VLAN 1)?

Sorry for asking the extreme basic stuff but it’s going to be something trivial/overlooked.

– Your pfsense shows the correct WAN IP in the Interfaces widget ?

I have WAN set to DHCP with manual mac binding / long term lease. Typical for ISP in case they reset router or do something stupid, i can quickly reset.

( when mine gets whacked out, I see it give me 192.168.100.2 – which is NAT – and why I use 192.168.0.0 as my main subnet – NAT is easily spotted )
NAT = WAN Logical interface name

  1. The host’s firewall is disabled / inactive ?

I use firewall on all hosts…

vi /etc/ufw/applications.d/plexmediaserver

[plexmediaserver-all]
title=Plex Media Server (Standard + DLNA)
description=The Plex Media Server (with additional DLNA capability)
ports=32400/tcp|3005/tcp|5353/udp|8324/tcp|32410:32414/udp|1900/udp|32469/tcp

ufw allow plexmediaserver-all

but within baseline Iine I have removed it

iptables -F
  1. There’s nothing in between the Pfsense & host except a switch which is NOT packet / VLAN filtering? (both on VLAN 1)?

primary vlan in this example is “100” 172.16.100.0/24. GW is pfsense at .1 via 1Gb line via tagged interface into same switch as Plex host(s). Pi Plex host is same switch in stack … two ports over. Host is 2 x 10Gb split one connection per switch in stack (but as it is a stack , its logically one switch).
image

Sorry for asking the extreme basic stuff but it’s going to be something trivial/overlooked.
[/quote]

Not a problem at all. Many times in these network debug its the basics. This started off with my thinking it was change in MTU… and that just took me a week to tear back out. I just wish I could get a protocol exchange session log from within plex. If it goes “green” for 2-3 seconds… that mean UI either is dump and defaults to green… or… every time you try… it links but then something like key exchange is failing.

Piece at a time if I may? I’ve got “The 'vid” and struggling.

Parts 1 and 2 of this part are in your debug server logs.

Part 1 - If you have your own FQDN, you’ve created a P12 file for PMS to use

  1. It must be OpenSSL v3.0 compliant now. That happened in April of 2023.
  1. How it works
  • You turn it ON
  • Plex/Web opportunistically turns the indicator green (before anything happens)
  • It notifies PMS
  • PMS sends out a reachability test to Plex.tv with an ID number (Test ID)
  • Plex.tv attempts direct connection on the given port at your WAN IP.
  • Pass or fail, the result message is sent to PMS
  1. Every part of this is in your DEBUG server logs. Search for ‘reachability’
    “:0” = false (not reachable)
    “:1” = true (reachable)

If you think cert/key is failing –

  1. Are you giving PMS a URL to contact your server with or are you using the default ?

  2. If so, are you also complying with OpenSSLv3 cert creation above?

Q: Are you using UFW and IPTables concurrently with Pfsense ?

  • If so, urge you don’t. Conflict and makes mess
  • You don’t trust pfSense ? UFW or IPTables -plus- pfsense
    – double firewall? unnecessarily redundant
    – what are you not using correctly ?
  • I’ve turned everything off with only Pfsense enabled.
    – VLAN isolation is performed in the switch (VLAN ID level 2)

Logs attached. I cleared out (archived) logs to narrow down test.
Plex Media Server_Nutered.log (669.8 KB)

“…If you have your own FQDN, you’ve created a P12 file for PMS to use…”
I don’t want to get fancy with plex. No idea what P12 file is… I am ok with plex and PMS create / rotate own keys. I don’t care if it signs them and uses its own overlay name .

OS of ubuntu 22.04 is hostname zone I manage… but that is outside what plex cares about and that is fine with me. Ex: pandora.labs.local

I host DNS /SOA for labs.local (A and PTR zones / records) but if plex registers itself pandora.plex.direct within PMS… go for it.

Firewall of pfsense is obvious as ingress into the environment. UFW on plex host is just logic to keep things secure… but during this test…

root@pandora:/# systemctl status ufw
○ ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:ufw(8)

I think the connectivity is solid.

Internet router set to passthrough
pfsense router has NAT set and Firewall rule set
listener on host working.

Packet capture shows session from internet inbound reach host.

Log does not show any errors or events (lots of HTTP 200 ok)…

Hense scratching head…

I know you were likely just using this as an example, but to clarify how Plex builds its *.plex.direct URL…

The URL generated will be in the form:

  • The HTTPS URL scheme (https://).
  • The public address of your server with the octets separated by dashes instead of periods.
  • Your server’s unique certificate UUID. This can be found in your Plex installation’s Preferences.xml file and is named CertificateUUID.
  • The domain plex.direct.
  • The port number you are forwarding in your router’s configuration and have specified in your remote access settings…

So, for example, if your public IP address is 93.184.216.34, your certificate UUID is abcdefedcbabcdef1234567890, and your external port to be forwarded is 32400, the generated *.plex.direct URL would be:

https://93-184-216-34.abcdefedcbabcdef1234567890.plex.direct:32400

Once you have determined what that URL is, you can try pinging/dig’ing/nslookup’ing the FQDN contained within to see if it resolves:

ping 93-184-216-34.abcdefedcbabcdef1234567890.plex.direct


For what it’s worth, you have your public IP address shown in a couple of screenshots above. One could test that port 32400 is open and has a Plex Media Server listening there using telnet:
telnet ipaddress 32400
GET /web/index.html

This will spew out the HTML document in text form.


[Edit]

You can also check this URL to see what connection information your server is publishing to Plex’s servers:

https://plex.tv/api/resources?includeIPv6=1&includeHttps=1&X-Plex-Token=your_plex_token

You can use the information in this support article to find your Plex token.

thanks for debug note:

Collected CertificateUUID + IP and with remote host did test

PS C:\Users\jump> nslookup - 8.8.8.8
Default Server:  dns.google
Address:  8.8.8.8

> 108-234-147-234.3f11123f1d22128549cf3bc44ca41e.plex.direct
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    108-134-146-234.3f11123f1d22128549cf3bc44ca41e.plex.direct
Address:  108.134.146.224

>
HTTP/1.1 200 OK
X-Plex-Protocol: 1.0
Cache-Control: no-cache
Accept-Ranges: bytes
Connection: close
Content-Length: 12417
Content-Type: text/html
Date: Thu, 25 Jan 2024 02:35:03 GMT

<!DOCTYPE html>
               <!--
                      =======   ==
                                    /==////== /==
                                                   /==   /== /==   =====   ==   ==
                                                                                    /=======  /==  ==///== //== ==
                                                                                                                    /==////   /== /=======  //===
                           /==       /== /==////    ==/==
                                                           /==       /== //======  == //==
                                                                                            //        //   /////   //   //

    Credits
              * Glyphicons - http://glyphicons.com
                                                  -->
                                                     <html lang="en" data-cast-api-enabled="true">
                                                                                                  <head>
                                                                                                        <title>Plex</title>
   <meta charset="utf-8">
                         <meta http-equiv="X-UA-Compatible" content="IE=Edge">

so seems registration with PMS is working.

@LordVisigoth

Now that you’ve confirmed registration, conduct the final test.

With your phone on LTE (no wifi), use Telnet or wget and repeat the URL test EXCEPT, use your WAN IP directly ( https://WAN.IP.of.PMS:port_number ).

If you don’t get the exact same results then you have confirmed it’s not making it through to the server.

You’re going to have to move things around , possibly write some explicit ACCEPT / PASS rules for iptables / UFW until you figure out where it’s dropping and then can make a permanent configuration change.

You might be able to do a ping ‘spray’ test if your have a computer which on the WAN side. Let it run as you make changes until you see the ping reply from the host.

Thanks for information…

That test WAS from remote host.

VPN to remote site → RDP to host… Run test → Post

I can hook up packet capture of session next if you think that is of value. I just was hoping something in logs would jump out.