Cloudflare Access Setup for Protected Sections#

What Was Established#

• Methodology for securing specific website paths or subdomains using Cloudflare Zero Trust Access.
• Authentication bypasses traditional .htaccess or server-side auth; Cloudflare handles it at the edge.
• Prerequisites: Cloudflare domain, Paid/Zero Trust plan (free tier supports up to 50 users).

Key Decisions#

• Identity Provider Choice: One-time PIN (OTP) recommended for simplicity and shared access without managing user lists. Alternatives include Google/GitHub or specific email allowlists.
• Policy Structure: “Allow Authenticated Users” policy with wildcard email matching (*) or specific domain matching (*@domain.com).
• Edge-Based Protection: No server-side configuration changes required; protection occurs before requests hit the origin server.

Current Configuration#

• Pattern established but not yet applied to specific homelab services.
• Relevant to Nginx Proxy Manager (192.168.1.222) or Proxmox (192.168.1.69) admin interfaces if routed through Cloudflare.

Historical Notes#

• Conversation date: 2025-11-24.
• Focuses on the Cloudflare Zero Trust dashboard workflow for self-hosted applications.
• No changes to existing Cloudflare SSL/DNS integration patterns.

Open Questions#

• Which homelab services will leverage Cloudflare Access for admin/protected paths?
• Will static IP bypass policies be implemented for homelab admin access?

Related Pages#

• Cloudflare Integration: SSL & DNS
• Hinterflix Help Site - Cloudflare Deployment
• Proxy Management & Cloudflare Tunnels

Sources#

• ingested/chats/117-Setting Up Cloudflare Access for Website Protection.md
• DeepSeek conversation: 2025-11-24 (Setting Up Cloudflare Access for Website Protection)

Hinterflix Help Site - Cloudflare Deployment#

What Was Established#

The Hinterflix help site (help.hinterflix.com) is deployed as a static Hugo site on Cloudflare Workers. The domain is managed within the same Cloudflare account.

Key Decisions#

• Hosting: Cloudflare Workers Pages (static hosting).
• Domain: help.hinterflix.com (root subdomain of hinterflix.com).
• DNS: CNAME record pointing to the Cloudflare Workers subdomain (*.workers.dev). Proxy status set to Proxied (orange cloud).
• SSL/TLS: Automatically provisioned by Cloudflare. “Always Use HTTPS” enabled in SSL/TLS settings.

Configuration Steps#

1. Cloudflare DNS Setup:

Hugo Deployment to Cloudflare Pages - Troubleshooting#

What Was Established#

Patterns for resolving missing assets (favicons, CSS, styling) and build failures when deploying Hugo-generated static sites to Cloudflare Pages.

Key Decisions#

• Build Configuration: Set build command to hugo, output directory to public, and explicitly match the local Hugo version in Cloudflare Pages settings.
• Static Asset Placement: Ensure all static files (e.g., favicon.ico, CSS) reside in the static/ directory root or theme-specific static folders.
• Rebuild Enforcement: Use hugo --cleanDestinationDir or manually remove the public/ directory to force Hugo to regenerate all assets and detect changes.
• Cache Management: Clear both Cloudflare Pages deployment cache and browser cache to prevent stale asset delivery.
• Verification Workflow: Validate locally via hugo server, inspect the generated public/ directory, review Cloudflare deployment logs, and confirm full Git commits.

Current Configuration#

• Build Command: hugo
• Output Directory: public
• Static Directory: static/
• Config File: config.toml / config.yaml (verify baseURL matches target domain)

Obsidian Integration for Hugo Date Format#

Hugo expects ISO 8601 dates with timezone offset: 2025-11-22T23:11:12-05:00

Proxy Management & Cloudflare Tunnels#

What Was Established#

There are multiple layers of proxying available in the homelab, ranging from edge protection (Cloudflare) to local routing (OPNsense/Nginx Proxy Manager).

Nginx Proxy Manager (NPM) Troubleshooting#

• Redirect Loops & Timeouts: Often caused by misconfigured upstream servers or aggressive timeout settings in NPM’s web UI. Resolving a redirect loop may expose underlying connectivity issues that manifest as timeouts.
• Docker Compose Pattern: NPM is deployed with network_mode: host to bind directly to host ports (80, 443, 81), bypassing Docker’s NAT for direct host network access.
• Verification Steps:
  1. Check container health: docker ps | grep nginx-proxy-manager (ensure healthy status).
  2. Verify port bindings: sudo netstat -tulpn | grep :80 / :443 (requires net-tools package).
  3. Inspect NPM Web UI: Access at http://<host-ip>:81 to review Proxy Host settings, specifically timeout values and upstream server addresses.
• Port Conflicts: Use netstat to identify which container owns a specific port (e.g., docker-proxy vs nginx: master). In this setup, port 8000 was observed bound to docker-proxy, indicating another service in the compose stack.
• Co-located Services: The same Docker Compose stack hosts cloudflare-ddns (for dynamic IP updates) and netbird (for mesh networking), requiring careful port management to avoid conflicts.

Key Decisions#

• Use network_mode: host for NPM to simplify port mapping and ensure direct access to host network interfaces.
• Rely on net-tools (netstat) for quick port binding verification in host-networked Docker containers.

Current Configuration#

• Docker Host: iluvatar@proxy (192.168.1.208)
• NPM Web UI: http://192.168.1.208:81
• Ports: 80 (HTTP), 443 (HTTPS), 81 (NPM Admin UI)

Historical Notes#

• Troubleshooting session from 2025-11-17 resolved a redirect loop that subsequently turned into a timeout issue.
• net-tools installation was required to diagnose port bindings on the host.

Open Questions#

• Specific timeout values configured in NPM for upstream services.
• Whether netbird or cloudflare-ddns requires dedicated port exposure or can share the host network.

Related Pages#

• Cloudflare Integration: SSL & DNS
• OPNsense DMZ Firewall Rules for IoT
• Docker Host Configuration

Uptime Kuma - Configuration & Integrations

Cloudflare Integration: SSL & DNS#

What Was Established#

Methodology for securing OPNsense and Proxmox web interfaces using Cloudflare’s Origin CA certificates and protecting the WAN via Cloudflare-specific firewall rules.

Key Decisions#

• SSL Mode: Cloudflare SSL/TLS setting must be set to Full (Strict).
• Security Pattern: Use Cloudflare IP Aliases on OPNsense to restrict WAN HTTPS (Port 443) access exclusively to Cloudflare’s IP ranges.
• DNS Strategy: Use A records with Proxy (Orange Cloud) enabled for web services to leverage DDoS protection.

Current Configuration#

Cloudflare Origin SSL (OPNsense)#

1. Generate Cert: In Cloudflare, go to SSL/TLS → Origin Server and create a certificate for the domain.
2. Import to OPNsense:
   • System → Trust → Certificates → Import existing Certificate.
   • Paste PEM (Cert) and Private Key.
3. Assign to WebUI:
   • System → Settings → Administration → Set SSL Certificate to the imported Cloudflare cert.
   • Restart WebGUI: configctl webgui restart.

WAN Hardening (OPNsense)#

1. Create Alias: Firewall → Aliases → URL Table Alias.
   • Name: Cloudflare_IPs.
   • URL: https://www.cloudflare.com/ips-v4.
2. Firewall Rule: Firewall → Rules → WAN.
   • Action: Pass.
   • Source: Cloudflare_IPs.
   • Destination Port: 443.
3. Block Rule: Add a block rule for port 443 from all other sources at the bottom of the WAN list.

Historical Notes#

Note: If the browser shows “Not Secure” after import, ensure the Cloudflare Origin CA Root Certificate is also imported into OPNsense System → Trust → Authorities.