Re: Wireguard Plugin for NM

On Thu, 2018-02-15 at 16:07 +0100, Jason A. Donenfeld wrote:
Hi Thomas,

Upstream WireGuard here.

Hi Jason,

thanks for reaching out.

I still think, it would be great to have wireguard support in
NetworkManager not via a VPN plugin. But that is for another day.

I fully agree, and I'd be happy to work with you on doing this, if
you're interested. For this, you can either attempt to reuse the
systemd-networkd stuff, or roll it yourself, likely using some
derivative of this code:
. It doesn't look like you're using any of the systemd netlink
stuff now, so it may indeed be best to roll it yourself.

I've been suggesting to Max that he makes his plugin talk to the
kernel directly, because the current implementation of shelling out
wg-quick has numerous problems and so the current plugin shouldn't be
used as is. But hopefully it'll get there.

Are you interested in working on real non-plugin NetworkManager
integration? If so, maybe find me on freenode (I'm zx2c4), and we can

Yes, we are interested in that, but currently nobody did any work on
that (AFAIK). But once somebody picks it up, it should be doable

As wireguard support got added to networkd, I supposed the netlink API
is reasonably stable? We were still waiting until the kernel part is
merged upstream. But that is not a blocker, merely a reason for
wireguard support not having a sufficiently high priority to implement
it -- until now.

Looking forward for that,



PS: a few details that might help with implementation. 

I think it would be a better expirience if wireguard would by directly
supported by NetworkManager. The main reason for that is, that the VPN
API is not as powerful as it should be, so VPN plugins unfortunately
feel a bit alien. That should possibly be improved. But there is really
no strong reason why wireguard has to be a VPN "plugin". It certainly
is more complex to get a great expirience and the only benefit seems to
be that it's maintained outside of NetworkManager's source tree.

NetworkManager knows "device plugin". These are shared libraries loaded
by NM to support certain device types. There is no stable ABI, hence
all plugins must be in-tree and match NM's version. The use of them is
mainly to reduce package dependencies of the core NetworkManager
package, and reduce the binary size if you don't need it. Device plugin
sources are sub directories in [1]. Essentially, device plugins consist
of subclass of NMDevice and a factory to create them.

Since a wireguard plugin has no external dependencies, probably it
shouldn't be a "device plugin" but just statically linked into the core
daemon. The only downside would be an increase of the binary size --
which is probably better then the burden of a separate package. All you
need is a "nm-device-wireguard.c" file in [1].

Maybe looking at "NMDeviceMacsec" would be a good start [2].


What is also needed, is how clients (nmcli, nm-connection-editor)
configure a wireguard setting. That commonly works by having a
"NMSettingWireguard" in libnm-core to contain all properties relevant
for wireguard. Unfortunately, it tends to be a bit combersome to
implement these setting classes. See also [2] for how it was done for
Macsec. Wireguard's peers are complex objects, similar to
NMSettingIPConfig's NMIPRoute/NMIPAddress.

I think NM would not re-use systemd's netlink implementation.
We fork (copy + paste) parts of systemd's source tree [3], but we only
use the parts that we really want from there (like DHCPv4, DHCPv6,
LLDP). We don't use any netlink related systemd API directly,
and I think we shouldn't.
The main reason is that we already have our way to handle netlink
(which works quite well). Switching to systemd API would be a large
effort, only to end up with something that is less flexible to our


The embeddable-wg-library is very nice! and we certainly should look at
that for inspiration, same for the networkd code. But I think we should
take the relevant netlink parts and extend our existing netlink code.

We are about to drop using libnl3 [4]. I personally think that netlink
is convenient enough, hence for a large project like NetworkManager it
seems preferrable to craft our own netlink code that suits our needs


We need to support rtnetlink for wireguard, which all happens in
NMPlatform [5] [6].


Currently, we only use generic netlink for nl80211.

I am contemplating, whether nl80211 and wireguard should both re-use
the one netlink socket from the NMPlatform singleton instead of opening
multiple sockets. That would require to integrate the genl requests
into platform's send-receive code [7]. Not sure about that though...


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]