Tunnelling Web Services with Cloudflared
In this post, I want to quickly summarise how I use cloudflared to expose web applications running on my home server to the internet.
Cloudflared is, as their README states, “a tunnelling daemon that proxies traffic from the Cloudflare network to your origins”. It does so by creating a persistent outbound connection, called a tunnel, between the host machine and Cloudflare’s edge servers.
CNAME DNS records, which point from one domain name to another, are used to redirect traffic for a domain to Cloudflare’s edge servers. In an earlier model, these DNS records were ephemeral and would be recreated when the tunnel was restarted. This system was called “Argo Tunnels”. Nowadays, tunnels are “named”, meaning they are issued a persistent UUID on creation, as well as a certificate to authenticate their owner. This change is documented here.
Cloudflared offers a CLI, as well as a Linux service, which shows ownership of a certain tunnel and then creates a persistent connection. After hitting the Cloudflare reverse proxy, traffic for a proxied URL is then redirected through the tunnel and towards a local web service on the host machine.
This approach has several advantages:
- The real host IP is completely hidden, and unlike the regular reverse proxy model, does not even have to be configured explicitly in Cloudflare. Any machine that can prove ownership of the named tunnel can immediately begin serving content simply via the tunnel’s UUID. Of course, we also benefit from the same security advantages as Cloudflare reverse proxying while doing so (such as load balancing, WAF, bot protection, etc.)
- Since traffic in the tunnel is automatically encrypted, and Cloudflare terminates TLS at its edge servers, a web application automatically provides HTTPS when provided via a cloudflared tunnel. This is unlike the regular reverse proxy system, where the connection between Cloudflare and the host via HTTPS ultimately still requires the host to supply its own SSL certificate to provide truly secure communication.
- Since the tunnel is an outbound connection, no specific firewall rules are necessary to expose a service. This means the setup provides fewer attack vectors, like open ports.
- The biggest advantage, of course, is that the host does not need to have a static IP, since the service is managed via a
tunnel and the real DNS target is a
UUID.cfargotunnel.comdomain. This allows a user to host web services from a home server without having to worry about updating DNS records for IP addresses dynamically provided by an ISP.
However, some disadvantages should also be considered, mainly:
- Similar to using Cloudflare as a reverse proxy, there is an implicit trust model between the host application and Cloudflare. Cloudflare terminates TLS and is theoretically able to read unencrypted traffic if said traffic is not end-to-end encrypted by the application.
Setting up cloudflared
Cloudflared can be set up mostly following the documentation.
Cloudflare recommends setting up remotely managed tunnels, as their configurations are stored on Cloudflare rather than locally, meaning it is easier to manage the tunnel from other machines. After first using the locally managed tunnels, I can also confirm that the UI is just nicer and easier to use than remembering the various CLI commands.
- Navigate to Cloudflare One > Networks > Connectors > Cloudflare Tunnels > Create a tunnel
- “Select Cloudflared” as a connector
- Name the tunnel
- Click “Save tunnel”
- Install cloudflared and register the tunnel as per the instructions
- Set up tunnel routes
- Congratulations, you’re done!
As for myself, I am mainly using published application routes, which connect a (sub)domain directly to a web service on the host. To set this up, simply select the subdomain, a domain managed by your Cloudflare account, and define the target service on the host machine.
When I initially set up cloudflared as a service, there were some issues since the configuration was stored in my user’s local folder (~/.cloudflared). I solved these issues by moving the certificate and tunnel file to /etc/cloudflared. This may be helpful to you.
Summary
For regular web applications hosted by individuals, I believe the advantages of cloudflared tunnels heavily outweigh the drawbacks. Cloudflared tunnels allow a user to securely and easily deploy web applications with SSL support without having to expose their network and without having to worry about IP configurations or SSL certificate renewals.
Over the next months, I plan to gradually dockerize most of my web applications and host them on a virtual server behind the cloudflared tunnel system. Additionally, the ease of use of the cloudflared tunnel also lets me easily spin up other FOSS applications to improve my quality of life.
As always, I will keep trying to improve my home infrastructure and learn about new technologies in the process.