Plex remote access setup on pfsense

dturbes

I am trying to setup remote access on pfsense router for plex that I have on a free nas server. whe I go to plex and click on settings then click on retry it takes a few seconds then says fully accessible outside your network but then about 3 seconds later says not available outside your network. please help I am new to this.
Thanks

Capture1.PNG_thumb

Capture2.PNG_thumb

MORGiON

I found I more reliable to do a port forward for pled rather than using upnp.

duren

If this is the free Plex / not on Plex pass, consider locking it down via basic or digest auth, VPN or two way SSL.

The free Plex is essentially open / admin / no concept of users so anyone can muck with the settings / setup and potentially bring your NAS to a crawl.

GoldFish

@dturbes:

I am trying to setup remote access on pfsense router for plex that I have on a free nas server. whe I go to plex and click on settings then click on retry it takes a few seconds then says fully accessible outside your network but then about 3 seconds later says not available outside your network. please help I am new to this.
Thanks

Had the same issue. For a fraction of a second it would come green and says its accessible and then it would report a red warning saying its not accessible. Infact, it still does the same thing. But i am able to access plex externally. You should try accessing it even if it says otherwise

johnpoz

I access plex all the time remotely via vpn from my phone, etc. I have it locked down to my son's IP and friend IP.. So they can get direct access from their home networks. I have some plex networks that are used for testing allowed, etc..

Just go to canyouseeme.org and test the 32400 port to validate if open or not. There testing with the green little checkmark could just be flawed..

I have it showing green since I added some of the netblocks they access from.. Are you using pfblocker or something - or have limits of what source networks can hit the port forward? They test from a bunch of different networks /12 and /15 from amazon..

Here are some of the networks I have seen them do the test from

54.224.0.0/12
54.160.0.0/12
54.228.0.0/15
54.144.0.0/12
54.194.0.0/15
54.240.0.0/12

There could be many more - could be different for you depending what part of the world your in, etc.

Simple test to validate its open is just go to canyouseeme.org vs their green or red icon ;) And port forward way better than UPnP..

marvosa

I agree with dturbes, instead of enabling uPNP and then trying to control the access with ACL's, why not just setup the port forward?

If you insist on using uPNP with an ACL, it appears the syntax for the IP address in your ACL was formatted incorrectly. You will need to make the following change to your ACL:

allow 32400 192.168.1.166 32400

If you look at the format and the example on the config page:

the [int ipaddr or ipaddr/CIDR] part of the format signifies a single IP address or a range in CIDR notation. Unfortunately, the way it's currently documented leaves room for interpretation which can cause confusion. The devs should really update that section of the format line in the next release.

What you currently have is allowing all IP's from 192.168.1.1 to 192.168.1.254 access to map that port. Is this the main issue? We don't know, but I doubt it's helping.

Quite honestly though, if you consider the time it took you create this thread and upload screen shot, it probably would've taken you a 1/3rd of the time to create the port forward and you would've been done. That's my recommendation. Blow the uPNP config away and create a port forward.

TAC57

@johnpoz I am having this same problem. canyouseeme.org tells me success on my ISP not blocking 32400 (I do have a rule to pass 32400 to my Plex server).

I am running pfBlockerNG-devel, what adjustment would I have to make in pfBlocker?

stephenw10

Try disabling pfBlocker as a test. It depends entirely how you have it configured as to how it would need to be changed.
However if you see the port shown as open on an external test then something is being allowed through and responding to TCP so it's probably not blocked by pfBlocker.

Steve

johnpoz

Unless you were using pfblocker to control inbound traffic, you would not need to do anything on pfblocker.

Do your port forwards use an alias to limit source to a specific geographic region? Do you have some pfblocker rule on your wan blocking?

If can you see me . org is showing you green. Then Atleast the IP(s) where can you see me . org is coming from are allowed.

Where is the client your trying to connect to from? Its possible 32400 is blocked outbound where they are at, etc..

TAC57

@johnpoz I have GeoIP set to Deny Inbound everywhere but North America, where it's set to Match Both.
I'm not using an alias on my 32400 port forwarding rule and I have no pfblocker rules on my WAN interface.
can you me . org says Success (I'm color blind, don't know if it's green).
My friends that are trying to connect are local and they've been able to connect in the past.

@stephenw10 When I disable pfBlocker Plex reports it's Fully accessible.

stephenw10

Geo Blocking is not 100% accurate. Check the alerts page in pfBlocker or the firewall logs (assuming you have logging enabled). Add your friends to the whitelist.

Also it's generally a bad idea to deny the world. You end up with huge IP lists.
Instead pass only what you need and everything else will be dropped by the default deny rule.

Steve

johnpoz

@stephenw10 said in Plex remote access setup on pfsense:

Geo Blocking is not 100% accurate.

You can say that again ;)

If your having a hard time seeing if blocked or allowed. Your friends/family that are having issues.. Have them google what is my ip.. And let you know that that IP is. Then look in the logs for that, or check your lists for that IP or network even.. Then make sure you whitelist it.

In a perfect setup, you would only allow your users IP in, and nothing else. But the problem is - knowing what there IPs are seems to be skill many users do not have.. And they change, and then they use their phones, and its some other IP the phone company is using which changes all the time.. And from geoip that is in a different state even, etc.

I get alerts for any new IP that talks to my plex - you can set that up with tautulli, and I see alerts from all over the country for user when they are using their phones.. And I know they are not traveling ;)

kesawi

The remote access status is Plex is buggy and may show it as not accessible when in fact it is accessible from the internet. There's a fairly lengthy thread over at the Plex forums and the issue has remained unresolved for some time.

https://forums.plex.tv/t/remote-access-connects-for-about-15-seconds-then-disconnects/543913

Try the steps in the following post to check whether your Plex server is actually accessible and the port forward and firewall rules are working.

https://forums.plex.tv/t/remote-access-failure/562725/45

TAC57

@stephenw10 Although I don't have many ports open I do think the GeoIP feature is pretty cool. I'm amaze how many foreign sites are pinging my IP address!

What I don't understand are the mechanics of why blocking everywhere but the US causes problems with Plex remote access, i.e. why a friend in the US causes an unsolicited request to my IP address from somewhere outside of the US.

kesawi

@tac57 Plex's central servers are hosted on AWS and my understanding is user authentication is undertaken via these servers rather than your local Plex server. This may be why your Plex server appears to be receiving an unsolicited request from an unknown IP. Plex's central servers also attempt to periodically connect to your server to verify your remote access status. These servers may be located outside of the US. Plex has a list of server IPs that need to be white listed (See IPs Being Blocked about two thirds of the way down the page at https://support.plex.tv/articles/200931138-troubleshooting-remote-access/

johnpoz

@tac57 said in Plex remote access setup on pfsense:

why blocking everywhere but the US causes problems with Plex remote access

What you could be running into.. Is how they check if plex remote or not.. They use a changing list of IPs to test..

https://s3-eu-west-1.amazonaws.com/plex-sidekiq-servers-list/sidekiqIPs.txt

Which currently are..

34.243.160.122
34.245.172.51
34.248.59.52
52.16.207.132
54.171.49.143
63.34.171.72

Notice those are not US IPs - when plex itself thinks its not available remote you can have issues..

You should prob allow those IPs to talk to your plex - I have the list updated every 6 hours via pfblocker.. Quick look at the firewall log shows them checking..

Here is alias I created - this allows those remote plex IPs (that change) and also status cake - which is free service I use to validate my plex is available remote, and alerts me if its not..

There are multiple sites you can use to monitor, uptime robot, statuscake - they even allow you to create public status pages your users can check ;)

For example here is snip of my status page that my users can access

You can even post announcements there - maybe your going to be down for a bit doing maint or something..

But yeah if your blocking where plex checks if your plex is up, its possible plex telling the users client is down, even though its not. Or if plex thinks its down - possible it doesn't send its public IP - that maybe changed? etc..

While users do report that remote status is buggy - I have never had any issues with it. As with many things like this.. Users not understanding how stuff like this works, and then breaking it or not setting it up correctly.. And they never provide details of what they are actually doing (like blocking some IPs) or quite often if they are using UPnP to get forward and what port on the remote side to use could change.. I personally have had no issues with plex reporting its status.. Then again I monitor my own up status.. And know for a fact when its available or not available..

Providing services to the public internet is a serious business - it should not be taking lightly. You are allowing the internet to talk to something on your network, unsolicited. That could be anyone on the internet - many of who are out to do bad things.. You should take the appropriate steps to keep this as secure as possible. To do that you do need to fully understand how it works, what your doing by forwarding a port. And should put in as many restrictions and monitoring as possible to make sure only the people you want talking to your service are talking to it.

I do limit who can talk to my server (only US and status checking IPs).. I monitor this traffic, via firewall logging. And look at this now and then, I also get alerts any new IPs that actual login to my plex. Via tautulli

I also am not using the normal 32400 port on the public side - while this really is not a security thing. It does help to lower the amount of noise in the log..

edit: BTW - Tobi is not actually in west chicago ;) That is an example how geoip is not all that accurate.. While he is in Chicagoland, he is not in west chicago ;)

stephenw10

Yup, like that. ^

Don't add block rules for everywhere else except the US. Which are all blocked by default anyway.

Add one pass rule for just the US. Plus the other required source IPs.

The resulting ruleset/table size will be far far smaller.

Steve

johnpoz

Should prob add - why I have a list for statuscake.. The FREE version I am using does not allow you to set which locations check on your IP and port your monitoring.. I was seeing false positives on it being down... Because sometimes they would check from non US IPs.. Which were blocked.

If you are having issues with access to plex remote - I would suggest looking into monitoring on your own.. Always nice when you know something is down before your users are calling or texting hey your plex is down ;)

They have all been given status page url as well.. And I tell them - hey if its not working, check status. But if you notice the uptime is pretty freaking good ;) 50 some days on current uptime.. There has even been updates to plex during that. But updates only take couple of minutes - and it only checks every 15.. so you can quite often sneak in an update without taking a hit to your uptime monitor ;)