Cloudflare has made it too easy to access your homelab on the internet
1–10 of 26 posts
Re: Cloudflare has made it too easy to access your homelab on the internet
#2Call me crazy, but I don't think "tunnel all your traffic through a third party corporation's service" is the correct solution to "my IP changes sometimes." Maybe just set up DDNS instead?
If you really are trying to run a server behind a CGNAT, then I guess you have no other options, but I'd consider this kind of thing to be a last resort.
Re: Cloudflare has made it too easy to access your homelab on the internet
#3Call me crazy, but I don't think "tunnel all your traffic through a third party corporation's service" is the correct solution to "my IP changes sometimes." Maybe just set up DDNS instead? If you really are trying to run a server behind a CGNAT, then I guess you have no other options, but I'd consider this kind of thing to be a last resort.
Not quite, some ISPs lock down their routers and you can't expose the relevant ports publically. That's when Cloudflare Tunnels combined with a reverse proxy save the day.
Another really useful service is being able to protect everything behind a SSO like Github, allowing at least the most basic form of intrusion prevention that would secure your homelab from the majority of attacks.
Re: Cloudflare has made it too easy to access your homelab on the internet
#4I've opted to do this myself by buying a VPS for ~$5/month with Digital Ocean. It runs a Wireguard server and nginx, and then my home lab router connects via Wireguard. Nginx acts as a reverse proxy to serve content from my home lab. I have (relatively speaking) complete control over the entire path.
When running Cloudflare tunnels, opening a port on your router, or having a VPS+Wireguard, it's important to think about security and covering your butt. I run everything in a DMZ subnet that has firewall/ACL rules on both the DMZ and my other networks to restrict any access. I put bandwidth caps on individual VMs/containers. I also use Wireguard to reroute all outbound Internet requests from the DMZ so that my home lab doesn't use my home IP address at all.
Maybe I'm paranoid, but the last thing I need is to forget about some web project I was experimenting with in my lab and suddenly the Internet connection I pay for is being used by some bad actor to participate in ddos or to resell access to my trusted residential IP for scamming purposes.
Re: Cloudflare has made it too easy to access your homelab on the internet
#5I'm pretty happy with Tailscale for private access.
Re: Cloudflare has made it too easy to access your homelab on the internet
#6I've opted to do this myself by buying a VPS for ~$5/month with Digital Ocean. It runs a Wireguard server and nginx, and then my home lab router connects via Wireguard. Nginx acts as a reverse proxy to serve content from my home lab. I have (relatively speaking) complete control over the entire path. When running Cloudflare tunnels, opening a port on your router, or having a VPS+Wireguard, it's important to think abo…
Curious how you have all this set up. This architecture makes a lot of sense but it seems a bit fiddly to set up. Do you manage routes, IPs, and ports manually or is there some magic docker thingy that facilitates this architecture?
Personally I currently just use DDNS for stuff hosted on consumer connections (AKA home lab). And docker nginx-proxy to multiplex various self-hosted web apps (either in a home lab or on a VPS).
Re: Cloudflare has made it too easy to access your homelab on the internet
#7I've opted to do this myself by buying a VPS for ~$5/month with Digital Ocean. It runs a Wireguard server and nginx, and then my home lab router connects via Wireguard. Nginx acts as a reverse proxy to serve content from my home lab. I have (relatively speaking) complete control over the entire path. When running Cloudflare tunnels, opening a port on your router, or having a VPS+Wireguard, it's important to think abo…
I have a VPS running BGP, along with my own ASN and a /24 block. My home network is tunneling out to the VPS from a VM and routing the /24 over wireguard. The /24 is then made available on its own VLAN.
No doubt all this stuff is a violation of residential TOS agreements.
Re: Cloudflare has made it too easy to access your homelab on the internet
#8This is also pretty easy with nothing but SSH, setting up a tunnel through any server to which you have SSH access (including extremely cheap/free ones.)
Re: Cloudflare has made it too easy to access your homelab on the internet
#9Unfortunately, you can't use this to tunnel multiple subdomains, unless you tunnel an entire domain. That's because Cloudflare won't let you issue third-level wildcard certificates, so you can't proxy *.lab.mydomain.com. Maybe I should just get my homelab a domain and be done with it, but right now running everything over Tailscale seems like a better solution.
Re: Cloudflare has made it too easy to access your homelab on the internet
#10I've opted to do this myself by buying a VPS for ~$5/month with Digital Ocean. It runs a Wireguard server and nginx, and then my home lab router connects via Wireguard. Nginx acts as a reverse proxy to serve content from my home lab. I have (relatively speaking) complete control over the entire path. When running Cloudflare tunnels, opening a port on your router, or having a VPS+Wireguard, it's important to think abo…
Curious how you have all this set up. This architecture makes a lot of sense but it seems a bit fiddly to set up. Do you manage routes, IPs, and ports manually or is there some magic docker thingy that facilitates this architecture? Personally I currently just use DDNS for stuff hosted on consumer connections (AKA home lab). And docker nginx-proxy to multiplex various self-hosted web apps (either in a home lab or on…
[Guix/Ansible/Chef/Nix/Puppet] + systemd-networkd + firewalld/nftables. It's not much different than setting up any old load-balancer or reverse proxy on an internal network.
Why not Docker? Since routes are kernel-level and shared between containers, using Docker here typically complicates things rather than making them simpler. Unless you already know about most of the "network magic" Docker does by default, in best case you'll waste a lot of time figuring all of that out and in worst-case you'll apparently have it working but actually vulnerable in some subtle way. And at the point where you're running with "--net=host --user=root --privileged", you're not gaining much from containers for these specific use-cases.
Yes, you _can_ do stuff like this with just containers with CNI/custom networking but VMs are typically cleaner and easier unless you're strongly personally motivated to learn about the underpinnings of container networking.
> And docker nginx-proxy to multiplex various self-hosted web apps (either in a home lab or on a VPS).
That's probably fine, and you might be able to do something similar without even touching that part (aside from closing off the public entrypoint when/if you get the tunneling working). You'd set up the WG+routing either on the same box or on a dedicated tunnel/proxy endpoint, as well as on the remote side. You can either add an additional L7 LB (like nginx) at the entrypoint or redirect traffic straight to your existing nginx. The former is probably the safer and easier, but less efficient approach.