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-10

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 resolv.conf locked to 1.1.1.1¶

What: /etc/resolv.conf on edge-gateway points to 1.1.1.1 and 1.0.0.1 instead of the router (192.168.0.1), and is locked with chattr +i.

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 and locking the file prevents both the rate-limit and Proxmox from reverting the change on reboot.

Trade-off: DNS queries now 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 was added to the firewall to allow this.

Revisit when: If you want to tighten the firewall back to router-only DNS, remove the chattr +i, restore 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.

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.