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
You must log in or # to comment.
I used to do all the things mentioned here. Now, I just use Wireguard. If a family member wants to use a service, they need Wireguard. If they don’t want to install it, they dont get the service.
Pangolin could be a solution
Came here to say this. I use wireguard and it simply works.
I started my homelab with a couple exposed services, but frankly the security upkeep and networking headaches weren’t worth the effort when 99% of this server’s usage is at home anyway.
I’ve considered going the Pangolin route to expose a handful of things for family but even that’s just way too much effort for very little added value (plus moving my reverse proxy to a VPS doesn’t sound ideal in case the internet here goes down).
Getting 2 or 3 extra folks on to wireguard as necessary is just much easier.
Full guide to setting up Jellyfin with Reverse Proxy using Caddy and DuckDNS
I followed this video and modified some things like ports
for me the easiest option was to set up tailscale on the server or network where jellyfin runs and then on the client/router where you want to watch the stream.
This is what I do as well. Works super well
This is also what I do, however, each user creates their own tailnet, not an account on mine and I share the server to them.
This way I keep my 3 free users for me, and other people still get to see jellyfin.
Tailscale and jellyfin in docker, add server to tailnet and share it out to your users emails. They have to install tailscale client in a device, login, then connect to your jellyfin. My users use Walmart Onn $30 streaming boxes. They work great.
I struggled for a few weeks to get it all working, there’s a million people saying “I use this” but never “this is how to do it”. YouTube is useless because it’s filled with “jellyfin vs Plex SHOWDOWN DEATH FIGHT DE GOOGLE UR TOILET”.
For the users you have using Onn TVs, is Tailscale just installed on a device on the network or on the Onn TVs?
The onn boxes run android so it’s just installed as an app from play store. The users connect with their own tailscale account. My server is shared so they see it. Then they install jellyfin on the device, punch in the hostname of the server given by tailscale and the port and then it connects.
I could not get my reverse proxy to let them use my local domain… I’m not smart enough and couldn’t figure it out but they are only using jellyfin so typing one address was fine.
We have it open to the public, behind a load balancer URL filtering incomming connection, https proxied through cloudflare with a country filter in place
I use a VPS and a wiregusrd tunnel.
I’m currently using CF Tunnels and I’m thinking about this (I have pretty good offers for VPS as low as $4 a month)
Can you comment on bandwidth expectations? My concern is that I also tunnel Nextcloud and my offsite backups and I may exceed the VPS bandwidth restrictions.
BTW I’m testing Pangolin which looks AWESOME so far.
I am using the free Oracle VPS offer until they block me, so far I have no issue. Alzernatively I wanted to check out IONOS, since you dont have a bandwidth limit there.
WOW! That’s one hell of a deal. You’ve convinced me XD I’m installing pangolin Right now. The hell with Cloudflare and their evil ways
VPN or Tailscale
Tailscale - funnel
Just that
for me i just needed a basic system so my family could share so I have it on my pc, then I registered a subdomain and pointed it to my existing ec2 server with apache using a proxy which points to my local ip and port then I opened the jellyfin port on my router
and I have certbot for my domain on ec2 :)
Who are you using for your domain? I was told if I used cloudfair they would ban me for having streaming traffic over their DNS.
You can use cloudflares DNS and not use their WAF (the proxy bit) just fine. I have been for almost a decade.
Nginx in front of it, open ports for https (and ssh), nothing more. Let’s encrypt certificate and you’re good to go.
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.
In a perfect world, yes. But not as a beginner, I guess?
It’s beginner level, the hard part is the reverse proxy, once you have a grasp on that just having it on a dedicated box in a segmented portion on your firewall designated as the DMZ is easy. Id even go so far as to say its the bare minimum if you’re even considering exposing to the internet.
It doesn’t even need to be all that powerful since its just relaying packets as a middleman
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 agree, but SSH is more secure than Jellyfin. it shouldn’t be exposed like that, others in the comments already pointed out why
Cool if I understand only some of things that you have said. So you have a beginner guide I could follow?
Take a look at Nginx Proxy Manager and how to set it up. But you’ll need a domain for that. And preferably use a firewall of some sort on your server and only allow said ports.
I’ve look a little on it, didn’t understand most of it. I’m looking for a comprehensive beginner guide before going foward
This isn’t a guide, but any reverse proxy allows you to limit open ports on your network (router) by using subdomains (thisPart.website.com) to route connections to an internal port.
So you setup a rev proxy for jellyfin.website.com that points to the port that jf wants to use. So when someone connects to the subdomain, the reverse proxy is hit, and it reads your configuration for that subdomain, and since it’s now connected to your internal network (via the proxy) it is routed to the port, and jf “just works”.
There’s an ssl cert involved but that’s the basic understanding. Then you can add Some Other Services at whatever.website.com and rinse and repeat. Now you can host multiple services, without exposing the open ports directly, and it’s easy for users as there is nothing “confusing” like port numbers, IP addresses, etc.
So I’m another newbie dummy to reverse proxies. I’ve got my jellyfin accessible at jellyfin.mydomain.com but I can only access it through the web. How do I share with other people who want to use the apps? I can’t get my apps to find my instance.
Can “your apps” access it when their device isn’t on your home LAN?
That was the problem, I couldn’t access anything away from my LAN. I finally figured it out though. I’m using Pangolin to access my services outside of my LAN and by default it adds a SSO option. Once I turned that off, my iPhone app was able to find my server through my domain name just fine. Thanks!
I would not publicly expose ssh. Your home IP will get scanned all the time and external machines will try to connect to your ssh port.
i have ssh on a random port and only get so many scan, so low that fail2ban never banned anyone that was not myself (accidentally).
Sorry, misunderstanding here, I’d never open SSH to the internet, I meant it as “don’t block it via your server’s firewall.”
Change the port it runs on to be stupid high and they won’t bother.
Yeah hey what’s your IP address real quick? No reason
In 3 years I haven’t had a single attempted connection that wasn’t me. Once you get to the ephemeral ports nobody is scanning that high.
I’m not saying run no security or something. Just nobody wants to scan all 65k ports. They’re looking for easy targets.
Just nobody wants to scan all 65k ports.
Shodan has entered the chat.
They can try all they like, man. They’re not gonna guess a username, key and password.
Doesn’t take that to leverage an unknown vulnerability in ssh like:
That’s why it’s common best practice to never expose ssh to raw internet if you can help it; but yes it’s not the most risky thing ever either.
If you’re going to open something, SSH is far, far more battle-tested than much other software, even popular software. Pragmatically, If someone is sitting on a 0-day for SSH, do you genuinely think they’re gonna waste that on you and me? Either they’re gonna sell it to cash out as fast as possible, or they’ll sit on it while plotting an attack against someone who has real money. It is an unhealthy level of paranoia to suggest that SSH is not secure, or that it’s less secure than the hundreds of other solutions to this problem.
Here is my IP address, make me eat my words.
2a05:f6c7:8321::164 | 89.160.150.164Are you giving random strangers legal permission to pentest you? That’s bold.
I linked a relevant vulnerability, but even ignoring that, pragmatically, you feel they’d be targeting specific targets instead of just what they currently do? (That, by the way, is automating the compromise of vulnerable clients in mass scale to power botnets). Any service you open on your device to the internet is inherently risky. Ssh best practices are, and have been since the early days, not to expose it to the internet directly.
You did link a vulnerability! That is true. I didn’t claim SSH had a clean track record, I claimed it had a better track record than most other software. That vulnerability is hard to exploit, and generates a lot of noise if you were to try, which nobody has because it’s never been found in the wild.
People who sit on 0-days for critical software like SSH don’t go out and try to mass-exploit it because it will be found within the day and patched within the week once they start making noise. This is not a quiet exploit. If they’re smart, they sell it. If they’re ambitious, they build an elaborate multi-chain attack against a specific target. Only 0.14% of devices vulnerable to this exploit are EoL versions of OpenSSH, so once this was patched, it was no longer a useful attack vector.
It would also have been completely negated by fail2ban, which is prominently deployed on internet facing SSH, as it required thousands and thousands of connection attempts to trigger the condition. It could also have been mitigated by not running sshd as root, though I understand that most people don’t want to deal with that headache even though it is possible.
There are thousands of independent honeypots that sit quietly and sniff all the mass-attacks and they earn their daily bread by aggregating and reporting this data. If you run a mass exploit, you will be found within the day. Trust me, I burned an IP address by regularly scanning the whole IPv4 space. You are going to end up on blacklists real fuckin’ fast and whatever you were doing will be noticed and reported.
If you’re going to open something, SSH is a very safe choice. But yes, don’t open it if you don’t need it. We are discussing how to open a service to the internet safely, though, so we need it.
🤔🤔🤔🤔🤔
Are we living in the same universe? In mine software doesn’t get patched all the time, in fact it’s usually a lack of patches that lead to any significant system compromise… Which happens time and time again. Also you’re on a thread that is advising hobbiests on how to configure and maintain their personal server, not the engineering meeting for a fortune 500. Yes, you can make ssh very secure. Yes, it’s very secure even by default. In the same regard, new vulnerabilities/exploits will be found, and it remains best practice not to expose ssh to raw internet unless absolutely necessary and with the considerations required to mitigate risk. Ssh isn’t even implemented identically on every device, so you literally cannot talk about it like you are. Idk why you’re arguing against the industry standard for best practices decided by people who have far more experience and engineering time than you or I.
You got balls to post you public addresses like that… I mean I agree with you wholeheartedly and I also have SSH port forwarded on my firewall, but posting your public IP is next-level confidence.
Respect.
That is some big dick energy ngl
Well, having a domain is basically documenting your IP publicly. It’s not that risky.
Well, those won’t typically have ssh exposed on them. But we could argue what is more risky to have exposed, ssh or http. Any publicly available server could be vulnerable, it’s just very unlikely these days (with up to date software).
Plot twost, That it’s neighbor ip
I remember that one. Those are pretty rare and usually involve a specific configuration that is often not the default, though, right? When such a vulnerability is found, is it rightly so major news.
“This race condition affects sshd in its default configuration.” direct quote from the linked article, paragraph like… 3. I linked it so people could read, not speculate.
Ah, now I remember. It took a quick configuration change to mitigate this. Still, I’d call this very rare.
I’m going side with @[email protected] on this one.
Agreed, but best practices are meant to deal with the very rare. They didn’t put the vulnerabilities in the software due to negligence or malice, it’s just an ever evolving arms race with cracks that show up due to layer upon layer of abstraction. Again I’m not saying to never expose ssh to the net, quite the opposite, but as a best practice you should never do it unless you fully understand the risk and are prepared to deal with any potential consequences. That’s just a core tenant of understanding security posture.
Only the failed attempts could be a Denial Of Service and throw you out. So, at least add an ever increasing delay to those. Fail2ban is important.
fail2ban with endlessh and abuseipdb as actions
Anything that’s not specifically my username or git gets instantly blocked. Same with correct users but trying to use passwords or failing authentication in any way.
Youve minimized login risk, but not any 0 days or newly discovered vulnerabilites in your ssh server software. Its still best to not directly expose any ports you dont need to regularly interact with to the internet.
Also, Look into crowdsec as a fail2ban replacement. Its uses automatically crowdsourced info to pre block IPs. A bit more proactive compared to abuseipdb manual reporting.
I have the firewall of my VPS reject any IP range except the ones I’m on frequently, that is mobile, home and work. Sucks when you travel, but otherwise works alright.
Still exposes ports to some people on the same mobile or home internet service networks…
So? Pubkey login only and fail2ban to take care of resource abuse.
Unifi teleport. A zero configuration VPN to my home network.
I’m fidgeting with Tailscale but I find this solution some what lacking
Tailscale is great for not opening your ports to the internet. Having it playable on a friend’s appletv adds some extra complexity. Reverse proxy on a subdomain with something like fail2ban would work, but it does leave you more vulnerable.
Over the top for security would be to setup a personal VPN and only watch it over the VPN. If you are enabling other users and you don’t want them on your network; using a proxy like nginx is the way.
Being new to this I would look into how to set these things up in docker using docker-compose.
Personally I use twingate, free for 5 users and relatively straightforward to set up.
I’m fidgeting with Tailscale right now, only to stream on a AppleTV at a friend house. So far no luck but that’s not me that set up Infuse, so could be an operator error on my friend part
I tried tailscale first but to be honest wasn’t a fan. I moved to Twingate and found it much simpler to set up
Will look into it, thanks !
The way I do it for a family member with Tailscale is them having a couple of boxes down there (n100 with their Jellyfin server, and a RPI4 with a TVHServer) with my Tailnet signed in, and those boxes running both a “subnet router” and an "exit node"that both me and said fam member can use.
This means she has permissions to use the exit node wherever like I do to my own local LAN, to connect to her LAN and access things locally since you can assign them via the ACL’s / device perms.
I know reading docs can suck sometimes but honest to god the ones that Tailscale put up are pretty awesome.
Along with all the YT videos about it I didn’t even have to go nagging on forums to get it to work, and that’s a general first for me.
Set up a VPN, use PiVPN
I’ll try looking into that
Just remember to test with something better than your phone, T-Mobile aggressively filters VPNs. Try a coffee shop.
Not in the US, most providers are asshole-y but seems less asshole that T-Mobile
@TribblesBestFriend domain name, reverse proxy and a static ip address
I’ve read about that. Any useful beginner walktrough to suggest ?
For my travel devices, I use Tailscale to talk to the server. For raw internet, I use their funnel feature to expose the service over HTTPS. Then just have fail2ban watching the port to make sure no shenanigans or have the entire service offlined until I can check it.
