You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
NetBird as a first-class remote path, alongside Tailscale
#28615
T3 Code treats Tailscale as a first-class way to reach a machine: --tailscale-serve, t3 pair --tailscale, and a plain-http exemption for linked environments. NetBird gets none of this, though it fills the same role: a WireGuard mesh with a peer address and a DNS name for each machine. It also fits T3 Code's direct, self-hosted remote story well. It is open source (BSD client, AGPL server), and you can run the whole control plane yourself or use the hosted service.
Today, opening a T3 server over a NetBird address works fine, and the iOS app allows it since #10801. Linked environments refuse it, because peerOrigin only exempts loopback, *.ts.net and fd7a:115c:a1e0::/48 (#26840, #27678).
What first-class support could mean, smallest first:
Advertised routes: the server advertises its NetBird address next to its LAN and Tailscale ones, so Link and Add environment can offer it.
Pairing:t3 pair can print a NetBird-reachable pairing URL, as --tailscale does.
Docs: list NetBird next to Tailscale in the remote-access docs, including the reverse-proxy route for HTTPS.
Out of scope: trusting private ranges in general. A user-configured trusted-network setting would also cover NetBird, ZeroTier and plain WireGuard, but it's a broader policy choice.
Open question: NetBird's netstack mode has no OS interface, so traffic to 100.x could bypass the tunnel. Is "daemon reports Connected" enough, or does this need a reliable netstack signal first?
Would the maintainers accept this direction, starting with item 1?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
T3 Code treats Tailscale as a first-class way to reach a machine:
--tailscale-serve,t3 pair --tailscale, and a plain-http exemption for linked environments. NetBird gets none of this, though it fills the same role: a WireGuard mesh with a peer address and a DNS name for each machine. It also fits T3 Code's direct, self-hosted remote story well. It is open source (BSD client, AGPL server), and you can run the whole control plane yourself or use the hosted service.Today, opening a T3 server over a NetBird address works fine, and the iOS app allows it since #10801. Linked environments refuse it, because
peerOriginonly exempts loopback,*.ts.netandfd7a:115c:a1e0::/48(#26840, #27678).What first-class support could mean, smallest first:
100.64.0.0/10address only when the local NetBird daemon reports it as a connected peer, sharing one gate with the Tailscale check in fix(server): linking accepts a Tailscale machine's 100.x address #26475. This is siew24's proposal on Linked environments: can't link machines on a local network because pairing only produces http:// and + Link rejects http #26840. If the daemon is missing or disconnected, the link is refused, so the WARP and CGNAT reasoning behind fix(connect): Cloudflare and other VPN addresses no longer show as Tailscale #17158 still holds.t3 paircan print a NetBird-reachable pairing URL, as--tailscaledoes.Out of scope: trusting private ranges in general. A user-configured trusted-network setting would also cover NetBird, ZeroTier and plain WireGuard, but it's a broader policy choice.
Open question: NetBird's netstack mode has no OS interface, so traffic to
100.xcould bypass the tunnel. Is "daemon reports Connected" enough, or does this need a reliable netstack signal first?Would the maintainers accept this direction, starting with item 1?
All reactions