Post by @tapdattl@lemmy.world

2026-10-18 05:44 UTC

Help with Netbird Networks access to home resources I have a GLInet travel router that is a peer connected to my Netbird network, I’d like to have any client that connects to my router to have access to the peers the travel router has access to, but still be able to access the regular internet that is being passed through by my router. Is this possible? Ultimately I’m trying to get the TV at my girlfriend’s place to be able to access my Jellyfin instance over Netbird. According to the Netbird documentation, exit nodes and routes are depricated and should not be used, but I’m struggling hard with getting it to work with Networks. I’ve created a group with my GLInet router, my Jellyfin instance, and my home server (Which hosts Jellyfin) all in the group called “Travel”. I’ve created a Network called “Home” in Netbird Within the “Home” network I’ve created a resource called “Jellyfin” with the IP address set to it’s Netbird IP address, and an access control group where all members of the “Travel” group have access to all ports of the “Jellyfin” resource. I’ve created two routing peers within the network, one is the GLInet router and the other is my home server. Both of these are Netbird peers with Netbird installed on them. I am very confused overall, and could use a hand if anyone wanted to walk me through what I’m doing wrong.

Replies (1)

@miaowoo_lw@lemmy.world 2026-10-18 06:01

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: 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. 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.

Open ##5239991