So everyone is talking about cloudflare tunnels and I decided to give it a shot.
However, I find the learning curve quite hard and would really appreciate a short introduction into how they work and how do I set them up…
In my current infrastructure I am running a reverse proxy with SSL and Authentik, but nothing is exposed outside. I access my network via a VPN but would like to try out and consider CF. Might be easier for the family.
How does authentication work? Is it really a secure way to expose internal services?
Thanks!
I know some people dislike NetworkChuck but this video should help you get things going.
Here is an alternative Piped link(s): https://piped.video/ey4u7OUAF3c
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
In effect, Cloudflare would give protection against DDoS attacks before requests would even hit your servers. That much said you can implement mitigations on the reverse proxy itself. One example would be fail2ban.
I’m sure there are additional steps that you can take. I’m not a fan of Cloudflare because their free offering has some caveats and violating these could be problematic. I have a cloud VPS with a WireGuard tunnel back to my server. I don’t have to do anything ugly like port forwarding. The cloud VPS runs NGINX as a reverse proxy. It’s a relatively simple and effective setup.
Thanks! How do you handle that with internal DNS? I suppose you’d need to setup the exact same proxies on the internal and external server, and local DNS handles which one my domain it’s being resolved to?
Right now the internal DNS I use has a TLD of .lan but that’s pretty much for my personal convenience. I access my websites by their FQDN internally with no issue. So I am not sure what your tring to achieve. Mind elaborating?
Of course! So in order to get maximum speed on your services, you wanna use a direct internal route when you’re inside your net. My understanding is, that when using an external cloud VPS with a proxy, local clients go through unnecessary routing…
Local request --out--> external VPS (proxy) --request data from internal--> receive data on external proxy --send back--> local client
So what I am saying, all requests are unnecessarily routed through the external VPS. So one would have to create an exact duplicate reverse proxy internally to avoid leaving the net. When accessing domain.com, the internal DNS returns the local proxy IP, when outside you receive the cloud VPS IP.
Or am I missing something?
Thank you for taking the time!
Cloudflared tunnels are great. No firewall ports to open.
I installed the Cloudflared docker, which is headless, and fed it my API key. Then Cloudflared creates a VPN between your system and theirs. Then, think of Cloudflare as the reverse proxy, you just configure it on the CF site instead of locally. No need for a reverse proxy on your side.
I’ve not done anything with auth on it as what I run I don’t mind being public. If you still want to run a local auth, you can set it to hit your local reverse proxy instead and do it that way.
The benefits are you don’t need to open firewall ports and your local IP is irrelevant so no need for dynamic DNS.
Just a side note that “not opening firewall ports” is not inherently a security benefit if you’re exposing the same service on the same port on the same host anyway via your reverse proxy setup.
If you were to measure your level of “security” on having ports open or not alone, then using Cloudflare tunnels could be considered worse, since an outbound VPN connection to Cloudflare is essentially circumventing your firewall’s protection entirely, meaning you’re effectively opening all 65,535 TCP and UDP ports instead of one, albeit only to Cloudflare.
There are benefits to using Cloudflare tunnels but “not opening firewall ports” is not one of them. And you could just as easily accomplish the same thing without Cloudflare by using a VPS and Tailscale with the selfhosted Headscale coordinator.
Meh, it’s sorta 6 of one and half-dozen of another. The benefit of not opening ports on a firewall isn’t necessarily a security one so much of a convenience one for people who don’t know how their routers work or no access to open those ports. The only security value is it prevents any exploits on your router and a port scan against your network won’t show those ports open. That makes it easier to hide the fact that your hosting something. I’d agree, it’s not a huge security vector to worry about, but can help people not see your real IP which has tangible value.
Really, your offloading security to CF and putting trust in them to do a better job than you, but as you said, in doing so they can sort of get the keys to your kingdom. I think it’s just worth it with their other tools to block bots and other common exploits that a Netgear home router isn’t looking for.
The problem with a vps and tailscale is its one more thing to manage and a vps costs money and cf is free.
I would also like to know this. Everyone talks about it but I have no idea how it’s different than anything I’m doing now. Is it like Tailscale?
One of the mysteries I am facing ^^ selfhost headscale? Tailscale? VPN? CF?
Too many options :D
Personally, I just wireguard in to my local net. No need to have CF snooping where they don’t need to.
It all depends on your use cases and what you (or your users) need to access.
Selfhost headscale, run a reverse proxy with let’s encrypt on a VPS and Tailscale that VPS to your local server, utilizing Tailscale’s ACLs to block all ports except for your desired ones. It’s exactly what CF tunnels is doing but you have far more control over your data and security.
Essentially it IS a tunnel, just with cloudflare’s infrastructure in the middle handling auth and obscuring each end from the other.
Auth is handled by cloudflare. That doesn’t mean cloudflare necessarily is the auth provider, though. Not likely in selfhosted, but one could set up some other auth provider, like azure, and cloudflare could give tunnel access to authorized users who actually provided credentials via azure.
The service, port, whatever being accessed via the tunnel may also require auth, and cloudflare generally doesn’t handle that. For example, your cloudflare tunnel to your local sonarr instance requires auth at cloudflare first, to access the tunnel, then again at sonarr because your sonarr instance requires authentication.
In a docker environment, you would either tunnel to the docker host or to individual Dockers. The latter is more sensible and generally a bit more secure, if only because least access = better. There’s probably some cloudflare tunnels docker out there that does half the setup for you, then you just stick it and the Dockers you want exposed through the tunnel all on the same docker network interface (which you create), but that’s just speculation.
As far as setting tunnels up goes, the docs are really good at the step by step. Easiest way to learn it is to set up a VM similar to what you want and bang away at the steps until it does what you want. Some things are easy, like RDP. Other things are trickier.
The basics of setup are that you use the cloudflared application at both ends: one server-side to expose what you want and one client-side to access the tunnel via cloudflare.
Tailscale is the same kinda thing. I think it is way easier for a lot of people. There’s a lot less setup involved. Just install the apps and make a few choices.
For personal use, I use wireguard to access my home server. Professionally I use cloudflare tunnels for a couple of things, but mostly an enterprise vpn.
Thank you for the detailed explanation. I am running Tailscale as a temporary solution to access some services, but I dislike that you have to set firewall rules basically twice (once in your local network and once in Tailscale). I suppose it would be similar for CF?
