A resilient backup communication path to home infrastructure that operates independently of DNS, Cloudflare, and standard IP routing. Built after a Cloudflare global outage in November 2025 exposed a single point of failure in all remote access methods.

The Problem

Every remote access method I had — Proxmox management, service dashboards, SSH — routed through Cloudflare DNS. When Cloudflare went down globally, everything stopped resolving simultaneously. No fallback existed.

The solution needed to be completely independent: no DNS lookups, no fixed IP addresses, no dependency on any third-party infrastructure.

What Reticulum Is

Reticulum is a cryptography-based networking stack designed for resilience. Unlike TCP/IP, it doesn’t require fixed addresses — devices are identified by cryptographic hashes that work regardless of their physical location or network path.

It can route traffic over any medium: internet TCP, LoRa radio, packet radio, or I2P — automatically selecting the best available path and failing over transparently.

Architecture

Windows Client
    │
    ├─ Path 1: TCP via WireGuard VPN (fast — used when VPN active)
    │
    └─ Path 2: I2P anonymous overlay network (slow but works anywhere)
                        │
                Reticulum gateway (homelab LXC)
                        │
                rnsh → encrypted remote shell

The client is configured with both paths. Reticulum automatically uses TCP when the WireGuard VPN is active (fast, ~100Mbps) and falls back to I2P when it isn’t (slow, ~100KB/s, but reachable from anywhere with no configuration changes).

Technical Highlights

  • Location independence — devices are addressed by cryptographic identity, not IP. The connection works regardless of what network either end is on.
  • Automatic path selection — Reticulum tries the fastest available interface first and fails over silently. No manual switching.
  • I2P for anonymity and resilience — even if the home IP changes or ISP blocks connections, I2P routes around the problem through its distributed overlay network.
  • Transport encryption — all Reticulum traffic is encrypted end-to-end using elliptic curve cryptography, independent of TLS or any PKI.
  • Zero DNS dependency — once you have a peer’s Reticulum address (a cryptographic hash), you never need DNS again.

Challenges Overcome

  • I2P tunnel build time — I2P takes 2-5 minutes to establish tunnels after starting. Starting Reticulum before I2P is ready causes silent failures. Solved with ordered systemd service dependencies and startup delays.
  • Windows client limitations — rnsh (Reticulum shell) has reliability issues on Windows due to Python multiprocessing differences. Worked around using WSL for shell access and the Sideband GUI app for other operations.
  • Path 2 performance expectations — I2P is designed for anonymity, not speed. Bandwidth is ~50-500 kbps — suitable for shell access and small file transfers, not streaming or large downloads.

Tech Stack

  • Reticulum Network Stack (Python)
  • i2pd (I2P daemon — C++ implementation)
  • rnsh (Reticulum Network Shell)
  • Proxmox LXC (Debian 12)
  • WireGuard VPN (primary path)
  • Windows client + WSL

Current Status

Container is intentionally stopped when not needed — started on demand as an emergency access method. Successfully tested: shell access to homelab from a network with no WireGuard connectivity, routed entirely through I2P.

What I Learned

This project taught me that resilience engineering means thinking about failure modes you haven’t experienced yet. The Cloudflare outage only lasted a few hours — but it revealed that my entire remote access stack had a single dependency I hadn’t noticed. Reticulum’s approach of using cryptographic identities instead of addresses is a fundamentally different mental model from TCP/IP, and genuinely useful for building infrastructure that survives partial internet failures.

Part of an ongoing homelab infrastructure resilience project.