Server Version#: 1.18.4.2171
Player Version#: 4.1.12.3
Does anyone know how PMS perform the tests which it uses to to indicate if it is accessible outside the network on the Settings > Remote Access Page?.
The reason I am asking is that I have port-forwarding setup at the router level on the usual port 32400, and with the ExpressVPN App active on the Windows Server PC, I often see the message ‘Not available outside your network’ and router connections from Public to Private IPs marked with a red ‘X’ on the PMS ‘Remote Access’ settings page, even though PMS remains fully accessible when it is addressed either 1) via the router’s Public IP or 2) accessed via remote Plex Apps which are signed into Plex.tv and which presumably know PMS’s usual Public (Router) IP address from an earlier PMS login prior to ExpressVPN running.
This makes me suspect that Plex is testing remote access via the current Public address provided to the Windows Server by ExpressVPN (i.e. which would, unsurprisingly, fail), instead of testing remote access using the routers Public IP address which continues to successfully resolve via port-forwarding to PMS even when ExpressVPN is operating on the Windows Server PC.
Ultimately this behaviour is unhelpful, since it alerts me erroneously to Plex not being available remotely when invariably it actually is.
An insights into the operation of remote access testing by Plex which would help solve this apparent anomaly would be appreciated.
I understand that Plex ‘knows’ the real WAN IP from what was reported prior to ExpressVPN being run, since ExpressVPN is only run periodically on this machine. I expect (but haven’t confirmed) that if I restarted the router (which would force assignment of a new WAN P address by my ISP) when ExpressVPN was running that Plex would no longer ‘know’ what the WAN IP address was and connections would likely fail.
Without further information, I suspect that Plex performs its own tests reported under ‘Remote Access’ using what it currently ‘detects’ as the WAN IP - which when ExpressVPN is running would be the VPN IP - instead of what it last recorded as the PUBLIC IP Address, corresponding to the ‘real’ WAN (Router) IP address.
After activating your tunnel, you must stop/end/quit Plex server and restart it, because only then will it be able to report your new external IP address to plex.tv immediately. plex.tv in turn will perform the accessibility test and will also tell your new external IP all other plex clients which have access permission to your server.
The alternative is to wait ~ 1 hr until plex server will update the external IP address information automatically, or to create an exemption for plex server from the VPN altogether: [How To] Bypass VPN for Plex
Until quite recently, with Plex Bypass running using xFlak’s VPN Bypass scripts, Plex reported it’s accessibility very reliably without any requirement to stop / restart the server.
Indeed just after my last posts I tested the scenario of changing the real WAN IP while ExpressVPN was enabled, and as I predicted all my clients lost access because Plex no longer ‘knew’ what the real IP address was. I then turned off ExpressVPN until Plex could ‘see’ the new WAN IP address, and then restarted the VPN, and my connections continued since these were continuing to be directed by plex.tv to the new WAN IP address that Plex had just reported.
The problem seems to be that the ExpressVPN App no longer supports by-passing (I still see this issue with nedrelid VPN Bypass App running), albeit as long as I don’t refresh the WAN IP address while Plex is running, remote Apps will continue to connect via a combination of the last reported WAN IP and Portforwarding on the router.
I have however confirmed for all intents and purposes that Plex’s own tests reported on the ‘Remote Access’ page are not performed with the PUBLIC IP address it is reporting, but with the PUBLIC IP address that it is detecting.
Updating this. With a couple of tweaks to the bypassed URLs I’ve been able get the Nedrelid VPN Bypass Solution working.
However Plex’s ‘Remote Access’ screen continues to indicate that it is not accessible remotely when it is perfectly accessible via the WAN IP that it is currently displaying / reporting.
