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.
Nginx in front of it, open ports for https (and ssh), nothing more. Let’s encrypt certificate and you’re good to go.
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.
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.
Ssh has nothing to do with scanning. Your IP and everyone else up is being scanned constantly. In ipv4 space at least.
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.
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
Wireguard.
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
You can also use a router that can run wireguard/openvpn and have that run the tunnel back to home for you. I’ve got a portable GL-Inet router with OpenWRT that I use for this when I’m on the road
or that yes, but I often don’t want to give the whole network access to my home network for security reasons, so that’s something to consider
How would you do this off network?
what do you mean by off network? on the wifi of a different home’s network, that has internet access?
the wireguard client on your laptop is supposed to give the laptop (and the laptop only) access to your home network, and the reverse proxy running on the laptop is supposed to give local devices access to services at home selectively, by listening on port 443 on the local network, and processing requests to services that you defined, by forwarding them through the vpn tunnel.
this requires that a machine at home runs a wireguard server, and that its port is forwarded in your router
deleted by creator
lemm.ee :‘’'(
deleted by creator
I think my approach is probably the most insane one, reading this thread…
So the only thing I expose to the public internet is a homemade reverse proxy application which supports both form based and basic authentication. The only thing anonymous users have access to is the form login page. I’m on top of security updates with its dependencies and thus far I haven’t had any issues, ever. It runs in a docker container, on a VM, on Proxmox. My Jellyfin instance is in k8s.
My mum wanted to watch some stuff on my Jellyfin instance on her Chromecast With Google TV, plugged into her ancient Dumb TV. There is a Jellyfin Android TV app. I couldn’t think of a nice way to run a VPN on Android TV or on any of her (non-existent) network infra.
So instead I forked the Jellyfin Android TV app codebase. I found all the places where the API calls are made to the backend (there are multiple). I slapped in basic auth credentials. Recompiled the app. Deployed it to her Chromecast via developer mode.
Solid af so far. I haven’t updated Jellyfin since then (6 months), but when I need to, I’ll update the fork and redeploy it on her Chromecast.
What an absolute gigachad XD
Clever, but very hands on
VERY hands on, wouldn’t recommend it haha.
But that’s the beauty of open source. You CAN do it
Jellyfin isn’t secure and is full of holes.
That said, here’s how to host it anyway.
- Wireguard tunnel, be it tailscale, netbird, innernet, whatever
- A vps with a proxy on it, I like Caddy
- A PC at home with Jellyfin running on a port, sure, 8096
If you aren’t using Tailscale, make your VPS your main hub for whatever you choose, pihole, wg-easy, etc. Connect the proxy to Jellyfin through your chosen tunnel, with ssl, Caddy makes it easy.
Since Jellyfin isn’t exactly secure, secure it. Give it its own user and make sure your media isn’t writable by the user. Inconvenient for deleting movies in the app, but better for security.
more…
Use fail2ban to stop intruders after failed login attempts, you can force fail2ban to listen in on jellyfin’s host for failures and block ips automatically.
More!
Use Anubis and yes, I can confirm Anubis doesn’t intrude Jellyfin connectivity and just works, connect it to fail2ban and you can cook your own ddos protection.
MORE!
SELinux. Lock Jellyfin down. Lock the system down. It’s work but it’s worth it.
I SAID MORE!
There’s a GeoIP blocking plugin for Caddy that you can use to limit Jellyfin’s access to your city, state, hemisphere, etc. You can also look into whitelisting in Caddy if everyone’s IP is static. If not, ddns-server and a script to update Caddy every round? It can get deep.
Again, don’t do any of this and just use Jellyfin over wireguard like everyone else does(they don’t).
Wow, a “for dummies” guide for doing all this would be great 😊 know of any?
If you aren’t already familiarized with the Docker Engine - you can use Play With Docker to fiddle around, spin up a container or two using the
docker runcommand, once you get comfortable with the command structure you can move into Docker Compose which makes handling multiple containers easy using.ymlfiles.Once you’re comfortable with compose I suggest working into Reverse Proxying with something like SWAG or Traefik which let you put an domain behind the IP, ssl certificates and offer plugins that give you more control on how requests are handled.
There really is no “guide for dummies” here, you’ve got to rely on the documentation provided by these services.
Thnx :]
I figured infodump style was a bit easier for me at the time so anyone could take anything I namedropped and go search to their heart’s content.
deleted by creator
I’ve recently been working on my own server and a lot of this stuff can be accomplished by just chatting with chatgpt/gemini or any ai agent of your choosing. One thing to note tho is that they have some outdated information due to their training data so you might have to cross reference with the documentation.
Use docker as much as you can, this will isolate the process so even if somehow you get hacked, the visibility the hackers get into your server is limited to the docker container.
My go to secure method is just putting it behind Cloudflare so people can’t see my IP, same as every other service. Nobody is gonna bother wasting time hacking into your home server in the hopes that your media library isn’t shit, when they can just pirate any media they want to watch themselves with no effort.
Nobody is gonna bother wasting time hacking into your home server
They absolutely will lol. It’s happening to you right now in fact. It’s not to consume your media, it’s just a matter of course when you expose something to the internet publicly.
No, people are probing it right now. But looking at the logs, nobody has ever made it through. And I run a pretty basic setup, just Cloudflare and Authelia hooking into an LDAP server, which powers Jellyfin. Somebody who invests a little more time than me is probably a lot safer. Tailscale is nice, but it’s overkill for most people, and the majority of setups I see posted here are secure enough to stop any random scanning that happens across them, if not dedicated attention.
No, they are actively trying to get in right now. If you have Authelia exposed they’re brute forcing it. They’re actively trying to exploit vulnerabilities that exist in whatever outwardly accessible software you’re exposing is, and in many cases also in software you’re not even using in scattershot fashion. Cloudflare is blocking a lot of the well known CVEs for sure, so you won’t see those hit your server logs. If you look at your Authelia logs you’ll see the login attempts though. If you connect via SSH you’ll see those in your server logs.
You’re mitigating it, sure. But they are absolutely 100% trying to get into your server right now, same as everyone else. There is no consideration to whether you are a self hosted or a Fortune 500 company.
No, they are actively trying to get in right now. If you have Authelia exposed they’re brute forcing it.
No, they aren’t. Just to be sure, I just checked it, and out of the over 2k requests made to the Authelia login page in the last 24 hours, none have made it to the login page itself. You don’t know jack shit about what’s going on in another persons network, so I’m not sure why you’re acting like some kind of expert.
Yes they are. The idea that they’re not would be a statistical wonder.
2k requests made to the Authelia login page in the last 24 hours
Are you logging into your Authelia login page 2k times a day? If not, I suspect that some (most) of those are malicious lol.
You don’t know jack shit about what’s going on in another persons network
It’s the internet, not your network. And I’m well aware of how the internet works. What you’re trying to argue here is like arguing that there’s no possible way that I know your part of the earth revolves around the sun. Unless you’re on a different internet from the rest of us, you’re subject to the same behavior. I mean I guess I didn’t ask if you were hosting your server in North Korea but since you’re posting here, I doubt it.
I’m not sure why you’re acting like some kind of expert
Well I am an expert with over a decade of experience in cybersecurity, but I’m not acting like an expert here, I’m acting like somebody with at least a rudimentary understanding of how these things work.
Yes they are. The idea that they’re not would be a statistical wonder.
Guess I’m a wonder then. I’ve always thought of myself as pretty wonderful, I’m glad to hear you agree.
Are you logging into your Authelia login page 2k times a day? If not, I suspect that some (most) of those are malicious lol.
That’s 2k requests made. None of them were served. Try to keep up.
Well I am an expert with over a decade of experience in cybersecurity, but I’m not acting like an expert here, I’m acting like somebody with at least a rudimentary understanding of how these things work.
Then I guess I should get a career in cybersecurity, because I obviously know more than someone with over a decade of supposed experience. If you were worth whatever your company is paying you in wages, you would know that a rule blocking connections from other countries, and also requiring the request for the login page come from one of the services on your domain, will block virtually all malicious attempts to access your services. Such a rule doesn’t work for a public site, but for a selfhosted setup it’s absolutely an easy option to reduce your bandwidth usage and make your setup far more secure.
a rule blocking connections from other countries, and also requiring the request for the login page come from one of the services on your domain, will block virtually all malicious attempts to access your services.
Whoa whoa whoa. What malicious attempts?
You just told me you were the statistical wonder that nobody is bothering attack?
That’s 2k requests made. None of them were served.
So those 2k requests were not you then? They were hostile actors attempting to gain unauthorized access to your services?
Well there we have it folks lmao
What a bunch of B’s. Sure your up gets probed it’s happening to every ipv4 address all the time. But that is not hacking.
Anything you expose to the internet publicly will be attacked, just about constantly. Brute force attempts, exploit attempts, the whole nine. It is a ubiquitous and fundamental truth I’m afraid. If you think it’s not happening to you, you just don’t know enough about what you’re doing to realize.
You can mitigate it, but you can’t stop it. There’s a reason you’ll hear terms like “attack surface” used when discussing this stuff. There’s no “if” factor when it comes to being attacked. If you have an attack surface, it is being attacked.
Yup, the sad reality is that you don’t need to worry about the attacks you expect; You need to worry about the ones you don’t know anything about. Honeypots exist specifically to alert you that something has been breached.
Couple questions here.
What is a honeypot? I’ve only heard it in terms of piracy.
Also, what steps can someone take to reinforce this attack layer? You have an infograph or something people can google search their way through?
A honeypot is something that is intentionally left available, to alert you when it gets hit. In practice, they’re just a tool to tell security specialists when they need to start worrying; They wouldn’t be used by the average user at all.
The goal is to build your security like layers, and ideally have all of your services behind the secure walls. Between these layers, you have honeypots. If someone gets through your first layer of security but hits the honeypot, you know someone is sniffing around, or maybe has an exploit for your outer layer that you need to research. If they get through the second layer and hit your second honeypot, you know that someone is specifically targeting you (instead of simply running automated scans) and you need to pay closer attention. Etc…
Reinforcing the attack layer comes in two main forms, which work in tandem: Strengthening the actual layer, and reducing attack vectors. The first is focused on using strong passwords, keeping systems up to date, running something like Fail2Ban for services that are exposed, etc… The goal is for each layer of security to be robust, to reduce the chances of a bot attack actually working. Bots will simply sniff around and automatically throw shit at the wall to see if anything sticks.
The second part is focused on identifying and mitigating attack vectors. Essentially reducing the amount of holes in the wall. It doesn’t matter how strong the wall is if it’s full of holes for your server’s various services. The goal is typically to have each layer be as solid as possible, and grant access to the layers below it. So for instance, running a VPN. The VPN gets you access to the network, without exposing services externally. In order to access your services, they need to get through the VPN first, making the VPN the primary attack vector. So you can focus on ensuring that the VPN is secure, instead of trying to spread your focus amongst a dozen different services. If it’s exposed to the open internet, it is a new potential attack vector; The strength of the wall doesn’t actually matter, if one of those services has an exploit that someone can use to get inside your network.
Home users really only need to worry about things like compromised services, but corporate security specialists also focus on things like someone talking their way past the receptionist and into the server room, USB sticks getting “lost” around the building and plugged into random machines by curious employees, etc… All of these are attack vectors, even if they’re not digital. If you have three or four layers of security in a corporate setting and your third or fourth honeypot gets hit, you potentially have some corporate spy wrist-deep in your server room.
For an easy example, imagine having a default password on a service, and then exposing it to the internet via port forwarding. It doesn’t matter how strong your firewall is anymore. The bot will simply sniff the service’s port, try the default credentials, and now it has control of that service.
The better way to do it would be to reduce your attack vectors at each layer; Require the VPN to access the network via a secure connection, then have a strong password on the service so it can’t easily be compromised.
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
Nah, setting non-standard ports is sound advice in security circles.
People misunderstand the “no security through obscurity” phrase. If you build security as a chain, where the chain is only as good as the weakest link, then it’s bad. But if you build security in layers, like a castle, then it can only help. It’s OK for a layer to be weak when there are other layers behind it.
Even better, non-standard ports will make 99% of threats go away. They automate scans that are just looking for anything they can break. If they don’t see the open ports, they move on. Won’t stop a determined attacker, of course, but that’s what other layers are for.
As long as there’s real security otherwise (TLS, good passwords, etc), it’s fine.
If anyone says “that’s a false sense of security”, ignore them. They’ve replaced thinking with a cliche.
People misunderstand the “no security through obscurity” phrase. If you build security as a chain, where the chain is only as good as the weakest link, then it’s bad. But if you build security in layers, like a castle, then it can only help. It’s OK for a layer to be weak when there are other layers behind it.
And this is what should be sung from the hills and mountaintops. There’s some old infosec advice that you should have two or three honeypots, buried successively deeper behind your security, and only start to worry when the second or third gets hit; The first one getting hit simply means they’re sniffing around with automated port scanners and bots. They’re just throwing common vulnerabilities at the wall to see if any of them stick. The first one is usually enough for them to go “ah shit I guess I hit a honeypot. They must be looking for me now. Never mind.” The second is when you know they’re actually targeting you specifically. And the third is when you need to start considering pulling plugs.
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.
The issue is not encryption, it’s the unauthenticated API. People can interact with your server without an account.
Specifically these issues: https://github.com/jellyfin/jellyfin/issues/5415
The big one is that video/audio playing endpoints can be used without authentication. However, you have to guess a UUID. If Jellyfin is using UUIDv4 (fully random), then this shouldn’t be an issue; the search space is too big. However, many of the other types of UUIDs could hypothetically be enumerated through brute force. I’m not sure what Jellyfin uses for UUIDs.
Jellyfin has a whole host of unresolved and unmitigated security vulnerabilities that make exposing it to the internet. A pretty poor choice.
And which one of those are actually vulnerabilities that are exploitable? First, yes ofc unauthenticated endpoints should be fixed, but with those there is no real damage to be done.
If you know the media path then you can request a playback, and if you get the user ids then you can get all users. That’s more or less it.
Good? No. But far from making it a poor choice exposing it.
These are all holes in the Swiss cheese model.
Just because you and I cannot immediately consider ways of exploiting these vulnerabilities doesn’t mean they don’t exist or are not already in use (Including other endpoints of vulnerabilities not listed)
This is one of the biggest mindset gaps that exist in technology, which tends to result in a whole internet filled with exploitable services and devices. Which are more often than not used as proxies for crime or traffic, and not directly exploited.
Meaning that unless you have incredibly robust network traffic analysis, you won’t notice a thing.
There are so many sonarr and similar instances out there with minor vulnerabilities being exploited in the wild because of the same"Well, what can someone do with these vulnerabilities anyways" mindset. Turns out all it takes is a common deployment misconfiguration in several seedbox providers to turn it into an RCE, which wouldn’t have been possible if the vulnerability was patched.
Which is just holes in the swiss cheese model lining up. Something as simple as allowing an admin user access to their own password when they are logged in enables an entirely separate class of attacks. Excused because “If they’re already logged in, they know the password”. Well, not of there’s another vulnerability with authentication…
See how that works?
Imo that’s perfectly fine and not idiotic if you have a static IP, no ISP blocked ports / don’t care about using alt ports, and don’t mind people who find your domain knowing your IP.
I did basically that when I had a fiber line but then I added a local haproxy in front to handle additional subdomains. I feel like people gravitate towards recommending that because it works regardless of the answers to the other questions, even their security tolerance if recommending access only over VPN.
I have CGNAT now so reverse proxy in the cloud is my only option, but at least I’m free to reconfigure my LAN or uproot everything and plant it on any other LAN and it’ll all be fine.
Reverse proxies can be useful for hiding your IP if you do something like host it in a VPS and tunnel the traffic back to your self hosted service. There’s also a lot of documentation on attaching things like fail2ban or crowd sec which can be helpful in reducing the threat from attacks. if you’re running lots of services it can reduce the risk of two apps using the same ports as ultimately everything will go through ports 80 and 443 on the public facing side. Finally again if you’re hosting several services having a central place to manage and deal with cert from can save a lot of time rather than having to wrangle it per service/ server.
deleted by creator
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.
If you’re a beginner and you’re looking for the most secure way with least amount of effort, just VPN into your home network using something like WireGuard, or use an off the shelf mesh vpn like Tailscale to connect directly to your JF server. You can give access to your VPN to other people to use. Tailscale would be the easiest to do this with, but if you want to go full self-hosted you can do it with WireGuard if you’re willing to put in a little extra leg work.
What I’ve done in the past is run a reverse proxy on a cloud VPS and tunnel that to the JF server. The cloud VPS acts as a reverse proxy and a web application firewall which blocks common exploits, failed connection attempts etc. you can take it one step beyond that if you want people to authenticate BEFORE they reach your server by using an oauth provider and whatever forward Auth your reverse proxy software supports.
I rent a cheap $5/mo VPS and use it to run a wireguard server with wgeasy and nginx proxy manager. Everything else runs on my home server connected by wireguard.
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 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.
This is 99% my setup, just with a traefik container attached to my wifeguard container.
Can recommend especially because I can move apartments any time, not care about CGNAT (my current situation which I predicted would be the case), and easily switch to any backup by sticking my boxes on any network with DHCP that can reach the Internet (like a 4G hotspot or a nanobeam pointed at a public wifi down the road) in a pinch without reconfiguring anything.
I access it through a reverse proxy (nginx). I guess the only weak point is if someone finds out the domain for it and starts spamming the login screen. But I’ve restricted access to the domain for most of the world anyway. Wireguard would probably be more secure but its not always possible if like on vacation and want to use it on the TV there…
This is the biggest weakness of Jellyfin. Native OIDC support would really be a no brainer at this point.
It is possible if you get something like an nvidia shield tho. But of course not everyone has it or the money for it
I use a cloudflare tunnel, ISP won’t give me a static IP and I wanna keep my firewall locked down tight.
I tried really hard to get a named CloudFlare tunnel working with a domain name I registered (I share my personal home videos with a non technical family member in Italy) but couldn’t get it working no matter what I tried.
I’m not sure whay the OS you use is, but on linux (debian based) they have a Curl installer that installs their Systemd service preconfigured for your account and the specific tunnel you’re using.
Once that is installed, configuration is pretty easy. Inside their ZeroTrust portal, you will find the options to configure ports.
Always point your tunnel to https://localhost:port or http://localhost:port. You can get a TLS cert from lets-encrypt for your first one. New certifications are issued by cloudflare’s partners regularly to prevent expiration. I think I have like 3 for my domain now? 1 from Lets-Encrypt and a couple from Google.
This could be totally unrelated, but when I first configured my domain, I used DuckDNS as my DNS registrar so I could do everything over wireguard. That’s is still set up and in Cloudflare I still have duckdns included in my DNS registry. Could he worth a shot to set that up and add it to your DNS registry on cloudflare.
“Technically” my jellyfin is exposed to the internet however, I have Fail2Ban setup blocking every public IP and only whitelisting IP’s that I’ve verified.
I use GeoBlock for the services I want exposed to the internet however, I should also setup Authelia or something along those lines for further verification.
Reverse proxy is Traefik.
I just install tailscale at family houses. The limit is 100 machines.
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.
For now just Tailscale but I’m working on setting up a reverse proxy and SSO through Authentik
Even more secure is having a VPS and self hosting Heascale, even better is Wireguard
I’m trying to move away from needing a VPN to connect to make it simpler for less technically inclined family members
Usually just needs to be set up once. A small price to pay for security.
