Main downsides to Cloudflare Tunnel are no e2ee (Cloudflare decrypts all your traffic) and technically anything other than basic HTML websites (ie media streaming) is against their free ToS, though I haven't heard of that being enforced in practice.
If you're the only one ever using your services then I'd recommend Tailscale instead, which sets up a VPN using WireGuard along with slick auto p2p setup (NAT traversal, relays, etc).
I love that list! I also use Tailscale for a lot of my personal private services as well as Cloudflare Tunnel, I think they're both really great :)
The concern about Cloudflare decrypting the traffic is valid, I just personally feel for a lot of public websites that's often fine especially if the hoster might have been using Cloudflare already anyway. If an individual doesn't want to use Cloudflare for their setup then that's fine and there are lots of cool pieces of tech they can consider!
It happened here[0], and the reasoning for why they allow some free tier content is in their S-1[1]. Typically, even if you blatant file sharing or video streaming application in violation of 2.8, Cloudflare doesn't necessarily care as long as it's not too bandwidth intensive (eg. I wouldn't recommend having a dozen people streaming Plex from the outside internet).
0: https://community.cloudflare.com/t/the-way-you-handle-bandwi...
You should also check out Innernet if you're interested in this space. Wiretrustee is similar to TS in that it mixes OS/Closed source.
No affiliation but what I'm having to use at work.
[1] https://docs.microsoft.com/en-us/azure/active-directory/app-...
[2] https://www.zscaler.com/blogs/company-news/securing-third-pa...
An “easy” solution would be something that gets your local content online in one click or less.
It also has basic e2ee. The TLS certs never leave the client devices by default.
Even so I agree with you that this is still too much. I think a non-technical person should be able to write some content, go through a quick OAuth2 flow to point a domain name at that content, and have it just work. I'm currently working on building something more like that.
Well, a port is exposed, it's just exposed on Cloudflare's reverse proxies. And I think this is probably a dramatic overstatement of the security that Cloudflare provides...
Most stacks would crumble under a relatively small L7 ddos that Cloudflare would not likely mitigate.
An easy secure setup would be to spin up a guest VM and isolate it in its own subnet.
Disable routing between your guest and the rest of your lan and you can sleep easy at night so long as your app doesn’t serve any crazy dynamic content.
You really can just host your webserver from home network and forward the port using your consumer grade router and consumer home connection most of the time and nothing bad happens. But this kind of tunneling would be great for when you have a bad ISP that blocks port 80 instead of just saying servers aren't allowed.
* Broken auth? Doesn't matter, encrypted.
* IDOR? Encryption takes care of it!
* Blind SQL or something from the 90s? EEENNNNCCCRRYYPPPTTIIOOONN!
Be weary of such absolute statements -- especially when it comes to security.
Caddy in particular is extremely easy to configure, with the bonus that HTTPS/Lets Encrypt has never been free'er. Wireguard configuration is also gloriously minimal but admittedly, potentially tricky to get right the first time.
It's just good to consider alternatives to Cloudfare's network dominance, if you can afford it.
I chose this over Wireguard because it integrates with our SSO system and users don't have to configure a firewall client. In fact, most users don't know we even did anything special to secure the service.
Secondly, I can set up wireguard, but then I would be responsible for maintenance, keeping the instance up and patched etc. You may save money by using Wireguard, but you pay for it in time, which is the only thing you cannot buy.
* Start with a "gateway" managing your WireGuard "PKI". Basically a group of Wireguard servers with an API that have synced configs.
/proxies - Your frontend servers.
/endpoints - Your backend servers.
/gateways - WireGuard servers that your frontend and backend can reach.
* Proxies handle user-auth like any web service and then act as a reverse proxy to the endpoints using the Wireguard internal address.
Nothing at all fancy except that in a normal deployment your frontend and backend would be live in the same datacenter and so you don't need any WireGuard BS.
This provides a model where our devs can hit a public endpoint that reverse proxies to their laptops.
Problem is, 3.5$/month has only 500MB RAM which is very little to run Apache + other services.
Superior UI/UX offered by centralized systems is why everything is being centralized.
People will trade everything including privacy and security for ease of use. The market has shown this time and time again.
Your users don't really care about decentralized utopia when your service doesn't work.
Cloudflare Tunnel has gotten good enough there aren't a lot of ways to be better left. A couple would be offering e2ee and a less stringent ToS (technically anything other than normal HTML websites is not permitted, though I'm not aware of this ever being enforced, yet).
[1]: https://inlets.dev/
I don't think they were malicious, I suspect growing pains, but it very much didn't match their stellar reputation.
After that experience we made sure not to rely on them for anything that we couldn't instantly turn off or switch away from. I'd run a blog behind cloudflare without worries but not sure anymore about nontrivial high-traffic applications.
I use it to share in-progress work with co-workers, test webhooks, etc.
Edit: fixed command thanks to comment below :)
FWIW the brew install command is `brew install cloudflare/cloudflare/cloudflared` (via https://developers.cloudflare.com/cloudflare-one/connections...)
The reason why is because Alan is awesome.
I don't want to see Cloudflare completely take over this space, but Cloudflare Tunnel is tough to compete with.
One knob ngrok could still turn is adding auto TLS certs which are managed on the client side. Then you can offer e2ee which is something Cloudflare will probably never do.
They explain towards the end of this tutorial https://developers.cloudflare.com/cloudflare-one/tutorials/s...
This is really cool too!! I use Tunnels with SSH a ton. I was considering making a follow-up post going through the SSH setup too, but I felt it was a bit redundant considering that docs page existed. My post was because of the lack of a clear guide for a simple HTTP webserver.
I wrote up a guide [0] for using Nginx on a standard digital ocean droplet, but had I known about cloudflared at the time I think I would have tried that (tailscale was also something I thought about).
There was another recent article about cloudflared I remember seeing (maybe not on HN?), there's not very much good stuff like this about self-hosting. A lot people online just say "use X" without explaining anything helpful.
[0]: https://zalberico.com/essay/2020/06/06/urbit-on-the-cloud.ht...
Thank you for your kind words!
> I've always found information about how to do this kind of thing to be pretty confusing and not well described.
This is the main reason I made this post, there is a lot of documentation but most of it is quite dense and doesn't walk through a simple use-case. When I've recommended Tunnel to my friends I usually have to baby them through the process because of the lack of clear information. This post was made so I have something to point to when I recommend people to use Tunnel for their-usecase. I didn't expect it to blow up this much!
I would want it to happen on my local machine, so that (a) Cloudflare can't read my plaintext traffic, and (b) I can manage subdomain certificates more easily via Caddy.
Is that possible with the cheapo free tunnels or does Cloudflare want to handle the domain and TLS certificates, too?
Your comment and u/pedrogpimenta's give very different answers, I guess I'll need to verify for myself.
* You have to run it as a foreground service so the user knows it's running. Not a problem in theory but annoying to implement.
* DNS name resolution doesn't work by default (with Golang at least) because android doesn't use resolve.conf. I solved this by setting DNS servers manually to 1.1.1.1, 8.8.8.8, etc.
* You have to do weird hacks in order to run native applications such as Golang programs.
* Android has endless optimizations for battery life that are trying to shut down/throttle your program. One example I would see huge performance differences as soon as I turned the screen off.
Overall I consider Android to be a very hostile environment for native applications, and networked apps in particular. iOS is even worse from what I can tell. We need a mobile OS that respects the user's control over their device. I'm fine with sane defaults, but it should be easy to switch them off. I'm hopeful for the Pinephone, but we have a long way to go.
In principle, there is no reason at all to use TLS inside the tunnel — the tunnel itself is authenticated and encrypted. Unfortunately, cloudflare tunnels feel a bit like a cute 20% project that was never quite finished and is barely integrated with the rest of cloudflare’s offering.
Hey jgc et all, if you’re reading this, maybe the cloudflare console UI could have a pane for managing tunnels. And the pane for managing website origin servers could let you choose between the traditional cloudflare-initiated connection and a tunnel, and the tunnel mode could give some controls for how the origin server is protected, whether connections load balance across multiple tunnels, etc. And maybe even really open-source the tunnel client for real, because it would be quite nice to have the actual origin server connect via a plugin instead of a separate daemon.
In other words, the hard part of this offering is done. Do the boring bits so it can be even better than the primary offering.
I ended up switching to a business connection with my ISP, so I could get an extra fixed IPv4 address at my house and not need any of these tunnels. Obviously that is not an option everywhere.
Disclosure: I work at ngrok
It makes a ton of things like cluster failover much simpler than they otherwise would be.
We have a single API service which is exposed to the internet, and put the CloudFlare tunnel as a sidecar inside the same pods. This way, it’s actually CloudFlare which handles the load balancing, which is surprisingly effective.
I believe they _may_ be referring to the feature of being able to run a single "tunnel" on multiple hosts, using the same credentials and ID. When you do this, not only will Cloudflare automatically serve from the geographically nearest server if it can, but when one client goes offline (When the tunnel is disconnected, not application error sadly) it will automatically ignore that connection and serve from the others, providing some basic degree of failover with no extra payment or much configuration.
I believe you can also easily integrate Tunnels with the paid CF Load Balancer: https://developers.cloudflare.com/cloudflare-one/connections...
One of the great things about cloudflare tunnels is that even without load balancer we can send requests to multiple clusters if we want to.
Makes it really easy to replicate stateless services like ingress gateways.
It's a real system with various security and compliance concerns; Cloudflare and dev-focused services like Inlet or simple SSH forwarding are unfortunately not going to work.
Reducing the conversation to "Can that server ping google?" would make my life 1000% easier.
I then set my local dns(Adguard home) to redirect my url to it's lan url. Additionally, I run cloudflare tunnel to expose these services on the internet.
This allows me to use the url for internal services both at home or through the internet while having proper auth through cloudflare access when accessed over the internet. It was been working great for me so far
That's on page 10 of 12 on the print preview... It has another service running though, I find that adds a lot of complexity to the setup, but as usual, this has pros and cons.
Don't get me wrong, it's a good tutorial but I'm not sure I find port forwarding more complex - but I would argue that that strengths of this setup are different.
As noted by other commenters, Cloudflare Tunnel is completely free forever and does not cost anything. This was not always the case in the past where it was previously tied with the Argo Smart Routing product that cost money. The announcement of it becoming free is here: https://blog.cloudflare.com/tunnel-for-everyone/
I didn't mention price in the post because it was free, however from the comments I am thinking perhaps that is an important point to make. I wiill keep this in mind if I make similar posts in the future :)
It's a wireguard based kubernetes network overlay. I use it to access private services in my homelab cluster from my laptop, phone, etc.
https://gitlab.com/stavros/docker-cloudflared
I use this with Harbormaster (https://gitlab.com/stavros/harbormaster) so I can expose containerized stuff without ever forwarding any ports outside of Docker.
I maintain my own Docker image too for personal use (https://github.com/Erisa/cloudflared-docker) but I've never ran into a situation where needing everything as an environment variable was required or even desired. I really love the idea of that though, and I love that image!
[1]: https://developers.cloudflare.com/ssl/origin-configuration/a... "Set up authenticate origin pulls"
I really wanted to love CF Teams but is lacking some polish IMO.
> credentials-file: /home/ubuntu/.cloudflared/ed5bfe1 (...)
To either /root, or (more likely) /etc/cloudflared/ and making it readable to root, or a system user especially for cloudflared.
I like to think that my services will run regardless of the state of my /home filesystem.
If you use a VPN like OpenVPN or Tailscale (based on WireGuard), it will require admin in order to configure the network devices. The main advantage of WireGuard solutions is it runs in the kernel and can potentially be much faster, or at least more efficient. For tunneling often your upload throughput and not performance is the bottleneck.
[0]: https://blog.cloudflare.com/getting-cloudflare-tunnels-to-co...
It seemed like I had to run everything on the domain through Cloudflare when I looked into this in the past. That might be fine in the end, but I just wanted to try tunnels out first without committing to anything else.
Edit: thanks, everyone! This was just going to be a tiny web site for hobby purposes at first.
Tunnels also has a testing domain you can use. It should give you a subdomain like xxx-xxx-xxx.trycloudflare.com for basic "How do I get this thing working" testing.
If you're referring to the TOS issue that is often discussed here, it depends on what that subdomain is, since Cloudflare doesn't just want to be pushing binary data for free. If the subdomain is some website that is primarily used in the browser, CF will generally be fine leaving it up even if you push TBs a day, but if it's just a file host CF has been known to flag that for abuse and disable proxying for the domain[2]. As for why they bother with a free plan with such cryptic rules, their S1 explains it[3].
0: https://support.cloudflare.com/hc/en-us/articles/36002034883...
1: https://developers.cloudflare.com/cloudflare-one/connections...
2: https://community.cloudflare.com/t/the-way-you-handle-bandwi...
(I am not a CF employee nor your lawyer)
*edit: Learned here in this discussion that moving NS servers to Cloudflare is not even required. I’ll need to test that.
I know there's other ways to do this, but Tunnel made it extremely easy.
Note that if you are not using Cloudflare Access as additional authentication layer and only rely on Home Assistant authentication, the Cloudflare tunnel obviously works with the Android app. It's just that I was too paranoid for this.
Maybe I'm overly cautious. Home Assistant does have two-factor as options as well, doesn't it?
No, this is not possible. Cloudflare Tunnel focuses mainly on HTTP traffic but also supports SSH, VNC and generic TCP only in situations where the client also uses the cloudflared client to proxy it back to their localhost. Hosting a mail server with these restrictions is not possible I'm afraid.
ingress:
- hostname: myapp1.examples.com
service: http://localhost:8080
- hostname: myapp2.example.com
service: http://localhost:8081
- service: http_status:404
ingress:
- service: http://localhost:80
$ cloudflared tunnel route dns mytunnel test.example.com
The `clouflared tunnel route dns` command creates thee DNS record mapping the tunnel to the domain. The tunnels config maps the hostname to the local service, and you can have multiple of those for each service. So for the example above, you would create a DNS record for each domain pointing to the same one tunnel, and that tunnel will route based on the ingress rules.