[ HOME ]    [ RADIO ]    [ COMPUTERS ]    [ FIELD STATION ]    [ ABOUT ]    [ MODERN MODE ]
=== CLOUDFLARE TUNNELS: SECURELY EXPOSING LOCAL SERVICES W/O PORT FORWARDING ===

Exposing local homelab services (like Nextcloud, Jellyfin, or a local wiki) to the public internet traditionally required static IP addresses, complex router port forwarding, and dealing with dynamic DNS (DDNS). Furthermore, if your ISP uses Carrier-Grade NAT (CGNAT)-common with fiber, cellular, and Starlink providers-traditional port forwarding is completely impossible.

Cloudflare Tunnels solves this by establishing a secure, outbound-only connection from your server directly to Cloudflare’s edge network. No open inbound ports are required on your router, and your server’s true IP address remains completely hidden.


1. How Cloudflare Tunnels Work (Architecture)

Instead of the internet reaching in to your server, a lightweight daemon called cloudflared runs on your server and reaches out to Cloudflare.

  1. cloudflared establishes persistent multiplexed HTTP/2 (or QUIC) connections to the nearest Cloudflare data centers.
  2. A user types your-service.your-domain.com into their browser.
  3. The DNS record points to the Cloudflare network.
  4. Cloudflare routes the traffic down the established tunnel directly to your local application.
  5. Your router’s firewall blocks all unsolicited inbound traffic, rendering port scanners (like Shodan) blind to your infrastructure.

2. Prerequisites

  • A domain name with its DNS managed by Cloudflare.
  • A Linux host (VM, LXC container, or Raspberry Pi) to run the cloudflared daemon.
  • A local service running (e.g., a web server on http://192.168.1.50:8080).

3. Installation and Authentication

We will install cloudflared on a Debian/Ubuntu-based system.

Step 1: Install cloudflared

Download the pre-compiled .deb package directly from Cloudflare’s repository:

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

Step 2: Authenticate the Daemon

Run the login command. This will generate a URL in your terminal.

cloudflared tunnel login

Copy the URL, open it in a web browser, log into your Cloudflare account, and select the domain you want to authorize. A certificate (cert.pem) will be downloaded to ~/.cloudflared/.


4. Creating and Configuring the Tunnel

Step 1: Create the Tunnel

Create a new tunnel named homelab (or whatever you prefer):

cloudflared tunnel create homelab

Note the UUID returned in the terminal. A credentials file (<UUID>.json) will be created in ~/.cloudflared/.

Step 2: Map a DNS Record

Bind a subdomain to your new tunnel. For example, to route app.your-domain.com through this tunnel:

cloudflared tunnel route dns homelab app.your-domain.com

Step 3: Create the Configuration File

Create a config.yml file in ~/.cloudflared/config.yml to define how traffic should be routed once it comes down the tunnel.

tunnel: <YOUR-TUNNEL-UUID>
credentials-file: /home/<your-user>/.cloudflared/<YOUR-TUNNEL-UUID>.json

# Ingress Rules map hostnames to local services
ingress:
  # Route the specific subdomain to a local web server
  - hostname: app.your-domain.com
    service: http://localhost:8080
  
  # Route an SSH connection (requires cloudflared on the client side too)
  - hostname: ssh.your-domain.com
    service: ssh://localhost:22

  # Catch-all rule (Required by cloudflared, returns a 404 for unmapped hostnames)
  - service: http_status:404

5. Running as a System Service

To ensure the tunnel survives reboots and runs silently in the background, install it as a systemd service.

# Route the systemd service to use your specific config file
sudo cloudflared service install

(If it fails to find the config, copy your ~/.cloudflared directory contents to /etc/cloudflared/ before running the install command).

Start and enable the service:

sudo systemctl start cloudflared
sudo systemctl enable cloudflared
sudo systemctl status cloudflared

6. Advanced Use Cases: Zero Trust Access

Because the traffic passes through Cloudflare, you can layer Cloudflare Zero Trust Access on top of your tunnel. This acts as an Identity-Aware Proxy (IAP).

Instead of exposing an internal dashboard to the whole internet, you can create an Access policy that requires a user to authenticate via Google, GitHub, or a One-Time PIN (OTP) sent to their email before Cloudflare allows the packets to travel down the tunnel to your server.

To configure this:

  1. Go to the Cloudflare Zero Trust Dashboard.
  2. Navigate to Access > Applications and click Add an Application.
  3. Enter your tunnel’s subdomain (app.your-domain.com).
  4. Create a policy (e.g., “Allow only emails ending in @your-domain.com” or specify a list of allowed email addresses).

Now, any visitor hitting that URL will be intercepted by a Cloudflare login screen. Only authorized users will ever touch your local server.




W4DXR Retro Terminal | Station Log & Technical Notebook