New WireGuard based OpenWrt VPN implementation: unetd


I've made a new WireGuard based VPN implementation called unetd. My goal was to make it as easy as possible to link up multiple OpenWrt based routers (or Linux servers) and provide a fully-meshed VPN (all peers talk directly to each other) that can properly deal with NAT inbetween. It also supports automatically creating a VXLAN tunnel (if requested) and properly deals with issues from reduced MTU.
You can find an overview and documentation here:
It also provides some example commands which show that it's possible to create a new VPN two routers in 5 commands securely without having to worry about generating and distributing keys.
It automatically exchanges endpoint information and distributes VPN config updates between all member nodes.
Since it uses WireGuard, you can expect it to have really good performance.
At the moment it needs at least one of the hosts to be reachable via public IP, but I'm working on removing that limitation by using a DHT for node discovery.

It's still fairly new and only in OpenWrt master so far, but it should be easy to backport to 22.03.

If you're already using WireGuard, OpenVPN or some other VPN implementation, I'd be very interested to hear if unetd would cover your use cases as well, or if there is something missing that should be added.


thanks @nbd

a function of the hybrid vpn of netduma allows to rotate the ports like that to its vpn to establish the connection to server

is it possible to do it with this one ? thanks

Capture d’écran 2022-09-02 à 06.24.38

with openvpn i'm use files

At the moment, rotating ports is not supported. What’s the use case for it?

I use it to connect to game servers I send you the video link only with netduma

with OpenWrt the localization is well truncated but the game doesn't connect to the servers here is the link

in openvpn I have the start in red that engages,

I can make all vpn work in principle but this vpn not

video at 1"30

FYI: What you described and what netduma labels as hybrid vpn is easily achieved with vpn policy routing in OpenWrt

1 Like

yes thanks hudra

i has test yesterday

but I think I'm going about this the wrong way, so I'm giving up for today too

have you played with tailscale and headscale?

1 Like

No, but I’ve taken a closer look at it for inspiration.


Yes, I’ve studied both when designing unetd. NAT traversal, including double NAT is working fine with unetd, as long as one node in the network is publicly reachable. I’ve decided against implementing DERP, because I wanted to avoid relying on any centralized service.

1 Like

One suggestion:
Could the unet-cli have a selective dependency for unetd?
That would enable the user to just define unet-cli in his .config recipe (or menuconfig) and the underlying unetd would get also selected.

Currently it is a hard dependency:

  define Package/unet-cli
     DEPENDS:=unetd +ucode +ucode-mod-fs
1 Like

There are two "pulic" typos in the help texts of unet-tool:

root@router4:~# unet-tool
Usage: unet-tool [command|options] [<file>]
        -S                      Sign file
        -V                      Verify file
        -P                      Get pulic signing key from secret key
        -H                      Get pulic host key from secret key
1 Like

publicly reachable nodes are becoming ever more scarce, and derp a decent fallback. openwrt could run their own derp servers much like y'all run your own ntp servers.

As I said earlier, I'm already looking into getting rid of the need for nodes with public addresses by implementing DHT support. This would still allow direct connections over double NAT without going through another tunnel server and without introducing a dependency on a centralized (or self-hosted) service.


@hnyman thanks, I will fix both the typos and the package dependency.

Amazing work !! Theres a huge need for this. First prize would be optionally being able to layer a GRE/EOIP implementation over the wireguard tunnel natively as well, so fully transparent 1500mtu bridge can be obtained over <1500 mtu WAN-to-wan links (eg PPPoE where it's typically 1492 or lower), without needing to configure separate IP address for wg tunnel and eoip peers/interface

I'm curious. How is GRE/EOIP more transparent with 1500 MTU bridge than what unetd is setting up with VXLAN right now?

I made a small LuCI proto handler enabling seeing the traffic stats:


Just a quick update: I pushed a new version of unetd, which now supports DHT based peer discovery, even through double-NAT. The DHT code is in an extra package 'unet-dht', and I've extended the documentation with some notes on how to use it.


I think this work would be a good candidate for this grant program: - cfp closes oct 1.

1 Like