pfSense and Plex HTTPS Problem

[reggie14]

I finally got around to installing the new version of Plex with HTTPS support. But, it took me a while to get it working. And I had to do strange enough things that really makes me wonder whether I did it correctly. I know there are some Plex and pfSense users here, so I thought one of you may be able to provide some insight.

After I first installed the update, attempting to log in to my server via the web gave me a warning that "We're sorry, but we can't reach the server securely..."

I use the unbound resolver with my pfDense router, and saw the note on the Plex site about how to bypass DNS Rebinding Attack checks on plex.direct. But, adding that to my router config didn't help.

Then I saw a note on the forum (thanks Google cache) about adding a host override in unbound for plex.direct. That still didn't work. I noticed I could browse to my server by entering plex.direct as the hostname, but I was getting certificate warnings because the name in the certificate didn't match. I also noticed the DNS name embedded in the certificate (*.<hashvalue>.plex.direct) wasn't resolving, which I guessed was the cause of my problem.

I ended up creating a wildcard DNS entry in my unbound configuration, which resolves every *.plex.direct request to the internal IP address of my Plex server. Here's what I added to the "advanced" box in the "DNS Resolver" settings.

server:
local-zone: "plex.direct" redirect
local-data: "plex.direct 3600 IN A <internal-ip>"

This seems overly complex. Can anyone think of why I had to do this? I don't think I ever got NAT reflection working properly on my pfSense server. Any attempt to ask for help about that on the pfSense forums typically results in people yelling at you to use split DNS instead. Do you think that's why it didn't work for me initially, but it (apparently) works for other people?

[reggie14]

Well, my problem appears to be unique, but I'll add to my thread in case someone stumbles upon it.

The fix I described above would likely break any attempts to access external Plex servers. While I will probably never do that, I'd rather not break it.

As I suspected, I made this far more complicated than I needed to. I'm pretty sure unbound on my pfSense box was initially blocking the proper DNS responses from plex.direct due to DNS rebinding attack checks. I thought I disabled those checks for plex.direct, but I missed a step.

Instead of what I previously added to my unbound advanced config, I just needed to add this line:

server:
private-domain: "plex.direct"

[Fuzzy]

I use plex through my pfsense all the time - but i've simply never cared about securing my plex stream.

[reggie14]

Fair enough. It wasn't a feature I was desperate to see. But, I'm going to disable security features if I can avoid it.

The Plex folks did some clever things to get it working. While nothing should have required significant changes on the clients, I imagine getting their plex.direct infrastructure worked out, and working with DigiCert for the CA, probably took a fair bit of the developers cycles. It seemed like development slowed down leading up to the HTTPS release. Maybe we'll see faster development cycles again.

[derringer]

Technically, you shouldn't expose those services directly to the internet anyway. I'd make use of OpenVPN to make a tunnel and then do whatever like you would locally. Theres many ways to make an openvpn tunnel first, and then you lockdown all access from the internet to only allow openvpn. This security model is super safe, super accessible (openvpn clients exist for almost every entry O/S or client,) and it a high security model in this age of security concerns from all directions.

So.. as long as you have local services running, even insecure, you can know that none will be on your local network but your machines (I assume you've also locked down wireless or worked to make it more secure.) It is so much simpler to secure the entry tunnel and then leave things open once you're in.

I can expound if needed, but I recommend you consider the concept..

p.s. I think I misunderstood your question and your referring to just local access? I suppose I will leave my response above, in case it has some value.. I suppose I wouldn't worry too much about using https on a local, trusted network, because of what I've said above. I would try to get it working, but if it gave me problems, I'd just leave it http... if someone is on my local network listening and swiping my packets, I've got bigger issues...

[reggie14]

@derringer

In general I agree with you, but I've made an exception for Plex. I use OpenVPN to access most network resources remotely, but it's particularly convenient to access Plex without a VPN. Why? Mostly two reasons: 1) I sometimes bring a Roku on travel with me to access my Plex server, and there's no OpenVPN client for that, and 2) I can't use my work VPN and OpenVPN at the same time. A third reason is that it would complicate my connection to the Plex server. I'd either have to access the Plex server by internal IP or I'd have to set up my VPN clients to only use my local DNS server running on pfSense (which wouldn't be a problem if I routed all traffic over the VPN, but that frequently kills network performance).

If I hear of some vulnerability in Plex I'd change my tune very, very quickly, but for now I think it's relatively safe to keep Plex remotely accessible.

And, FWIW, you're right that the original issue I had was probably unique to accessing my Plex server locally. But again, as a general rule I really don't like the idea of disabling crypto. If I really had to I would have disabled it, but I didn't it to come to that.