Every inbound firewall rule is a standing invitation. It exists because something on the inside needs to be reachable from the outside, and it stays long after the reason is forgotten. Audit any mature environment and you will find rules referencing decommissioned hosts, vendors who left in 2019, and a source range that was "temporary."
The VPN is the same problem with better branding. A remote user authenticates once, receives a routable address inside your network, and is then trusted by everything that address can reach. The authentication is strong. What happens after it is not a security model — it is a network position.
Cloudflare Tunnel changes the direction of the connection, and that one change removes an entire category of exposure.
How the tunnel inverts the problem
A lightweight daemon — cloudflared — runs next to your application. It makes an outbound connection to Cloudflare's edge on ports 7844 (TCP and UDP) and holds it open. Traffic destined for your application arrives at Cloudflare, is matched against policy, and is delivered down that existing outbound connection.
The consequences are worth stating plainly:
- No inbound firewall rules. Nothing needs to be permitted inbound, because nothing arrives unsolicited.
- No public IP on the origin. The server can sit on RFC1918 space with no NAT entry and no route from the internet.
- It works behind CGNAT and on networks where you could not forward a port if you wanted to.
- The origin cannot be attacked directly, because it cannot be addressed directly. Port scanning your address space returns nothing, because there is nothing there.
That last point removes a class of misconfiguration rather than mitigating it. You cannot accidentally expose an admin panel that has no listening path from the internet. Compare that to the conventional model, where the security of your origin depends on every firewall rule, NAT entry and ACL being correct simultaneously and permanently.
The tunnel is not the security control
This is the mistake that matters, so it belongs before the architecture: a tunnel with no policy in front of it is a well-engineered way to publish an internal application to the entire internet. The tunnel solves reachability. Zero Trust is what decides who gets through, and it is a separate deliberate step.
A Cloudflare Zero Trust deployment has four components, and confusing them is the source of most bad designs:
| Component | What it connects | What it does |
|---|---|---|
Tunnel (cloudflared) |
Your applications and networks to Cloudflare | Outbound-only connectivity; no inbound rules |
| Access | Identity to applications | Authenticates and authorizes every request, per application |
| WARP | User devices to Cloudflare | The on-ramp; carries device posture and identity |
| Gateway | Outbound traffic from users and networks | DNS, HTTP and network filtering, egress policy |
Tunnel is plumbing. Access is the policy. WARP is how users get on. Gateway is what governs where they can go. You need at least Tunnel plus Access for anything internal; most real deployments use all four.
Three patterns that cover most of what people need
Pattern 1 — a public application, with the origin hidden
The application is meant to be public. You want it protected and you do not want the origin reachable.
Run cloudflared on the origin, publish the hostname through the tunnel, and let Cloudflare terminate TLS and apply WAF, bot management and rate limiting at the edge. The origin has no public address at all. This is usually the first tunnel an organization deploys, because it is uncontroversial and removes a public IP from the attack surface immediately.
Pattern 2 — an internal application, for employees and contractors
This is the VPN replacement, and the highest-value pattern.
The internal application — a wiki, a dashboard, a vendor portal, a management interface — is published through a tunnel and fronted by an Access policy. The policy evaluates identity from your existing IdP, group membership, device posture, country, and anything else you decide, on every single request.
The user experience is that they open a URL and authenticate. There is no client to launch for browser-based applications, no split-tunnel debate, no concentrator to size.
The security difference is structural: the user never receives a position inside your network. They receive access to one application. Lateral movement from a compromised laptop does not follow, because there is no network to move laterally across.
This is the pattern that solves the contractor problem outright. A third-party maintenance vendor who needs one management interface gets exactly that one interface, scoped to their identity, logged per request, and revoked by disabling an account rather than by editing firewall rules.
Pattern 3 — networks, servers and site-to-site
Some things are not web applications: SSH and RDP, database ports, SMB, thick clients, and traffic that originates from a server rather than a person.
Cloudflare handles this with private network routing — advertise internal CIDR ranges through the tunnel and reach them by address or internal hostname with WARP on the client side. For bidirectional and server-initiated traffic, the WARP Connector extends the same model to site-to-site connectivity, which is what lets you retire branch-to-branch VPN tunnels rather than just remote-access VPN.
The important discipline: advertising a /16 through a tunnel and calling it Zero Trust reproduces the flat VPN you were replacing. Advertise the narrowest ranges that work and apply network policy on top.
What you stop maintaining
Worth enumerating, because this is where the operational savings are:
- Inbound NAT and firewall rules for published services
- Public IP addresses for application origins
- The VPN concentrator, its licensing, its capacity planning and its patch cycle
- IP allowlists for partners and vendors, which break whenever their address changes
- Certificate management on internal origins, if you terminate at the edge
- The quarterly firewall rule review that nobody enjoys and nobody finishes
Mapping this to Zero Trust principles
Zero Trust is often reduced to "never trust, always verify," which is true and unhelpful. Concretely, this architecture delivers:
Verify explicitly. Every request to every application is authenticated and authorized against current identity and device state — not once at connection time, but continuously.
Least privilege. Access is granted per application, not per network. A user authorized for the ticketing system has no path to the finance server, because no path exists for them.
Assume breach. A compromised endpoint reaches only the applications that endpoint's identity is entitled to. The blast radius is a policy decision rather than a routing accident.
Log everything. Every request produces a record tied to an identity, an application and a device. That is materially better evidence than a VPN session log that says a user connected at 09:14 and did something for six hours.
Getting the implementation right
Sequence: start with one non-critical internal application. Publish it through a tunnel, put an Access policy in front, and run it alongside the VPN. Then expand by application, retiring VPN dependencies as you go. Do not attempt a cutover.
Redundancy: run multiple cloudflared replicas for any tunnel that matters. A tunnel with a single connector is a single point of failure that you will discover during a patch window.
Credential hygiene: tunnel credentials are secrets. They belong in a secret manager, scoped per tunnel, rotatable, and never in a shell history or a configuration repository.
Policy before publication: create the Access policy before you publish the hostname. The window between the two is the window where an internal application is public.
Device posture: if you deploy WARP, use it. Posture checks — disk encryption, patch level, EDR present — are what make "verify explicitly" more than a login prompt.
Logging: forward Access and Gateway logs to your SIEM from day one. The audit value of this architecture is the main reason compliance teams approve it, and it is only real if the logs go somewhere you look.
Where this does not fit
Be honest about the edges. Latency-sensitive industrial protocols inside an OT enclave belong behind industrial-aware firewalls, not routed through an internet edge. Some legacy applications assume a flat network and will need remediation before they work per-application. And bandwidth-heavy internal traffic — large file transfers between two internal sites — is usually better served by direct connectivity than by an edge round trip.
Those are design boundaries, not objections. Everything a human being reaches through a browser or a client, and most of what a server reaches across a WAN, fits comfortably inside this model.
BlackHawk Data is a Cloudflare Elite Partner and our engineering team holds 50+ Cloudflare certifications — a Cloudflare-specific count that sits within the 100+ engineering certifications we hold across all vendors. If you want a structured read on your current posture before you build, the Cloudflare Zero Trust assessment maps your applications, identities and exposure and returns a phased migration plan. Practice detail is at /solutions/cloudflare.