Currently I’m using tailscale. I like it but often switching IP address if I’m at home and I can’t use my normal vpn on it. Plus, I’m excited to learn about DNS and cloud flare. Its just very overwhelming haha

I forgot to mention that one because I kinda thought it belongs with radmin and hamachi, but it’s my choice as well currently.

I am using it with my own Headscale though, so add a domain to that as well.

And I finally need to switch my vaultwarden to work over tailscale & LAN finally, it’s a huge security risk to expose that one.

Headscale is great but requires port forwarding which, aside from having its own iasues, is something op wants to avoid.

Yes, it works great for me. Probably not for a TV though, for that you’d probably need some travel router VPN client. But I don’t know how often you’d be at a random TV and need to get to jellyfin.

Yeh, exactly.
And the “dynamic DNS” part handles your public IP address changing with 0 pain.
You either buy a domain (like example.com), or there are free domain name providers that give you a subdomain (like mycooldomain.example.com) of one of their domains.
You then run an additional service on your home server that checks what the current public IP address is. If it changes, it notifies the DNS responsible for your domain/subdomain, which then points to your new public IP.
To connect to your VPN, you only ever care about “mycooldomain.example.com” and never the underlying IP address.

…
As long as your ISP isn’t running CG-NAT of course 😵‍💫

I’m sold! Setting it up now!

Just be aware that if you want anyone else to connect to your Jellyfin, you’ll still have to route it through a domain and reverse proxy, unless you’re comfortable letting them log in to your tailnet.

It’s a bit of a fiddle to set up, but once it’s done it’s quite satisfying.

it’s actually the recommended way if you use jellyfin, theres a few security/privacy vulnerabilities with publicly exposing the jellyfin server anyway, they are being worked on but, the safest way to do it is just use a vpn regardless.

I added a reference to your comment

yeah I forgot that one. I had to rush the comment a bit.

Some .xyz domains cost less than 1$. Mine is 0,85$/year

On Cloudflare, you’ll want to set a DNS record to point any relevant subdomains to your current WAN IP address. IPv4 will be an A Name record. IPv6 would be an AAAA Name record, but I’m not going to deal with IPv6 for this… Here is an example of mine, with info blocked out:

So for instance, maybe you have a peepee.example.com subdomain, a poopoo.example.com subdomain, etc which all point to your WAN IP address. That will basically tell Cloudflare’s DNS to forward any traffic for those subdomains to your WAN IP. Each subdomain can also choose whether or not to proxy the content, or just directly send it to your WAN with DNS. Basically, when Cloudflare propagates the DNS records to the various DNS servers, you can choose whether that record has your WAN IP (DNS Only) or one of Cloudflare’s (Proxied). Proxy support means you can take advantage of some additional CF protections, but it also means passing all of the data through CF’s server. In most cases, you’ll want DNS Only. Proxy support will depend on the individual service. Some will work fine with it, some won’t. And it’s also possible that you don’t want services proxied through CF for privacy reasons.

Next, you’ll want to set up a reverse proxy service. This will be something like Nginx Proxy Manager, Caddy, etc that you run on a device on your LAN. It can even be on the same machine running your various services. The big reverse proxies all offer Docker images, so you can incorporate it directly into an existing Docker stack if you already have one. Personally I use NPM, but Caddy is also very popular.

You’ll tell this reverse proxy “when you receive valid traffic addressed to {subdomain}, forward it to {relevant service on your LAN}.” You can also set some additional options for each subdomain, like automatically upgrading to https. For instance, maybe peepee.example.com forwards to 192.168.1.100:42069 on your LAN, and is configured to automatically upgrade any http traffic to https, and to require https.

You can also set up automatic TLS certificate renewal, so https traffic can be properly encrypted. The reverse proxy will need an API key, and it will allow the service to automatically check expiration dates and pull a fresh TLS cert for your domain if the date is coming up soon.

You’ll probably want to use a wildcard certificate, (basically *.example.com) because the TLS certificates are open to the public. So if you do individual certs for all of your various services, bots will scrape the public records and you’ll inevitably get a lot of bot traffic probing your various subdomains. A wildcard domain usually means the bots hit the standard example.com and www.example.com first, which makes them super easy to detect and block. I even have rules set up to automatically block anything that tries to access my www subdomain, because I specifically don’t host a landing page and don’t have anything available there. So I know that any traffic hitting that www subdomain is a bot trying to access common subdomains.

Next, you’ll want to forward ports 80 and 443 to your reverse proxy. Port 80 is the standard port for http traffic, and 443 is the standard port for https traffic. These will be the ports that your reverse proxy actually receives the traffic on, before forwarding it to the various services. Note that lots of lazy devs default to using 80 and 443 for lots of things, so you may want to configure your router to use a different port (like 81 or 444) for its config page if you’re able. Otherwise, you may end up accidentally locking yourself out of your router’s config page, because it will attempt to use 80 to reach the page, then get automatically forwarded to the reverse proxy instead.

Finally, for some ease-of-maintenance, you may want to consider adding a DDNS service (like Cloudflare-DDNS) to your docker stack. This will occasionally check your current WAN IP, and update it with Cloudflare if necessary. For example, if you have an outage and your router gets a new WAN IP when it boots back up again. Normally you would need to manually go to Cloudflare and update the IP info to point at your new address. But DDNS does that automatically.

The way traffic flows when it is all set up is along these lines:

1. A device wants to access your service at peepee.example.com. It doesn’t know where to find that site, so it asks a DNS server.
2. Cloudflare has told all of the various DNS servers “hey, peepee.example.com can be found at {your IPv4 WAN address}”.
3. The device follows that DNS record, and attempts to connect to your IPv4 WAN address, on port 80 or 443. For this example, let’s say it tries to connect on port 80 for standard http traffic. The device knocks on port 80’s door and says “hey, I’m here to access http://peepee.example.com/.”
4. Your reverse proxy checks the configured list, finds the valid peepee.example.com subdomain, finds it has a valid TLS cert, finds it is configured to automatically upgrade to https, and responds “Yes, please upgrade to https. Http traffic is not allowed.”
5. The external device knocks again, this time on port 443’s door. It goes “hey, I’m here to access https://peepee.example.com/. Your reverse proxy goes “thank you, here is the TLS cert and my half of the TLS security handshake.”
6. Your external device uses the data in the TLS cert to validate and complete the TLS handshake with the reverse proxy, and the traffic between the reverse proxy and your external device is now encrypted with https. Your device gets the nice little “secured” padlock icon in your browser. Because the traffic is encrypted, a malicious actor may be able to tell what kind of info you are passing (for example, a video stream will likely have a pretty obvious pattern) but they won’t be able to see what specific data you are passing. They may be able to tell that you’re streaming a video, but they won’t know which video specifically.
7. The reverse proxy forwards the traffic to the service, configured at 192.168.1.100:42069.
8. Your service does not ever know the device is being accessed via WAN, because (as far as the service can tell) the traffic is coming from your reverse proxy (also a LAN device). So any “pay to use WAN” services will continue to work for free.
9. The external device never gets access to info like the specific LAN IP or port number, because it only has access to the reverse proxy. All of the traffic is passing back and forth between the reverse proxy.

But notably, keep in mind that the reverse proxy didn’t do any actual user authentication. If your service has a weak password, a reverse proxy will act as a gateway for any potential hackers to gain access to the service. The same way an open port is a gateway directly to the service, the reverse proxy is now a gateway that simply requires an attacker to use a subdomain instead of an IP and port number. And if you make your subdomain something like jellyfin.example.com it will probably be dead simple for a bot to guess. And any vulnerabilities in the service will still be exploitable via the reverse proxy, because the reverse proxy is simply making sure the request is valid, and then passing the traffic back and forth. It isn’t actually inspecting the content of that traffic, so it’s not going to stop things like attackers. When you hear digital security folks talk about things like attack vectors, this is what they’re referring to. Your reverse proxy is a potential vector of attack for your configured services. Use strong passwords, keep your services updated, etc…

You can technically add authentication to a reverse proxy. So for instance, maybe a service doesn’t have any built-in way to add a password. You can have the reverse proxy act as an authentication gate, so it will prompt the user for a username+password before they can even reach the service. This will make the services more secure (yes, even the ones that already have passwords, as long as you use a different password for your reverse proxy authentication) but it will break most apps that are designed to work with a service. For instance, Jellyfin has several apps that work, but those apps won’t have any way to get past the reverse proxy’s password gate. So those apps will simply break if you add a second layer of authentication with your reverse proxy.

There are also some security options you’ll likely want to enable on Cloudflare’s side, but this comment is already long enough.

Free vps in oracle cloud with Pangolin

If I’m not mistaken I tried setting up pangolin to work along side my already running Traefik setup and it was just an absolute nightmare.

I just don’t have the time nor energy to reinvent my already running configuration.

and used a cloudflared tunnel to direct traffic to Caddy

There is also a way to use the cloudflared tunnel for free that gives you a domain as well (sort of anyways).

This is DDNS, a popular, free alternative would be ddclient. Essentially updating an A Record so that your dynamic IP is remains associated with your domain.

While cloudflare is also my registrar as well, I don’t use any of the “features” they offer, and opted to use Keycloak for my authentication needs.

A cheap way to start is noip.com. You can get a domain name for free, you just need to check in every 3 months to say you are still using it. It’s big enough that many routers support it.

After 2 years of checking in every 3 months I paid for their next tier of service where you don’t have to check in and get multiple domains etc. So their free service marketing worked.

I’d recommend buying a domain through Cloudflare. Once you have one, you can create subdomains and point them to services running on your home server. Cloudflare’s dashboard makes the DNS side pretty straightforward.

I mean I cheated and used chatgpt to help figure it out. But it’s more or less 3 programs max running on whatever server you’re using and using the cloudflare UI to redirect the traffic to the right place

I’ve been with NameCheap for over a decade. They’re a relatively quiet company that’s been around a while.

They’ve never done anything to make me want to change providers. Have my email through them as well. Good uptime. Ok-ish prices. Good customer service the one time I’ve needed it. Web site takes some getting used to, but it’s also never changed since I started using them.

Fair points.

I’ve been lucky enough to have never been behind cgnat, so I keep forgetting about it.

My bigger concern with tailscale is being required to install software on the client. Not every device I use, I have permission to install a vpn client, nor would I want to.

For example, I have a fileshare using Filebrowser where I store work related files that I don’t want to loose access to or need access to from multiple machines (non proprietary info, stuff IT/MGT wouldnt get mad at me for ofc. I’ve actually cleared it with my managers, so no worries). That’s also a handy way to (temporarily) share large files with people or provide a way for friends to upload large files to me.

I also like to access my emby server (using sufficiently limited accounts), from things like the TV in the work break room, or a friends PC while I’m visiting.

Tailscale is a hurdle that I just don’t need/want.

Glad I could help. I’m not always immediately available, but I don’t mind answering questions if you run into troubles. Just send me a DM and I’ll do what I can. :)