Known Issues & Decisions¶

Architectural decisions and known issues documented during Phase 1 implementation. Reference this before making changes to avoid re-litigating settled decisions.

Last updated: 2026-04-11

Decisions¶

D1 — cloudflared forced to HTTP/2 over IPv4¶

What: compose command includes --edge-ip-version 4 --protocol http2

Why: During initial tunnel setup, cloudflared crash-looped when using QUIC (UDP) and IPv6 edge addresses. Forcing IPv4 + HTTP/2 over TCP resolved the issue immediately.

Revisit when: You want slightly better tunnel performance. Remove the flags, restart cloudflared, and monitor for 5 minutes. If it stays healthy on QUIC, keep it. If it crash-loops, revert.

D2 — CT 101 DNS set to 1.1.1.1 via Proxmox config¶

What: CT 101's DNS is set to 1.1.1.1 at the Proxmox level (pct set 101 --nameserver 1.1.1.1), not inside the container. Proxmox writes /etc/resolv.conf on every container start.

Why: cloudflared crash-looped ~100 times in quick succession, flooding the router with DNS queries. The router rate-limited UDP/53 from the LXC's IP. Switching to public DNS prevents the rate-limit issue.

History: Originally the fix used chattr +i to lock /etc/resolv.conf inside the container. This broke on 2026-04-11 — Proxmox overwrote the file on a container restart, reverting DNS to the router (192.168.0.1), which caused cloudflared to crash-loop with "there are no free edge addresses left to resolve to". The chattr +i approach also requires the linux_immutable LXC capability which is not available by default (see I4). The Proxmox-native --nameserver approach is simpler and survives reboots without any in-container workarounds.

Trade-off: DNS queries exit the LAN to Cloudflare instead of resolving locally. Adds ~3ms latency to DNS lookups. The OUT ACCEPT -p udp -dport 53 (any destination) rule in 101.fw allows this.

Revisit when: If you want to tighten the firewall back to router-only DNS, run pct set 101 --nameserver 192.168.0.1 and delete the public DNS fallback rules from 101.fw. Only do this if the router DNS has been stable.

D3 — Tailscale bypasses Proxmox firewall¶

What: Tailscale traffic enters the host via the ts-input iptables chain, which is inserted above PVEFW-INPUT. Proxmox firewall rules never see Tailscale traffic.

Why: This is by design — Tailscale's ts-input chain is injected at a higher priority than Proxmox's firewall. Any device on your Tailnet can reach the Proxmox WebUI on port 8006.

Accepted risk: We're trusting the Tailscale mesh. If your Tailnet is compromised, the attacker has full access to Proxmox. This is acceptable for a homelab because: - Tailscale requires device authentication - The mesh is end-to-end encrypted (WireGuard) - Adding ACLs in the Tailscale admin console provides equivalent control

Mitigation (optional, not implemented): Configure Tailscale ACLs in the admin console to restrict which devices can reach 100.89.70.63:8006.

D4 — PVEFW-0-management-v4 allows LAN-wide SSH¶

What: The default Proxmox management IP set contains 192.168.0.0/24, allowing SSH (port 22), VNC (5900-5999), SPICE (3128), and serial console (60000-60050) from any LAN device to the Proxmox host.

Why: Proxmox populates this automatically based on the host's subnet. The explicit DROP rule for port 8006 fires before the management set's RETURN, so the WebUI is still protected. But SSH from the full LAN is allowed.

Accepted risk: In a trusted home LAN, SSH from any device is not a significant threat. The root password and/or SSH keys are the real access control.

Mitigation (optional, not implemented): Edit the management IP set in Datacenter > Firewall > IP Sets to contain only 192.168.0.16/32 (admin desktop) and the Tailscale IPs.

D5 — n8n has no outbound port 80¶

What: CT 102 firewall allows outbound TCP/443 but not TCP/80. n8n can only make HTTPS API calls.

Why: Modern APIs are HTTPS-only. Allowing port 80 would be an unnecessary hole that could be exploited for data exfiltration or DNS rebinding attacks over HTTP.

Revisit when: A specific n8n integration requires HTTP. Add a targeted rule for that exact destination IP and port rather than a wildcard OUT ACCEPT -p tcp -dport 80.

D6 — No OPNsense/pfSense — staying with consumer router¶

What: Decided not to replace the home router with a dedicated firewall appliance.

Why: Proxmox micro-segmentation (per-CT firewall rules with IP sets) provides equivalent lateral movement prevention. The consumer router only needs to route packets and serve DHCP/DNS. Adding OPNsense would increase complexity without meaningful security gain for Phase 1.

Revisit when: Phase 2+ requires advanced networking (VLANs, WAN failover, IDS/IPS, per-device policies). At that point the firewall rules transfer 1:1 to OPNsense — same logic, better hardware.

Known Issues¶

I1 — cloudflared ICMP proxy disabled¶

Log line: WRN ICMP proxy feature is disabled error="cannot create ICMPv4 proxy: Group ID 65532 is not between ping group 65534 to 65534"

Impact: None. The ICMP proxy is a cloudflared feature for proxying ping through the tunnel. Not needed for HTTP tunnelling. Cosmetic warning only.

I2 — cfd-features.argotunnel.com DNS "failure"¶

Log line: ERR Failed to fetch features, default to disable error="lookup cfd-features.argotunnel.com on ..."

Impact: None. This hostname intentionally has no A record. cloudflared uses it as a feature-flag probe and gracefully falls back to defaults. Cosmetic error on every start.

D7 — Tailscale subnet routing enabled¶

What: Proxmox host advertises 192.168.0.0/24 as a Tailscale subnet route (tailscale set --advertise-routes=192.168.0.0/24), approved in the Tailscale admin console.

Why: Enables remote access to LAN devices (router admin panel, Intel AMT/MeshCommander) from any Tailscale device without being on the home network.

Security model: Same trust boundary as D3 (Tailscale bypasses Proxmox firewall). Subnet routing extends this to the full LAN. Only authenticated Tailnet devices can use the route. WireGuard encrypted end-to-end.

Risk: If a Tailscale device is compromised, the attacker can reach all LAN devices. Mitigation: use Tailscale ACLs to restrict subnet route access to admin-tagged devices only.

Revisit when: Adding more people to the Tailnet — restrict subnet route access via ACLs before giving non-admin users Tailscale access.

I4 — chattr +i does not work inside LXC containers¶

What: chattr +i fails with Operation not permitted in unprivileged LXC containers. This was discovered on 2026-04-11 when attempting to re-lock /etc/resolv.conf on CT 101.

Why: The chattr +i command requires the CAP_LINUX_IMMUTABLE capability, which is not granted to LXC containers by default. Proxmox does not support adding it via lxc.cap.add in the container config (pct reboot fails with parse error).

Lesson: Do not rely on chattr for persistence inside LXC containers. Use Proxmox-level config instead (e.g., pct set <vmid> --nameserver for DNS). See D2 for the DNS-specific fix.

I3 — Cloudflare DNS migration briefly broke telegram.exzentcg.com¶

What happened: When NS was switched from Hostinger to Cloudflare, the Cloudflare zone was missing several records. telegram.exzentcg.com was unreachable for users whose DNS resolvers had already picked up the new NS.

Root cause: Cloudflare's auto-import missed records. NS switch happened before manual verification.

Resolution: Missing records were added manually. Going forward, always diff the full record set before switching NS.

Lesson: Never switch nameservers until the new zone is a verified complete mirror of the old one.