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)

SSH Host Key Management & Troubleshooting#

What Was Established#

Standard procedures for resolving SSH REMOTE HOST IDENTIFICATION HAS CHANGED warnings, which occur when a host’s SSH fingerprint differs from the locally stored known_hosts entry. This typically happens after a server reinstall, OS upgrade, or SSH key regeneration.

Key Decisions & Commands#

• Verify Legitimacy: Always confirm with a system administrator or check server logs if a key change is unexpected, as it could indicate a man-in-the-middle attack.
• Remove Stale Keys: Use ssh-keygen -R <hostname> to safely remove the outdated entry from ~/.ssh/known_hosts.
• Targeted Removal: If the error specifies a line number (e.g., line 9), you can remove it via sed -i '' '9d' ~/.ssh/known_hosts or manually edit the file.
• Pre-populate Keys: In managed environments, use ssh-keyscan <host> >> ~/.ssh/known_hosts to automate key acceptance.
• Security Best Practice: Prefer certificate-based authentication in sensitive environments to bypass host key checking entirely.

Current Configuration#

• Host Encountered: proxy (192.168.1.222, Nginx Proxy Manager)
• User Context: Commands executed from macOS (NK---Galadriel) as user natekelley.
• Fingerprint Example: SHA256:k5j8V356rpQXapznIs12MeBEWHfZYwfeicXdNNWFyOI (ED25519)

Historical Notes#

• Initial troubleshooting documented on 2025-11-17. The proxy host likely had its underlying VM/container rebuilt or its SSH configuration reset, triggering the warning.

Open Questions#

• Should SSH host keys be version-controlled or managed via a configuration management tool (e.g., Ansible) to prevent future mismatches?

Related Pages#

• Proxy Management & Cloudflare Tunnels
• Troubleshooting Network Interface Changes

Sources#

• ingested/chats/111-Check and Install Git, Go, Dart Sass on Ubuntu.md
• ingested/chats/104-SSH Host Key Change Warning and Fix.md
• Historical DeepSeek conversation: SSH Host Key Change Warning and Fix (2025-11-17)

OPNsense DMZ Firewall Rules for IoT#

What Was Established#

A structured firewall rule set for isolating IoT devices in a DMZ zone. The rules enforce a “high-to-low trust” flow, ensuring IoT devices can reach the internet for cloud services while preventing them from initiating connections to the trusted LAN. This pattern is critical for preventing lateral movement from compromised IoT devices.

Key Decisions#

• Explicit Allow / Implicit Deny: Only allow necessary outbound traffic (HTTP/HTTPS, DNS, NTP) from DMZ to WAN.
• Strict Containment: Explicitly block all DMZ-initiated traffic to the LAN zone.
• Controlled LAN Access: Default deny for LAN-to-DMZ, with specific allow rules only for administration or required services.
• WAN Isolation: Block all unsolicited inbound traffic from WAN to DMZ.

Current Configuration#

Note: The homelab currently uses VLANs (Gandalf 192.168.1.x, Mithrandir 192.168.2.x, Tharkûn 192.168.3.x, Rivendell 192.168.4.x) managed by a UniFi Express gateway (“Olorín”, 192.168.1.1). These OPNsense zone-based rules should be adapted to the homelab’s VLAN structure or applied to a dedicated IoT VLAN (e.g., 192.168.50.x).

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.