Zero Trust for a Small Home Lab: Protecting Self-Hosted Apps with Cloudflare Access

Self-hosting is fun—until an admin panel, NAS UI, or WireGuard dashboard ends up exposed to the public internet. A simple and robust alternative to port forwarding is Cloudflare Zero Trust:

• Cloudflare Tunnel (cloudflared) keeps your services reachable without a publicly routable IP and without opening inbound ports, by creating outbound-only connections to Cloudflare. (Cloudflare Docs)

• Cloudflare Access puts an identity-aware login gate (SSO/MFA/policies) in front of those services—so only approved users can reach them. (Cloudflare)

This article shows how to protect common homelab targets—admin panels, NAS, WireGuard UI, SSH—using Access + Tunnel, while keeping your origin private.

---

What you’re actually building

Goal: “Private app, public entry point” — your service stays in your LAN, but Cloudflare becomes the only door.

High-level flow:

You (browser)  →  Cloudflare Access (login + policy)  →  Cloudflare Tunnel  →  Local service (LAN)

Cloudflare provides a documented option to publish a self-hosted app and require Access authentication—either by enabling “Protect with Access” at the tunnel route level or by validating Access tokens at your origin. (Cloudflare Docs)

---

Why this is safer than “just reverse proxy + password”

With Cloudflare Access you get:

• Identity-based allow rules (email, group, IdP claims) instead of a shared password (Cloudflare Docs)

• Easy MFA via your identity provider (Google/GitHub/Okta/etc.) (Cloudflare Docs)

• Centralized policy control per app (NAS UI can be stricter than a media server)

And with Tunnel you get:

• No port forwarding, no inbound firewall holes, no need for a public IP (Cloudflare Docs)

---

The building blocks

1) Cloudflare Tunnel (cloudflared)

Runs inside your homelab (Docker, VM, bare metal). It connects outward to Cloudflare and forwards requests to your internal services. Cloudflare describes Tunnel as a lightweight daemon creating outbound-only connections to Cloudflare’s global network. (Cloudflare Docs)

Firewall note: Cloudflare documents that cloudflared connects on port 7844 (UDP for QUIC or TCP for HTTP2), so your network must allow outbound access accordingly. (Cloudflare Docs)

2) Cloudflare Access

Access verifies who you are (identity provider) and applies your rules before letting you through. Cloudflare positions Access as a ZTNA product that secures access to self-hosted and non-web apps. (Cloudflare)

3) Identity Provider (IdP)

Access integrates with your IdP so logins can be Google, GitHub, etc., and you can reuse MFA there. (Cloudflare Docs)

---

Recommended homelab architecture (clean and scalable)

Pattern A — “One app = one hostname”

Create separate subdomains so each app gets its own policy:

• nas.example.com → NAS web UI

• wg.example.com → WireGuard UI / admin

• admin.example.com → homelab admin panel

• ssh.example.com → SSH access (optional)

Each hostname routes to the right internal IP:port via the tunnel, and each hostname is protected by Access.

This keeps policies simple: NAS can require stronger rules (MFA + specific emails), while a lower-risk dashboard can be more relaxed.

---

Setup steps (conceptual, homelab-friendly)

Step 1 — Create a Tunnel and connect your lab to Cloudflare

Install and run cloudflared in your homelab and create a tunnel. The key point is: Tunnel connects your private resources to Cloudflare without needing a public IP and without inbound exposure. (Cloudflare Docs)

Step 2 — Add “Public Hostnames” for each internal service

For each service, map:

• Hostname: nas.example.com

• Service: http://192.168.1.10:5000 (example)

Repeat for WireGuard UI, admin panels, dashboards, etc.

Step 3 — Turn on “Protect with Access”

Cloudflare documents you can enable Access protection on the tunnel route (“Protect with Access”) so authentication is enforced at the edge. (Cloudflare Docs)

Step 4 — Create Access Applications + Policies

Access policies define who can log in to each app, and you can reuse or edit them anytime. (Cloudflare Docs)

Common homelab policies:

• Allow only your email(s) (and optionally family/teammate emails)

• Require IdP login (Google/GitHub) + MFA (handled by your IdP)

• Separate policies per hostname (NAS stricter than others)

---

Practical examples (admin/NAS/WireGuard UI)

Example 1: Protect a NAS web UI

Risk: NAS panels are high-value targets.

Suggested Access policy:

• Allow: only your email(s)

• Require MFA via IdP

• Optional: block unknown countries / add additional checks (if you use those features)

Result:

• NAS stays on LAN

• No ports exposed

• Only authenticated identities can reach it (Cloudflare)

Example 2: Protect a WireGuard UI / admin dashboard

Risk: This is basically your network keys and routing control.

Suggested approach:

• Put wg.example.com behind Access

• Keep the actual WireGuard UDP port usage separate (WireGuard itself may still need its own connectivity depending on your deployment; the “UI” is what you protect here)

Example 3: Protect SSH without managing long-lived keys

Cloudflare has a documented “SSH with Access” approach that replaces long-lived SSH keys with ephemeral SSH certificates, improving operational security. (Cloudflare Docs)

This is especially nice for homelabs where you don’t want to babysit SSH key sprawl.

---

Don’t forget non-human access (automation)

Sometimes you want a script or webhook to reach an internal service without a human login. Access supports Service Auth rules like service tokens or mutual TLS, which don’t require an IdP login flow. (Cloudflare Docs)

Use this carefully:

• Scope tokens per app

• Rotate them

• Log and alert on unexpected usage

---

Best practices for a small lab

• Keep origins private: bind admin services to LAN only; rely on Tunnel as the only ingress.

• One hostname per app: makes policies and auditing clean.

• Principle of least privilege: NAS and admin tools should allow only a tiny set of identities.

• Separate “public-ish” and “admin-only”: even within the lab, treat admin UIs as critical.

• Know your outbound requirements: ensure outbound 7844 works for cloudflared. (Cloudflare Docs)