Dashboard's 'SSH Access is disabled' warning confuses new users
who can clearly ssh into peers just fine. These are two different
systems: Dashboard's SSH Access is NetBird's own in-daemon SSH
tunnel server (accessed via Dashboard Connect button or
'netbird ssh'), while the regular ssh command uses the target
machine's OpenSSH running on port 22 and has nothing to do with
the Dashboard SSH toggle.
Home-lab use cases rarely need the NetBird built-in SSH — regular
OpenSSH over the NetBird overlay is sufficient. Doc explains when
you would actually want it (browser-based terminal from Dashboard,
credential offloading to NetBird identity, etc) and how to enable
if needed.
CT100 now routes 192.168.42.0/24 for the personal group, letting
Mac/iPhone reach LAN devices that don't run NetBird (OpenWrt,
Proxmox nodes, NAS, printers, cameras, etc).
- IP forwarding persisted via /etc/sysctl.d/99-netbird-route.conf
- Route created with masquerade=true, metric=9999
- access_control_groups restricts who can use the route
- Chose CT100 over CT124 to avoid the Tailscale kernel-mode
iptables collision documented in peer-deployment-ops.md
Doc covers: concept, API + UI creation, verification, troubleshooting
(forwarding, masquerade, LXC caveats, Tailscale interference),
and security considerations for narrowing the route CIDR.
Explain what Groups are in NetBird, the four places they surface
(policies, setup keys auto_groups, network routes, DNS), and a
concrete segmentation plan for the current mesh:
- servers group: CT100, CT101
- personal group: mbp-13-pro, iphone-15-pro
- Replace default All->All with least-privilege policies
(personal->servers, servers<->servers)
Includes UI and API workflows, a phased migration plan, rollback
strategy, and how to wire auto_groups into setup keys for future
deployments.
Document the operational patterns established while adding CT100 and
CT101 as peers via Docker, plus incidental fixes:
- Docker compose template for headless peer containers
- One-off setup key naming convention and API creation
- Peer rename via API PUT (works, unlike setup keys)
- Mac daemon kickstart via 'sudo launchctl kickstart -k system/netbird'
(service name is 'netbird', not 'io.netbird.client')
- UPNP auto-port-mapping discovery in NetBird client
- CT100 PermitRootLogin drop-in override (first-match-wins sshd quirk)
Document the 'Force relay connection' switch that silently disables
ICE gathering on iOS NetBird (and similar on macOS), which was the
real cause of all peers showing Connection type: Relayed despite
STUN being correctly configured.
Also document bufferbloat diagnosis via macOS networkQuality, which
was a red herring during the P2P investigation (large RTT spikes
were the WiFi/ISP, not NetBird).
Document Setup Keys concept vs SSO, PAT creation and usage, and the
workaround for renaming a setup key — the API silently ignores the
name field on PUT, so the fix is to UPDATE store.db directly and
restart netbird-server.
Document the fix for 'server closed the stream without sending trailers'
gRPC error when exposing NetBird via Nginx Proxy Manager:
- NPM proxy_host advanced_config with grpc_pass for Signal/Management
- Caddy h2c listener enabled via 'protocols h1 h2 h2c'
