Pangolin was a single-VPS hub architecture — every packet routed through the VPS. That was fine for admin but meant latency compounded and a VPS outage killed remote access entirely. NetBird gives us:

• Direct P2P between peers whenever network conditions allow
• Relay fallback only when necessary
• Subnet routing — one peer on each LAN advertises the whole LAN to the mesh
• Zero public port exposure — no open ports on the home router required
• Clean client apps for every OS

To add more peers (iPad, MacBook, phone), invite from the dashboard or use a setup key.

Linux (Debian/Ubuntu):

curl -fsSL https://pkgs.netbird.io/install.sh | bash
netbird up --management-url https://api.netbird.io --hostname <peer-name>

You’ll get a one-time auth URL in the terminal — open it in a browser to authorize.

Or with a setup key (for headless provisioning):

netbird up --setup-key <KEY> --hostname <peer-name>

macOS / Windows / iOS / Android: download from netbird.io/download. Sign in with the same account.

Pi-hole on CT102 is registered as a NetBird nameserver, so mesh peers get local DNS automatically:

• *.edmd.me → 192.168.8.54 (Caddy)
• Short names (hpve, portainer, immich, etc.) → resolve directly
• *.netbird.cloud → resolved by NetBird client locally (peer names)

Peers appended netbird.cloud as a search domain, so typing just hpve in a browser reaches hpve.netbird.cloud (the hpve peer’s mesh address).

The hpve peer advertises 192.168.8.0/24 to the mesh. The fpve peer advertises 192.168.0.0/24. Any peer connected can reach any host on either LAN by its local IP address.

Routes are configured in the NetBird dashboard under Network Routes and must be selected on each peer (netbird routes select <route-id>).

NetBird tries paths in this order:

1. Direct P2P over IPv6 — fastest, no NAT issues. Requires IPv6 on both ends.
2. Direct P2P over IPv4 via STUN/ICE — works through most NATs, can fail with strict CGNAT (Starlink).
3. Relayed through NetBird relay servers — always works, adds 30-80ms latency.

Check which path is being used: netbird status --detail shows each peer’s connection_type as P2P or Relayed.

In an ideal home network, two improvements would help direct P2P:

• Enable IPv6 at both ends. Bypasses IPv4 NAT issues entirely.
• Port-forward UDP 51820 on the home router → 192.168.8.221 (hpve). Gives the home peer a stable public endpoint.

At our current home, neither is feasible — the ISP gives OPNsense a private WAN IP (192.168.254.65) behind their managed gateway. We can’t get IPv6 through the upstream gateway, and we can’t open inbound ports on the upstream we don’t control. Until the ISP service tier changes, peers fall back to STUN-punched UDP4 (which works for most paths) or relayed (small latency cost).

In practice this means: peers that are both on residential ISPs with reasonable NAT will reach each other directly via STUN; mobile peers on cellular often relay. Both are functional.