Cloudflare Tunnel

The Architecture

Cloudflare Tunnel (cloudflared) creates an outbound-only encrypted connection from your server to Cloudflare's global edge network. Your firewall can block all inbound traffic — no ports need to be opened, no public IP is required, and no dynamic DNS service is needed.

Users connect to Cloudflare's anycast network, which provides DDoS protection, a WAF, and caching. Cloudflare then routes requests through the persistent tunnel to your cloudflared daemon, which forwards them to your local service.

• No inbound firewall rules — cloudflared initiates all connections outbound on port 7844 (UDP preferred, TCP fallback). Your router's NAT is never touched.
• No public IP — works behind CGNAT, home ISP NAT, or any network that blocks inbound connections.
• Automatic failover — cloudflared maintains multiple connections to different Cloudflare PoPs for redundancy.
• TLS everywhere — Cloudflare terminates TLS from the browser; the tunnel itself uses QUIC or HTTP/2 with TLS between Cloudflare and your daemon.

Prerequisites

Before you begin, you need three things. The tunnel itself is completely free on Cloudflare's free tier.

• Cloudflare account — sign up at dash.cloudflare.com. Free tier includes the tunnel, Zero Trust, WAF (basic), and DDoS protection.
• Domain on Cloudflare DNS — your domain's nameservers must point to Cloudflare. This is required because Cloudflare automatically creates CNAME records for your tunnel hostnames. You cannot use Cloudflare Tunnel with a domain managed elsewhere. Nameserver delegation typically propagates within 24 hours.
• cloudflared binary — the connector daemon that runs on your server. Available for Linux (amd64/arm64), macOS, Windows, and as a Docker image. See the OS-specific installation steps in Section 3.
• Zero Trust enabled — navigate to Zero Trust in the Cloudflare dashboard and complete the one-time onboarding (free, no credit card required for the free plan).

Approach A: Tunnel → Caddy (Recommended)

Cloudflare Tunnel connects to Caddy. Caddy acts as a local reverse proxy and virtual host router. This is the best setup when you have multiple apps on one server or need Caddy features like basic auth, path rewriting, or access logs.

Set your Cloudflare tunnel public hostname URL to http://localhost:80 (bare metal) or http://caddy:80 (Docker). Caddy uses auto_https off since TLS is handled at the Cloudflare edge.

:80 {
    @app1 host app1.yourdomain.com
    handle @app1 {
        reverse_proxy app1:3001
    }

    @app2 host app2.yourdomain.com
    handle @app2 {
        reverse_proxy app2:3002
    }

    # Optional: strip /api prefix before forwarding
    @vllm host api.yourdomain.com
    handle @vllm {
        uri strip_prefix /v1
        reverse_proxy ml-backend:8002
    }
}

Caddy's host matcher reads the Host HTTP header, which Cloudflare preserves correctly by default.

Approach B: Tunnel → Direct App (Simple)

Skip Caddy entirely and point the tunnel directly at your application. Best for a single service or when you want the simplest possible setup.

In the dashboard: set Service Type to HTTP and URL to localhost:3000. No Caddy needed.

Trade-offs vs Approach A:

• No virtual hosting — one tunnel hostname per app port
• No Caddy access logs or log formatting
• No Caddy-level basic auth or rate limiting
• No request rewriting or path manipulation
• Simpler — fewer moving parts, easier to debug

👤 Cloudflare Access (Zero Trust Auth)

Put identity-based authentication in front of any tunnel hostname. Users must authenticate before any request reaches your server — your app never sees unauthenticated traffic.

Zero Trust → Access → Applications → "Add an application" → Self-hosted

• Identity providers — Google, GitHub, Microsoft, email OTP (magic link), SAML 2.0, OIDC. Free tier supports one provider.
• Free for 50 users — ideal for personal homelab or small team use.
• Session duration — configure how long a login session lasts (24h default). Users re-auth after session expires.
• Per-app policies — different rules for different apps. Allow only your Google account for personal apps, allow your whole domain for team apps.

# Example Access policy (configured in dashboard):
# Application: grafana.yourdomain.com
# Policy: Allow
# Rule: Emails → [email protected]

🚫 Block All Direct Inbound Traffic

Once your tunnel is working, lock down your firewall so that your services are only reachable through Cloudflare. This eliminates direct attack surface.

# UFW (Ubuntu/Debian)
# Block all inbound on 80 and 443
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

# Allow outbound (cloudflared needs port 7844)
# UFW allows outbound by default — no action needed.

# Verify cloudflared can still reach Cloudflare
curl -I https://region1.v2.argotunnel.com

• cloudflared connects outbound on UDP port 7844. If UDP is blocked, it falls back to TCP 443.
• You can verify with: curl https://region1.v2.argotunnel.com — should return HTTP 400 (tunnel protocol, not HTTP).

🛡 Cloudflare WAF

The Web Application Firewall blocks OWASP Top 10 attacks, SQL injection, XSS, and known CVEs before traffic reaches your server. Available on the Pro plan ($20/mo) and above.

Domain → Security → WAF → Managed Rules → enable Cloudflare Managed Ruleset and OWASP Core Ruleset

• Cloudflare Managed Ruleset — Cloudflare's own rules for common web attacks, updated continuously.
• OWASP Core Ruleset — industry-standard rules. Set anomaly threshold to "Medium" to start — "Low" generates false positives for many apps.
• Custom rules — block specific countries, user-agents, IP ranges, or request patterns with firewall rules (free tier: up to 5 rules).

🔓 IP Allowlist via Access Policies

Restrict an application to specific IP ranges using Access policy rules. Useful for admin panels that should only be reachable from your office or home IP.

Zero Trust → Access → Applications → your app → Policies → add a rule:

• Rule type: IP ranges
• Value: 203.0.113.0/24 (your office/home CIDR)
• Combine with an email rule using AND logic: must be from allowed IP and authenticated identity.

# Or block at the WAF level with a custom rule:
# Field: ip.src
# Operator: not in
# Value: {203.0.113.5, 198.51.100.0/24}
# Action: Block

🔑 mTLS for API Authentication

Mutual TLS (mTLS) requires clients to present a valid certificate. Useful when you have internal services or automation calling your APIs — ensures only authorized systems can connect, regardless of network position.

Zero Trust → Access → Service Auth → mTLS

• Cloudflare acts as the CA — it issues client certificates you distribute to your services.
• Configure a hostname-level mTLS policy: requests without a valid cert get a 403 before reaching your origin.
• Combine with Access policies for layered auth: mTLS (machine identity) + JWT (user identity).

📥 Browser Isolation & DLP

For Enterprise use cases: Cloudflare's Remote Browser Isolation (RBI) renders web pages in Cloudflare's cloud, sending only safe pixels to the end user. Data Loss Prevention (DLP) scans uploads/downloads for sensitive data patterns (PII, credit card numbers, etc.).

• RBI — prevents malicious JavaScript from executing in corporate endpoints. Requires Enterprise plan.
• DLP — requires Zero Trust Gateway with an appropriate plan.
• For homelab / small team: these features are beyond what you need. Stick to Access + WAF.