Covers 0.0.0.0/0 route creation, opt-in client-side selection (different
from subnet routes which auto-apply), and the extra trust exposure when
routing through a third-party VPS.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Document two lessons from the RTSP-camera-via-subnet-route diagnosis:
1. Existing NetBird clients don't automatically re-apply new route
config; daemons stuck in old state need explicit restart per
platform (launchctl kickstart / App reconnect / compose restart).
Shows up as 'Networks: -' on status output and no entry in the
system routing table.
2. Some iOS apps (notably certain RTSP players) don't use the system
VPN route and bypass NetBird entirely even when route is
correctly installed. Safari test distinguishes 'route broken'
from 'app doesn't respect VPN'.
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.
