Jellyfin over the internet
-
While technically not strictly necessary, it adds more robust authentication methods, and makes it easier to build out other apps if you want to in the future without having to re-do the sign-in process for all of your users. You can have things like 2fa and other things that make it harder for bots to get in and easier for users to stay in. It also makes it easier to keep track of login attempts and notice compromised accounts.
Edit: There are also alternatives like authelia that may be easier to implement. I don't really trust most web apps to be ultra secure with internet-facing sign-in pages so it just feels like "good practice" to hide behind an auth service whose sole purpose is to be written and built securely. Plus once you learn how to set up fail2ban with an auth service, there will be no need to re-learn or re-implement it if you add a 2nd app/service. Very modular and makes testing and adding new things much easier.
Another benefit is that it has a nice GUI. I can look at logins, add services, stuff like that without touching config files which will be nice for those who don't like wading through text files to change config.
Can authentik pass through the authentication to Jellyfin, or do you just log in twice?
-
Can authentik pass through the authentication to Jellyfin, or do you just log in twice?
wrote last edited by [email protected]It can pass through. There is even an official Authentik guide on the various methods specifically for Jellyfin: https://integrations.goauthentik.io/integrations/services/jellyfin/
Same with Authelia, though I don't have a link for that on hand.
-
I have had Jellyfin directly open to the Internet with a reverse proxy for years. No problems.
wrote last edited by [email protected]If your reverse proxy only acknowledges jellyfin exists if the hostname is correct, you won't get discovered by an IP scanner.
Mine's on jellyfin.[domain].com and you get a completely different page if you hit it by IP address.
If it does get found, there's also a fail2ban to rate-limit someone brute-forcing a login.
I've always exposed my home IP to the internet. Haven't had an issue in the last 15 years. I'm running about 10 public-facing services including NTP and SMTP.
-
What’s your go too (secure) method for casting over the internet with a Jellyfin server.
I’m wondering what to use and I’m pretty beginner at this
Cheap VPS with Pangolin for Wireguard and reverse proving through the tunnel.
-
Also run the reverse proxy on a dedicated box for it in the DMZ
Honestly you can usually just static ip the reverse proxy and open up a 1:1 port mapping directly to that box for 80/443. Generally not relevant to roll a whole DMZ for home use and port mapping will be supported by a higher % of home routing infrastructure than DMZs.
-
What’s your go too (secure) method for casting over the internet with a Jellyfin server.
I’m wondering what to use and I’m pretty beginner at this
Tailscale
-
I see everyone in this thread recommending a VPN or reverse proxy for accessing Jellyfin from outside the LAN. While I generally agree, I don't see a realistic risk in exposing Jellyfin directly to the internet.
It supports HTTPS and certificates nowadays, so there’s no need for outside SSL termination anymore.(See Edit 2)In my setup, which I've been running for some time, I've port-forwarded only Jellyfin's HTTPS port to eliminate the possibility of someone ending up on pure HTTP and sending credentials unencrypted. I've also changed the Jellyfin's default port to a non-standard one to avoid basic port-scanning bots spamming login attempts. I fully understand that this falls into the security through obscurity category, but no harm in it either.
Anyone wanna yell at me for being an idiot and doing everything wrong? I'm genuinely curious, as the sentiment online seems to be that at least a reverse proxy is almost mandatory for this kind of setup, and I'm not entirely sure why.
Edit: Thank you everyone for your responses. While I don't agree with everything, the new insight is appreciated.
Edit 2: I've been informed that infact the support for HTTPS will be removed in a future version. From v10.11 release notes:
Deprecation Notice: Jellyfin’s internal handling of TLS/SSL certificates and configuration in the web server will be removed in a future version. No changes to the current system have been made in 10.11, however future versions will remove the current system and instead will provide advanced instructions to configure the Kestrel webserver directly for this relatively niche usecase. We strongly advise anyone using the current TLS options to use a Reverse Proxy for TLS termination instead if at all possible, as this provides a number of benefits
It's difficult to say exactly what all a reverse proxy adds to the security conversation for a handful of reasons, so I won't touch on that, but the realistic risk of exposing your jellyfin instance to the internet is about the same as handing your jellyfin api over to every stranger globally without giving them your user account or password and letting them do whatever they'd like for as long as they'd like. This means any undiscovered or unintentional vulnerability in the api implementation could easily allow for security bypass or full rce (remote code execution, real examples of this can be found by looking at the history of WordPress), but by siloing it behind a vpn you're far far far more secure because the internet at large cannot access the apis even if there is a known vulnerability. I'm not saying exposing jellyfin to the raw web is so risky it shouldn't be done, but don't buy into the misconception that it's even nearly as secure as running a vpn. They're entirely different classes of security posture and it should be acknowledged that if you don't have actual use for internet level access to jellyfin (external users, etc, etc) a vpn like tailscale or zero tier is 100% best practice.
-
Is Nginx Proxy Manager running on the VPS itself and then the proxy routes across the wireguard to your home server? Or is the VPS just port forwarding to your home server which runs the proxy?
My goal was to have no ports exposed on my home network so the proxy is on the VPS. My home server connects over wireguad to the vps, then all the traffic is routed over wireguard to the home server which only listens on wireguard.
-
What’s your go too (secure) method for casting over the internet with a Jellyfin server.
I’m wondering what to use and I’m pretty beginner at this
I use a cloudflare tunnel, ISP won't give me a static IP and I wanna keep my firewall locked down tight.
-
I was just trying to get a setup like this going yesterday. I used standard Wiregaurd and got that working between the VPS and home server, but I was trying to set up Caddy as a reverse proxy to direct the incoming traffic through the WG VPN to my services. I wasnt able to figure it out yesterday. Everyone online says Caddy is so simple, but I'm such a noob I just have no idea what it's doing or how to troubleshoot.
I've also really struggled with Caddy despite everyone saying its so simple. I'm pretty new to all this, but I had better luck with Traefik - I now actually have a reverse proxy up and running correctly, which I haven't been able replicate with Caddy.
Traefik labels make sense to me in a way Caddy does not.
-
I was just trying to get a setup like this going yesterday. I used standard Wiregaurd and got that working between the VPS and home server, but I was trying to set up Caddy as a reverse proxy to direct the incoming traffic through the WG VPN to my services. I wasnt able to figure it out yesterday. Everyone online says Caddy is so simple, but I'm such a noob I just have no idea what it's doing or how to troubleshoot.
wrote last edited by [email protected]I havent tried with caddy but i might be able to help you get it working if you wanna chat some time. My contact info is on my website.
-
I've also really struggled with Caddy despite everyone saying its so simple. I'm pretty new to all this, but I had better luck with Traefik - I now actually have a reverse proxy up and running correctly, which I haven't been able replicate with Caddy.
Traefik labels make sense to me in a way Caddy does not.
I appreciate this response. I'll try booting up traefik later.
I think Caddy just abstracts things to such a great degree that if you dont already know what it's supposed to do, it's harder to learn what you're doing with it. I'm sure plenty of others have stepped right up and loved the "two line config" without already understanding the basics, but it's not clicking for me.
-
Nginx in front of it, open ports for https (and ssh), nothing more. Let's encrypt certificate and you're good to go.
Why would you need to expose SSH for everyday use? Or does Jellyfin require it to function?
Maybe leave that behind some VPN access.
-
I see everyone in this thread recommending a VPN or reverse proxy for accessing Jellyfin from outside the LAN. While I generally agree, I don't see a realistic risk in exposing Jellyfin directly to the internet.
It supports HTTPS and certificates nowadays, so there’s no need for outside SSL termination anymore.(See Edit 2)In my setup, which I've been running for some time, I've port-forwarded only Jellyfin's HTTPS port to eliminate the possibility of someone ending up on pure HTTP and sending credentials unencrypted. I've also changed the Jellyfin's default port to a non-standard one to avoid basic port-scanning bots spamming login attempts. I fully understand that this falls into the security through obscurity category, but no harm in it either.
Anyone wanna yell at me for being an idiot and doing everything wrong? I'm genuinely curious, as the sentiment online seems to be that at least a reverse proxy is almost mandatory for this kind of setup, and I'm not entirely sure why.
Edit: Thank you everyone for your responses. While I don't agree with everything, the new insight is appreciated.
Edit 2: I've been informed that infact the support for HTTPS will be removed in a future version. From v10.11 release notes:
Deprecation Notice: Jellyfin’s internal handling of TLS/SSL certificates and configuration in the web server will be removed in a future version. No changes to the current system have been made in 10.11, however future versions will remove the current system and instead will provide advanced instructions to configure the Kestrel webserver directly for this relatively niche usecase. We strongly advise anyone using the current TLS options to use a Reverse Proxy for TLS termination instead if at all possible, as this provides a number of benefits
The issue is not encryption, it's the unauthenticated API. People can interact with your server without an account.
-
I see everyone in this thread recommending a VPN or reverse proxy for accessing Jellyfin from outside the LAN. While I generally agree, I don't see a realistic risk in exposing Jellyfin directly to the internet.
It supports HTTPS and certificates nowadays, so there’s no need for outside SSL termination anymore.(See Edit 2)In my setup, which I've been running for some time, I've port-forwarded only Jellyfin's HTTPS port to eliminate the possibility of someone ending up on pure HTTP and sending credentials unencrypted. I've also changed the Jellyfin's default port to a non-standard one to avoid basic port-scanning bots spamming login attempts. I fully understand that this falls into the security through obscurity category, but no harm in it either.
Anyone wanna yell at me for being an idiot and doing everything wrong? I'm genuinely curious, as the sentiment online seems to be that at least a reverse proxy is almost mandatory for this kind of setup, and I'm not entirely sure why.
Edit: Thank you everyone for your responses. While I don't agree with everything, the new insight is appreciated.
Edit 2: I've been informed that infact the support for HTTPS will be removed in a future version. From v10.11 release notes:
Deprecation Notice: Jellyfin’s internal handling of TLS/SSL certificates and configuration in the web server will be removed in a future version. No changes to the current system have been made in 10.11, however future versions will remove the current system and instead will provide advanced instructions to configure the Kestrel webserver directly for this relatively niche usecase. We strongly advise anyone using the current TLS options to use a Reverse Proxy for TLS termination instead if at all possible, as this provides a number of benefits
I don't disagree, and I am one of the VPN advocates you mention. Generally there is no issue with exposing jellyfin via proxy to the internet.
The original question seemed to imply an over-secure solution so a lot of over-secure solutions exist. There is good cause to operate services, like jellyfin, via some permanent VPN.
-
What’s your go too (secure) method for casting over the internet with a Jellyfin server.
I’m wondering what to use and I’m pretty beginner at this
Jellyfin through a traefik proxy, with a WAF as middleware and brute force login protected by fail2ban
-
I see everyone in this thread recommending a VPN or reverse proxy for accessing Jellyfin from outside the LAN. While I generally agree, I don't see a realistic risk in exposing Jellyfin directly to the internet.
It supports HTTPS and certificates nowadays, so there’s no need for outside SSL termination anymore.(See Edit 2)In my setup, which I've been running for some time, I've port-forwarded only Jellyfin's HTTPS port to eliminate the possibility of someone ending up on pure HTTP and sending credentials unencrypted. I've also changed the Jellyfin's default port to a non-standard one to avoid basic port-scanning bots spamming login attempts. I fully understand that this falls into the security through obscurity category, but no harm in it either.
Anyone wanna yell at me for being an idiot and doing everything wrong? I'm genuinely curious, as the sentiment online seems to be that at least a reverse proxy is almost mandatory for this kind of setup, and I'm not entirely sure why.
Edit: Thank you everyone for your responses. While I don't agree with everything, the new insight is appreciated.
Edit 2: I've been informed that infact the support for HTTPS will be removed in a future version. From v10.11 release notes:
Deprecation Notice: Jellyfin’s internal handling of TLS/SSL certificates and configuration in the web server will be removed in a future version. No changes to the current system have been made in 10.11, however future versions will remove the current system and instead will provide advanced instructions to configure the Kestrel webserver directly for this relatively niche usecase. We strongly advise anyone using the current TLS options to use a Reverse Proxy for TLS termination instead if at all possible, as this provides a number of benefits
wrote last edited by [email protected]Jellyfin has a whole host of unresolved and unmitigated security vulnerabilities that make exposing it to the internet. A pretty poor choice.
-
It feels like everything is a tradeoff and I think a setup like this reduces the complexity for people you share with.
If you added fail2ban along with alert email/notifications you could have a chance to react if you were ever targeted for a brute force attempt. Jellyfin docs talk about setting this up for anyone interested.
Blocking IP segments based on geography of countries you don't expect connections from adds the cost of a VPN for malicious actors in those areas.
Giving Jellyfin its own VLAN on your network could help limit exposure to your other services and devices if you experience a 0day or are otherwise compromised.
Fail2ban isn't going to help you when jellyfin has vulnerable endpoints that need no authentication at all.
-
If your reverse proxy only acknowledges jellyfin exists if the hostname is correct, you won't get discovered by an IP scanner.
Mine's on jellyfin.[domain].com and you get a completely different page if you hit it by IP address.
If it does get found, there's also a fail2ban to rate-limit someone brute-forcing a login.
I've always exposed my home IP to the internet. Haven't had an issue in the last 15 years. I'm running about 10 public-facing services including NTP and SMTP.
Please to see: https://github.com/jellyfin/jellyfin/issues/5415
Someone doesn't necessarily have to brute Force a login if they know about pre-existing vulnerabilities, that may be exploited in unexpected ways
-
Wireguard.
wrote last edited by [email protected]and a local reverse proxy that can route through wireguard when you want to watch on a smart tv.
its not as complicated as it sounds, it's just a wireguard client, and a reverse proxy like on the main server.
it can even be your laptop, without hdmi cables
