Why Plex Remote Access Fails Behind a VPN and How to Fix It

Remote access flips to unavailable the moment a VPN takes over the default route, while the same server keeps streaming to the LAN without complaint. Nothing in the Plex logs explains the change, because Plex is not the part that broke: it publishes an address where traffic no longer lands. A provider that shares one public address between customers forwards a port to your tunnel address, and something on your own machine still has to move that port to the Plex listener. All three links must agree on one external port before the reachability test turns green.

The Chain Has Three Links, and Plex Only Sees the Last One

The provider owns a public address and maps one of its ports onto your tunnel address. Your machine takes whatever arrives on that port and redirects it to the Plex listener, which normally sits on loopback port 32400. Plex is then told the external port number so its own probe matches what the outside world dials.

Break any single link and the web interface reports remote access as unavailable, with no hint about which link failed. That silence is why people restart the server, reinstall the app, and toggle the setting over and over without moving the needle. The three links fail independently: a forward aimed at a stale tunnel address, a redirect that only covers the Ethernet interface, and a Plex field still holding 32400 all produce identical red text. Work outward from the listener instead of guessing, and the failing link usually names itself within a minute.

Link One: Forward a Port at the VPN Provider

Open the provider's port forwarding page and add a mapping. Most implementations hand you a random external port and let you choose the internal one, so accept the assignment and point it at the tunnel address your client currently holds. Write that number down, because every later step repeats it exactly.

Providers that rotate the mapping on reconnect are the usual reason this setup survives an evening and then dies. Some let you request a stable port, others reassign one on each handshake, so read the current mapping page before touching anything else.

Link Two: Redirect the Port with a pf Anchor

On macOS the redirect belongs in a pf anchor, one rule per interface that can carry the packet. Write the tunnel rule first and the Ethernet rule second, with the same external port on both, otherwise traffic arriving over Wi-Fi during a failover lands nowhere.

# /etc/pf.anchors/plex.forward
rdr pass on tun0 inet proto tcp from any to any port 41893 -> 127.0.0.1 port 32400
rdr pass on en0 inet proto tcp from any to any port 41893 -> 127.0.0.1 port 32400

The anchor file on its own does nothing; the main configuration has to reference it and load it. Put these two lines in /etc/pf.conf ahead of any existing redirect rules, then reload and read back what the kernel actually accepted.

rdr-anchor "plex"
load anchor "plex" from "/etc/pf.anchors/plex.forward"

sudo pfctl -vnf /etc/pf.anchors/plex.forward
sudo pfctl -f /etc/pf.conf
sudo pfctl -s nat

A syntax complaint about an unknown port means a placeholder survived your edit. An empty nat table means the anchor never loaded, and since pf is not enabled by default on current macOS, sudo pfctl -E belongs to the fix rather than to the optional extras. Reload the anchor after every reboot and after every mapping change. Keep the anchor file in version control so a provider port change becomes a one-line edit rather than a rediscovery exercise.

Link Three: Pin the Same Port Inside Plex

In Plex, open Settings, then Server, then Remote Access, and tick the box that lets you specify a port by hand. Enter the provider's external port rather than 32400, then let the reachability test run. Newer builds moved this control away from the older Connect page, so look under Remote Access if the field is not where a guide claims it is.

Testing from the LAN proves nothing at all. A laptop on the same Wi-Fi reaches the server directly, so the probe succeeds even while the public path is dead. Use a phone on cellular data, or any host outside your network, and dial the public address and external port from there.

Confirm Each Link Before You Blame Plex

Start with the listener and work outward. If Plex is bound only to the LAN address it will ignore a redirect aimed at loopback, so the first command is the one that proves where it listens.

sudo lsof -nP -iTCP:32400 -sTCP:LISTEN

Next, prove the redirect exists and matches the port you handed the provider. The nat table should show the same external port on both interfaces.

sudo pfctl -s nat | grep 41893
nc -vz 203.0.113.42 41893

Run that last command from outside the network, not from the Mac. If the TCP connection completes from cellular while Plex still shows unavailable, the port is reaching the listener and the remaining suspect is the number typed into the Plex field. If nothing answers at all, the break is upstream: the provider mapping, the tunnel address, or pf not being enabled.