I have several services on my home server, most of which I access using Tailscale, and it works great. I had a couple services on Cloudflare tunnels in order to access them from devices that I can’t put Tailscale on.

Plex is going to start charging for remote access. So I figured now would be the time to migrate to Jellyfin. But using Jellyfin on Cloudflare tunnels is against their TOS. I have a Roku TV at a remote location that I use to watch Plex. I won’t be able to do that anymore. And I can’t put Tailscale on it to serve Jellyfin that way.

I was going to set up Nginx Proxy Manager to use my domain name for Jellyfin so I didn’t have to use Cloudflare tunnels. But in setting that up I found out that my ISP is double NATting me, and I haven’t been able to find a way around it.

So I’m left with two options: 1) buy Plex Pass so I can continue to stream remotely; or 2) get a VPS, run Tailscale and NPM on it and switch to Jellyfin.

I’m looking for a sanity check to make sure the VPS thing would work the way I think it would. If it’s running Tailscale then the double NAT would be a non-issue, correct? Is there another option that I haven’t thought of yet? Which of the two options would you choose?

  • Max-P@lemmy.max-p.meEnglish
    152·
    2 days ago

    I keep hearing claims that it’s not secure enough to be exposed on the Internet, but I can’t seem to find anything about unauthenticated vulnerabilities. It’s got a fair amount of CVEs but they all seem to affect when you’re an already authenticated user, mainly to XSS an admin as a regular user or the likes.

    It’s written in C#, and publicly all you can do is pretty much attempt to log in, this feels like it should be pretty sane compared to some other PHP crap I run.

    Do you have any examples of previous exploits or anything else to be concerned about?

        • ChapulinColorado@lemmy.worldEnglish
          1·
          3 hours ago

          You don’t have to take my word on this, but when you have so many vulnerabilities, the foundation and knowledge about security practices by the developers is missing some key ingredients.

          I use Jellyfin. I like jellyfin. I would like people to use jellyfin, but do it responsibly.

          Citing backwards compatibility is not an acceptable answer either. If individual endpoints and/or protocols (web sockets) are being addressed as separate issues, then there is no overall filter for the most basic thing as checking if the user is authenticated, you know a potential attacker will look for more.

          Will they target jellyfin instead of your average government website with a low budget and similar issues? Unlikely, but possible if the level of effort is low and can potentially create a large botnet, maybe?

          You handle these with overall filters (or whatever they are called on c#) and white lists if something truly needs not to have it instead of reacting when someone reports it.

          The simple fact that some of the code was sending api keys as GET parameters (which get logged cross every access log in the middleware on its way to the target server) and it didn’t raise any flags seems sufficient enough to suggest DO NOT expose jellyfin directly to the internet.