Moved state file from /root/.config/netbird/state.json to /var/lib/netbird/state.json to reduce storage wear. The dangling file /root/.config/netbird/state.json can be removed. If any configuration was lost, let me know.
After a long time, netbird has been updated to 0.66.2 in OpenWrt 25.12. It will be available for everyone in a few hours or days. Highlights:
Support for exposing a local HTTP service from the CLI with netbird expose. Rosenpass or pre-shared keys are currently incompatible with the reverse proxy feature.
Thank you for maintaining the netbird package in openwrt.
netbird v0.66.3 is out.
They seem to be releasing many updates in a short span of time, but haven't yet merged the pull request https://github.com/netbirdio/netbird/pull/5447 that fixes compilation with golang 1.26.x .
Yeah, netbird is a pain, but you don't need to worry about every single version. The NetBird repository is a monorepo containing several components (management, relay, infra, etc.) and supporting multiple architectures (iOS, Windows, BSD, etc.). Some updates are irrelevant (or not worth the effort) for OpenWrt, and it's impossible for me to follow every single change, fortunately I have @egc to help.
While I've been maintaining netbird, I've noticed a pattern: launch a new feature, then several follow-up releases to fix and polish it, then repeat. This time it took me months to update netbird and only 3 new features reached end users, 2 of which were irrelevant until recently because they weren't supported by the NetBird cloud (I don't think we have a lot of self-hosters). Yep, there were some bug fixes in the meantime, but nothing critical.
I also try to follow a stable approach of "don't break things" rather than pushing new features into OpenWrt stable.
@egc thanks for testing and the ping, sorry for the loooong delay. I’ve been a bit busy recently, I’ll try to update to the latest version this week. I know this already took too long.
Edit: I see you opened a PR for the update, very good. I need to test whether I can build netbird for a 16mb target (this package is getting too fat) and review the changelogs, since you've already tested.
I’ve made luci-app-netbird, a LuCI app to manage the NetBird client from the web interface on OpenWrt/ImmortalWrt.
It supports common operations like connect/disconnect, self-hosted servers, full netbird up settings (WireGuard, routes, DNS, SSH, IPv6, Rosenpass, etc.), peer status, and live logs.
It can also automatically create the NetBird firewall zone and handle LAN ↔ NetBird forwarding with one click.
Currently it only supports setup key login (my main use case). If there’s strong community interest, I’m happy to add other authentication methods later.
For the client binary, it prioritizes the official NetBird release for amd64, arm64, 386, and armv6, with fallback to the OpenWrt package feed for other architectures. The OpenWrt feed fallback supports more architectures than the official NetBird releases. I mainly test on x86_64 in Proxmox, so feedback and contributions are very welcome.
I'm planning to use NetBird to access my devices, especially when I'm at work, where UDP traffic is blocked.
Previously, I was using Tailscale. It worked well until I started downloading a large file. After that, my workplace firewall's DPI (Deep Packet Inspection) detected the connection and blocked Tailscale.
Currently, I'm using an Oracle Cloud VPS running VLESS as a middle relay. My home router is configured as a WireGuard server, and my work router connects to the VPS using VLESS as a client. So far, the firewall hasn't detected it as a VPN connection.
My question is: Can NetBird bypass DPI, or does it behave similarly to Tailscale in environments where DPI is used? Has anyone used NetBird on a network that blocks VPN traffic through DPI?
AFAIK, both netbird and tailscale use wireguard on the lower level. Which can be very easily detected, not even special DPI required. Not having used VLESS (need to try it, though), as a more lightweigth alternative you might try a socks5 proxy (i.e. hev-socks5-tproxy on openwrt), using tcp on port 443. Has no cipher, but in the times of https or DoH this might not be necessary.
Personal advice: don't be surprised if your employer terminates your contract without further notice. You would be lucky if they ask you what your doing upfront....
Almost everyone at my workplace creates a hotspot from their work PC, connects their phone to it, and then turns on a VPN like WARP or Proton to access websites that are blocked.
I just took it one step further because I’m a bit of an OpenWrt enthusiast. Since routers don’t currently have the same convenient functionality that the Proton or WARP mobile apps provide, I chose to use VLESS instead. That way, I don’t have to keep checking whether the VPN is connected or reconnect it manually every time—it just works automatically in the background.
Another reason is that I don’t have a public WAN IP at home, so I had to use a VPS as an intermediate relay. This setup routes all of my traffic through my home router, which also means my banking apps work normally without any issues. If I were using WARP or Proton directly on my phone, I’d have to disconnect the VPN every time I wanted to use a banking app, which becomes pretty inconvenient.
One step further might be exactly the one step your employer may no longer ignore. _bernd is spot on, your approach is putting your job on the line, technically it's 'always' explicitly against the rules of your employer's IT, but they might be willing to look the other way - the further you push it, (strong, stationary, rogue AP) the more you force their hand to make a stance.
Since routers don’t currently have the same convenient functionality that the Proton or WARP mobile apps provide, I chose to use VLESS instead. That way, I don’t have to keep checking whether the VPN is connected or reconnect it manually every time—it just works automatically in the background.