Cloudflare Zero Trust Tunnels: Secure Access Without Exposed Ports

Modern infrastructure rarely lives in one place. Some servers run in the cloud, others sit on an office LAN, and a few inevitably end up at home. They span Linux and Windows, different networks, different trust boundaries.

The traditional answers—opening SSH or RDP ports, managing VPNs, sharing keys—are functional but fragile. They add operational overhead, expand your attack surface, and age poorly as environments grow.

This article documents the approach I’ve standardized on: Cloudflare Zero Trust Tunnels using cloudflared. It’s the same model I now use across all my environments.

The Infrastructure

Each server establishes an outbound‑only connection to Cloudflare’s edge. There are no inbound firewall rules and no public IP exposure.

Access is enforced at Cloudflare’s Zero Trust layer:

• Identity‑based (email, SSO, device posture)
• Device‑aware via the WARP client
• Network‑agnostic (cloud, LAN, home all behave the same)

If Cloudflare doesn’t explicitly allow the request, the service effectively does not exist.

This setup is currently running across 10+ servers distributed between cloud instances, office networks, and home infrastructure. It’s used both for administrative access (SSH, RDP) and for selectively exposing private services to trusted users.

Threat Model Assumptions

This setup is designed with a specific threat model in mind.

• The public internet is untrusted. No assumption is made about the safety of exposed IPs, forwarded ports, or perimeter firewalls.
• Endpoints may be mobile or transient. Clients connect from changing networks (home, office, mobile), so IP-based controls are intentionally avoided.
• Identity is the primary security boundary. Access decisions are based on authenticated users, devices, and posture—not network location.
• Cloudflare is a trusted control plane. Cloudflare is assumed to correctly enforce Access policies and tunnel authentication. If this trust is unacceptable, this model is not a good fit.
• Host compromise is out of scope. If an attacker gains root or SYSTEM-level access to the server itself, tunnel-based access controls do not protect against that.

Within these assumptions, Zero Trust Tunnels significantly reduce exposed attack surface while keeping operational complexity low.

Implementation Details

1. Install cloudflared

Linux:

wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb

Windows:

• Download and install the MSI from Cloudflare’s official GitHub releases.

2. Authenticate the host

cloudflared tunnel login

This associates the machine with your Cloudflare Zero Trust account.

3. Create a tunnel per site or network

I keep tunnels aligned with physical or logical locations:

cloudflared tunnel create colombo-lan

The same pattern applies for office networks or cloud environments.

4. Define ingress rules

Example /etc/cloudflared/config.yml:

tunnel: colombo-lan
credentials-file: /etc/cloudflared/colombo-lan.json
ingress: - hostname: ssh.home.pasindudissan.xyz service: ssh://localhost:22 - hostname: rdp.office.pasindudissan.xyz service: rdp://localhost:3389 - service: http_status:404
warp-routing: enabled: true

Each hostname maps cleanly to a private service. And if you aren't a non-technical person you can even use Cloudflare's dashboard and achieve a good enough setup without having to write maintain or manage config files. No port forwarding, no NAT gymnastics.

5. Run cloudflared as a service

cloudflared service install
systemctl start cloudflared

6. Apply Zero Trust policies

From the Cloudflare dashboard:

• Map externally resolvable hostname to the tunnel
• Define Access policies (email allowlists, SSO groups, device posture)

This is where authorization lives. The server itself remains unreachable from the public internet.

Day‑to‑Day Access

With the WARP client running on my laptop or workstation, access is transparent.

SSH:

ssh user@ssh.home.pasindudissan.xyz

RDP:

• Connect to rdp.office.pasindudissan.xyz as you would on a local network.

Traffic is authenticated by identity, not IP addresses or shared secrets. The same configuration scales cleanly across AWS, on‑prem, and home networks without additional complexity.

Why Not a Traditional VPN?

VPNs solve connectivity by extending the network boundary. That works, but it introduces problems that compound over time.

• Over-broad access
  Once connected, clients typically gain visibility into far more of the network than intended.

• Credential and key sprawl
  Shared secrets, long-lived keys, and stale client configurations accumulate quickly.

• Operational friction
  Split tunneling, DNS inconsistencies, client compatibility issues, and routing conflicts are common.

• Poor fit for mixed environments
  Home networks, office LANs, and cloud VPCs behave differently, and VPNs tend to leak those differences.

Zero Trust Tunnels invert this approach. Instead of granting network access, they publish a single service behind identity- and device-aware policies. There is no concept of being “on the network”—only being authorized for an application.

Operational Notes

• No inbound ports exposed
• No VPN key rotation
• No firewall rule drift
• Works reliably across unstable home connections

This setup has been running continuously for months. Family members access private services like Nextcloud without a single router‑level port forward.

UPDATED: Related Notes

This article ties into my broader self‑hosting and infrastructure notes:

• Access from Anywhere Without Complex Setups

• Securing Access with Free WAF and Zero Trust Tunnels

Closing

If you’re managing access across mixed environments, the biggest win here isn’t just security—it’s consistency. Every network behaves the same, regardless of where it lives.

If one part of your infrastructure still feels painful to access remotely, that’s usually the best place to start tightening things up.