Selfhosted

Your setup is close — the missing piece is usually that the GL.iNet router needs to actually route LAN clients' traffic into the Netbird tunnel, which Netbird alone doesn't do: Netbird creates the tunnel interface on the router, but clients behind it don't enter that tunnel automatically.

Two things to check:

1. Masquerade into the Netbird interface. SSH into the GL.iNet and make sure LAN traffic is NATed into wt0 (Netbird's interface):

   iptables -t nat -A POSTROUTING -o wt0 -j MASQUERADE
   

   Without that, replies from Jellyfin head back to the router itself instead of the client, and the connection dies silently. GL.iNet firmware sometimes intercepts this with its own client-management rules, so verify with a client-side test, not just the config screen.

2. Don't make the router a routing peer unless it needs to be. Your resource is a single IP (Jellyfin's Netbird IP), so group-based access control should suffice once traffic reaches wt0. Routing peers are for distributing whole subnet routes — and since routes are deprecated in favor of Networks, mixing the two models is exactly why this config gets confusing.

Quick test order that isolates the failure:

• From the router itself, ping Jellyfin's Netbird IP (tests tunnel + ACL).
• From a client behind the GL.iNet, try the same (tests forwarding/masquerade).
• If router→peer works but client→peer doesn't, it's the NAT/forwarding rule, not your Netbird Networks config.

Also double-check the access-control direction: the group on the client side (router) needs to be granted access to the resource — having Jellyfin in a group alone doesn't create the permission.