Cloudflare Tunnels: Expose Local Services Without Port Forwarding

Port forwarding is a security liability. Opening ports means exposing your network, managing firewall rules, and hoping your ISP doesn’t change your IP. Cloudflare Tunnels solve this elegantly—your services connect outbound to Cloudflare, which handles incoming traffic.

How Tunnels Work

Traditional setup:

With Cloudflare Tunnel:

The tunnel daemon (cloudflared) runs on your server and maintains a persistent outbound connection to Cloudflare. No inbound ports needed.

Setting Up a Tunnel

Install cloudflared

1
2
3
4
5
6

# Debian/Ubuntu
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
sudo dpkg -i cloudflared.deb

# Or via package manager
sudo apt install cloudflared

Authenticate

1

cloudflared tunnel login

This opens a browser to authenticate with your Cloudflare account and stores credentials.

Create a Tunnel

1

cloudflared tunnel create my-tunnel

This generates:

• A tunnel ID (UUID)
• Credentials file at ~/.cloudflared/<tunnel-id>.json

Configure the Tunnel

Create /etc/cloudflared/config.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

tunnel: <your-tunnel-id>
credentials-file: /etc/cloudflared/<your-tunnel-id>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
  - hostname: api.example.com
    service: http://localhost:8080
  - hostname: grafana.example.com
    service: http://localhost:3001
  - service: http_status:404  # Catch-all (required)

The catch-all rule at the end is mandatory—it handles requests that don’t match any hostname.

Configure DNS

Point your subdomains to the tunnel:

1
2

cloudflared tunnel route dns my-tunnel app.example.com
cloudflared tunnel route dns my-tunnel api.example.com

Or manually create CNAME records:

Run as a Service

1
2
3

sudo cloudflared service install
sudo systemctl enable cloudflared
sudo systemctl start cloudflared

Advanced Configuration

WebSocket Support

For apps needing WebSockets (chat, live updates):

1
2
3
4
5

ingress:
  - hostname: realtime.example.com
    service: http://localhost:3000
    originRequest:
      noTLSVerify: true  # If your local service uses self-signed cert

WebSockets work automatically through the tunnel.

Load Balancing Multiple Origins

1
2
3
4
5
6

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
    originRequest:
      connectTimeout: 30s
      noHappyEyeballs: true

For true load balancing, use Cloudflare Load Balancer with multiple tunnels.

Access Control

Combine with Cloudflare Access for authentication:

1
2
3
4

ingress:
  - hostname: admin.example.com
    service: http://localhost:8080
    # Cloudflare Access policies apply at the edge

Then configure Access policies in the Cloudflare dashboard to require SSO, email verification, or other authentication.

Private Networks

Tunnel can also route to private IPs:

1
2
3

ingress:
  - hostname: internal.example.com
    service: http://192.168.1.50:8080

The tunnel daemon needs network access to that IP, but the service itself doesn’t need to be on the same machine.

Comparison: Tunnel vs Traditional

Troubleshooting

Check tunnel status

1

cloudflared tunnel info my-tunnel

Test locally

1

cloudflared tunnel run my-tunnel

Watch the output for connection errors.

Common issues

“failed to connect to origin”

• Check if local service is running
• Verify the port number in config
• Check if service binds to localhost vs 0.0.0.0

DNS not resolving

• Verify CNAME record exists
• Check if proxied (orange cloud) is enabled
• Wait for DNS propagation (up to 5 minutes)

SSL errors

• Cloudflare handles edge SSL automatically
• For origin, use http:// in config (tunnel encrypts the connection)
• Use noTLSVerify: true if origin has self-signed cert

Logs

1

sudo journalctl -u cloudflared -f

Migration Strategy

Moving existing services to tunnels:

1. Set up tunnel without changing DNS
2. Test with /etc/hosts on a test machine
3. Update DNS to point to tunnel
4. Remove port forwards from router
5. Close firewall ports

The cutover is just a DNS change—if something breaks, point DNS back to your IP.

When Not to Use Tunnels

Tunnels aren’t ideal for:

• High-bandwidth streaming (Plex, game servers) — Cloudflare’s ToS limits non-HTML content on free tier
• UDP traffic — Tunnels are TCP-only (use WARP for UDP)
• Latency-critical applications — Adds ~10-50ms through Cloudflare edge

For these cases, direct connections or WireGuard might be better.

The Security Win

The biggest benefit isn’t convenience—it’s security posture:

• No open ports = smaller attack surface
• No public IP exposure = harder to target
• Cloudflare’s WAF = free protection layer
• Access controls = authentication at the edge

Your home network stays invisible. Traffic comes through Cloudflare or it doesn’t come at all.

That’s worth the 20 minutes of setup.

Recommended Setup

Cloudflare Tunnels work great with any VPS:

• DigitalOcean — $200 free credit. Perfect for self-hosting behind tunnels.
• Vultr — $100 free credit. Global edge locations.
• Cloudflare — Free tier includes tunnels, DNS, and CDN.

Disclosure: Some links are affiliate links.