Outbound-Only: Cloudflare Tunnels as a Zero-Trust Integration Layer

We have spent, cumulatively, months of our lives negotiating firewall rules. Not writing integration code. Negotiating. Sitting in tickets with a network team, explaining why a cloud service needs to reach an on-prem host, waiting for a change window, discovering the VPN gateway is at capacity, re-explaining it to the security team, waiting again.

That work produced nothing a customer would ever see. It was pure friction between two systems that needed to talk. Outbound-only tunneling is the first pattern we’ve found that makes most of it disappear, and for connecting legacy on-prem systems to cloud APIs, it has changed how we scope projects.

The problem is the direction of the connection

Here’s why the old way is so painful. A cloud service reaching an on-prem system is an inbound connection from the perspective of the corporate network. Inbound means opening a hole. A hole means a public IP or a NAT rule, a firewall exception, a VPN gateway, and split-brain DNS so the name resolves differently inside and out.

Every one of those is a thing a security team is right to resist. Each is an attack surface. Each is a standing exception that outlives the person who requested it. Fifteen years of integration work taught us that the connection direction is the whole fight: inbound is expensive and political, outbound is cheap and boring.

Tunnels flip the direction. A lightweight agent, cloudflared, runs next to the on-prem system and makes an outbound, encrypted connection to Cloudflare’s edge. The origin never accepts an inbound connection from the internet. There is no public IP to expose, no inbound firewall rule to negotiate, no VPN gateway to maintain. Traffic reaches the origin by riding back down a connection the origin itself opened.

The sentence that closes projects: the legacy system’s network team doesn’t have to open a single port. Outbound 443 is already allowed. You’re done.

What the traffic actually does

The flow, end to end, is straightforward. A user or a calling service hits Cloudflare’s edge. The edge applies Zero Trust policies: who is this, are they allowed to reach this specific service. Only then does traffic pass through the tunnel to the origin.

That ordering matters. Identity and policy are enforced before anything touches the origin, at the edge, not by the fragile old system itself. The legacy host, which was never designed to authenticate modern users, sits behind a policy engine that speaks Okta, Azure AD, and SAML/OIDC. You add identity-aware access to a system that has no idea what an identity provider is.

Cloudflare’s own reference architecture lays out three connectivity tiers, and the choice is worth understanding. Public DNS is the simplest and the one you usually don’t want for internal systems. Tunnels are the recommended default: outbound-only, no exposed origin. And a direct network interconnect is available when you need maximum throughput and can justify the setup. For most integration work bridging on-prem to cloud, the middle tier is the answer.

Where it fits, and where it doesn’t

It handles more than HTTP. Tunnels carry HTTPS, and also raw TCP (SSH, RDP, database connections), plus private routing for arbitrary traffic. That range is what makes it an integration tool and not just a web-app front door. We’ve used it to reach a database that had spent its entire life inside a corporate network and was never meant to be reachable from a cloud job.

It also drops cleanly into Kubernetes. You can run the connector as a workload and expose an internal service without provisioning an ingress controller or a public load balancer. For teams running integration workloads on-prem in Kubernetes, that removes a whole class of networking setup.

Now the honest limits, because there’s no turnkey in integration and this is no exception.

You’re adding a dependency on Cloudflare’s edge in your critical path. For a lot of systems that’s a net gain in reliability (their edge is more available than the VPN gateway you were maintaining), but it’s a dependency, and your monitoring and incident runbooks have to account for it. If the tunnel is down, the integration is down, and someone needs to know that at 3 AM.

Compliance can complicate it. Some environments mandate that traffic egress through specific network zones or that data never traverse a third party’s infrastructure. Those constraints are real and they’re knowable in advance, which is exactly the point. You find out during requirements, not during rollout.

And the connector is now a component you operate. It runs somewhere, it updates, it has a health state. That’s a small operational surface compared to a VPN gateway, but it isn’t zero, and pretending otherwise is how you get surprised.

Why we reach for it now

The reason this pattern earns its place is that it removes the least valuable, most contentious part of an integration project (the inbound-connectivity fight) and replaces it with a component we can reason about and monitor.

The old model spent human weeks negotiating a standing exposure that the security team correctly hated. The new model spends an afternoon deploying a connector that exposes nothing. When the hardest part of connecting two systems stops being a political negotiation and starts being a deploy, the whole shape of the project changes. You spend your time on the integration that matters instead of on the plumbing that shouldn’t have been hard in the first place.