Cloudflare recently announced the new ability to create tunnels in just three steps, right from the dashboard. This made making new tunnels go from a process that could take you ~15-30 minutes to fully configure and understand, to something that you could do in less than 5 minutes, and get a fully set up, running as a service, production ready tunnel.
What are Cloudflare Tunnels
Cloudflare Tunnels can be used to expose internal services using outbound only connections. Think Ngrok tunnels. Cloudflare Tunnels can be used to proxy normal http/https connections, ssh/vnc, as well as more advanced things like arbitrary TCP, with some more restrictions.
The advantage of using Cloudflare Tunnels is not having to open any ports on your web server, no need for anything like IP Restrictions, Origin Cert checking, etc. Cloudflare Tunnels also use http/2 to connect to Cloudflare's Edge (soon http3/quic), whereas normally Cloudflare will only connect to an origin over http/1.1 (except for gRPC).
This guide will focus on setting up a tunnel for a normal web server over http. It's important to remember that since the tunnel is acting as a proxy for traffic, the web server (or whatever you are exposing via the tunnel) will see all incoming traffic as localhost. You will need to grab the real user's IP from a header (CF-Connecting-IP - normal cdn things) but also not rely on restricting any resources to localhost.
Pricing / Limits of Cloudflare Tunnels
Cloudflare Tunnels are completely free. Cloudflare Tunnels used to be named Cloudflare Argo Tunnels, and required a Cloudflare Argo Subscription. Cloudflare Argo is a service Cloudflare offers where they will use "smarter routing" to route requests to your origin avoiding network congestion, charging per gigabyte transferred.
Now Cloudflare has completely separated the products, while you can still buy an Argo Subscription to try to speed up traffic to your origin. Tunnels are free for any traffic amount with only a few limits: 1000 Tunnels per account, and 100 Active Connections from each tunnel to Cloudflare's edge.
Requirements:
- Cloudflare Account (free)
- Domain added to Cloudflare (using CF nameservers, etc)
- Linux server with a web server already configured on it
- No ports need to be port forwarded or allowed through your firewall
How to setup a Cloudflare Tunnel
Installing the tunnel
Navigate to the Cloudflare Zero Trust / Teams Dashboard within your Cloudflare Dashboard
Click create a tunnel in the top right, and enter a name that will be useful for identifying later.
Select your OS and architecture. If you're not sure, check if you have either dpkg on your system (Debian) or yum (Red Hat).
Execute the command it gives you, and wait for your Connector to connect (scroll down to the Connectors section)
Configuring the tunnel
In the route section, you are given a ton of options on how traffic will be routed to and through your cloudflared connector.
If you are hosting your service on a subdomain, just type in the subdomain, select your domain, and leave the path blank. If you're hosting on your apex, just select your domain.
For the Service section, it is about the service you already have running on your machine, which cloudflared will connect locally to. If you have a simple nginx/apache/openlitespeed server running on port 80, select HTTP for the service and type localhost:80. It doesn't matter that this part is HTTP, since it is all local on your machine and never leaves it.
Note that if you already have a DNS Record created for the specified hostname, as of 3/28/2022, it will just silently fail when you click save tunnel. You need to manually delete the conflicting record first.
If you are aiming to use the tunnel for a domain on the apex of your site (not on a subdomain), you will need to create a duplicate public hostname, but with the www subdomain, or your www subdomain will not work and potentially confuse visitors or other sources that assume www will always work.
Your configuration should look something like this:
YOUR.DOMAIN <-> Cloudflare's Edge <-> Cloudflared Daemon (On your server) <-> Your Web Server (Over port 80, localhost, depending on your configuration)
Then click "Save tunnel".
Cloudflare should have taken care of creating the DNS Record for the domain you picked, and you should be able to visit your application now.
Further Configuration
From the tunnels page, you can click "Configure" on your tunnel, and then under "Public Hostname", you can add more routes for other services on your machine. The UI is mostly self-explanatory and works according to the steps before.
How the tunnel works
You may have noticed, your tunnel makes multiple connections, sometimes even to different data centers. Cloudflare says it connects to multiple machines in case one crashes/reboots, it can use the other connections.
Each individual connection to Cloudflare is not limited to one user request at a time. Cloudflare says each connection can handle hundreds or thousands of requests at one time.
Cloudflare for Teams/Cloudflare Access has a generous free plan you can use as well, for up to 50 people, using Google (or a ton of other sso options) for auth. You can very easily make an Application policy to protect your tunnel and limit it to only specific emails or other options.
{Tunnel-UUID}.cfargotunnel.com is a virtual/non-existent domain, that is only used internally when it makes CName's pointing to your tunnel and other references. Other Cloudflare Customers cannotpoint their domains at your tunnel and bypass your Cloudflare Access or other restrictions.
Closing Notes
You can still use the old way to configure your tunnels, manually setting the configuration file, but there's no real upside. Cloudflare says this new way is slightly more secure too, as before on the server it stored a token that could be used to communicate with CF's API to create new tunnels, modify DNS records, etc. Now all the server needs is an auth token to connect the tunnel.
Now that you have your tunnel setup and running, you could consider routing SSH or VNC through your tunnel as well, and using Cloudflare Zero Access to protect those, instead of relying on
legacy VPNs or IP Whitelists.
Top comments (0)