Cloudflare Tunnel: Publish Internal Business Apps Without Opening Firewall Ports

Cloudflare Tunnel lets you publish an internal web application, such as a client portal, a reporting dashboard or an admin tool, at a normal hostname like portal.example.com without opening any inbound ports on your firewall. A small program called cloudflared runs on a server inside your network and makes outbound-only connections to Cloudflare. Visitors connect to Cloudflare, and Cloudflare sends their requests back down those connections. Your public IP address doesn't need to accept web traffic at all. Add Cloudflare Access in front of it, run two connectors for redundancy, and keep cloudflared updated, and you have a safer way to publish internal apps than port forwarding.

How it works

Traditional publishing means forwarding ports 80 or 443 on your firewall to an internal server. Anyone on the internet can then reach that server, scan it and try exploits against it.

With a tunnel:

1. cloudflared starts on a machine that can reach the application, either the app server itself or a small VM next to it.
2. It opens outbound connections to nearby Cloudflare data centers. Each cloudflared instance opens four connections.
3. A visitor requests portal.example.com. Cloudflare matches the hostname to your tunnel and sends the request through it.
4. cloudflared forwards the request to the internal service, for example http://localhost:8080, and returns the response.

Cloudflare's documentation recommends a positive security model: block all inbound traffic and allow only the outbound traffic cloudflared needs. The main requirement is outbound port 7844 over both TCP and UDP (HTTP/2 and QUIC). If your firewall restricts outbound traffic, allow that first.

Remotely-managed vs locally-managed tunnels

	Remotely-managed	Locally-managed
Where configuration lives	On Cloudflare (dashboard, API or Terraform)	In a config.yml file on your server
How it's created	In the dashboard; you run a provided install command	From the command line with cloudflared tunnel create
Cloudflare's guidance	Recommended for most use cases	Intended for specific cases such as local development, testing or legacy configurations

For most businesses, a remotely-managed tunnel is the right choice. Anyone with dashboard access can see and change the routes, and nobody has to log in to the server to add a hostname.

Setting up a remotely-managed tunnel

1. Make sure the domain is already active on Cloudflare. A tunnel can only publish hostnames in zones on your account.
2. In the Cloudflare dashboard, go to Networking > Tunnels and select Create a tunnel. Give it a clear name, such as office-portal. Cloudflare reorganizes its menus from time to time, so if the path differs, search the dashboard for "Tunnels".
3. Choose the server's operating system. Cloudflare shows an install command that includes your tunnel token. Run it on the server. It installs cloudflared as a system service (systemd on Linux, a Windows service on Windows) so the tunnel starts at boot.
4. Treat the token like a password. Anyone who has it can run a connector for your tunnel. Don't paste it into tickets or chat.
5. On the tunnel's Routes tab, select Add route > Published application. Enter the subdomain and domain, and set the Service URL to the internal address, for example http://localhost:8080 or https://10.0.0.20.

Cloudflare creates the DNS record for you on a full DNS setup. Before step 5, read the Access section below.

Locally-managed tunnels and ingress rules

If you manage the tunnel from the command line, the sequence in Cloudflare's docs is cloudflared tunnel login, cloudflared tunnel create <NAME>, a config.yml file, cloudflared tunnel route dns <NAME> <hostname> and cloudflared tunnel run <NAME>. The config file maps hostnames to internal services with ingress rules:

tunnel: <Tunnel-UUID>
credentials-file: /root/.cloudflared/<Tunnel-UUID>.json

ingress:
  - hostname: portal.example.com
    service: http://localhost:8080
  - hostname: reports.example.com
    service: http://10.0.0.25:3000
  - service: http_status:404

Rules are checked from top to bottom, and the first match wins. Cloudflare requires a catch-all rule at the end. The usual choice is http_status:404, which returns a 404 for any hostname you did not list, so nothing is exposed by accident. Two commands catch mistakes before they go live:

• cloudflared tunnel ingress validate checks that the rules are valid.
• cloudflared tunnel ingress rule https://portal.example.com shows which rule a URL would match.

To run it as a Linux service, use cloudflared service install. If you run that with sudo, pass --config with the full path to your file, because $HOME becomes /root.

Always combine a tunnel with Access

A tunnel hides your server, but it does not decide who may use the application. Cloudflare's documentation warns that a published application without an Access application in front of it is available to anyone on the internet. For anything internal:

1. Create a Cloudflare Access application for the hostname before you add the route. Use an Allow policy limited to your staff's identity provider group or specific emails.
2. In the tunnel route settings, enable Protect with Access so that cloudflared itself checks the Access token.

For websites that are meant to be public, the Cloudflare WAF adds request filtering on top.

High availability with replicas

A single cloudflared process is a single point of failure. If that VM reboots for updates, the app goes offline. Cloudflare's answer is replicas: run the same tunnel on a second machine. Each replica opens its own four connections, and if one host fails the others keep serving traffic.

Two limits to know:

• Replicas don't load-balance. Cloudflare sends traffic to the geographically closest replica, with no round-robin or hash-based steering. For real traffic distribution, Cloudflare points to its Load Balancing product with separate tunnels.
• Replicas only help if they run on different hardware. Two VMs on the same host don't protect you from that host failing.

Replicas also let you update cloudflared one machine at a time without downtime.

Keep cloudflared updated

Cloudflare's cloudflared README states that Cloudflare supports versions released within one year of the most recent release. Older versions may break when Cloudflare changes things on its side. To update:

• If you installed from a package repository (apt, yum/dnf, Homebrew), upgrade with that package manager and restart the service.
• If you installed the standalone binary, run cloudflared update and restart the service, for example sudo systemctl restart cloudflared.service on Linux.
• With Docker, pull the latest image and recreate the container.

An update restarts cloudflared and briefly interrupts traffic. With replicas you avoid that. Add cloudflared to your regular patching routine like any other software.

When a tunnel is not the right tool

• Inbound email. Mail servers that receive SMTP on port 25 need inbound connections from other mail servers. A published application route isn't designed for that.
• Staff who need the whole network. If employees need file shares, RDP or many internal IP addresses, Cloudflare's private-network routing with its device client, or a traditional VPN, fits better than publishing apps one by one. Our remote and hybrid work guide covers the options.
• Large uploads or long-running requests. Proxied traffic is subject to Cloudflare's request size limits and timeouts, which vary by plan. Apps that move very large files may need a different design.
• Sites that already run on public hosting. A cPanel or cloud-hosted website that is meant to be public is usually better served by a proxied DNS record, the right SSL/TLS mode and a locked-down origin firewall.

Core Florida IT sets up Cloudflare Tunnel and Access for businesses as an independent IT provider; Cloudflare doesn't endorse us. Our cybersecurity and managed IT support teams can review which of your internal apps are exposed today. Request a free IT assessment, whether your office is in Miami-Dade, Broward or elsewhere in South Florida.

Sources

• Cloudflare Tunnel overview (Cloudflare Docs)
• Create a tunnel in the dashboard (Cloudflare Docs)
• Locally-managed tunnels (Cloudflare Docs)
• Configuration file and ingress rules (Cloudflare Docs)
• Tunnel availability and replicas (Cloudflare Docs)
• Tunnel with firewall (Cloudflare Docs)
• Update cloudflared (Cloudflare Docs)
• cloudflared README: supported versions (GitHub)
• Add a self-hosted public application (Cloudflare Docs)