NetworkManager Plugin

NetworkManager Plugin

[Max Moser]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

Good day, ladies and gentlemen!



I have been working on a NM plugin for wireguard as part of my thesis 
for quite a while, but somehow I've never really found the time to work 
on that (sorry about that!).

*Until recently.*

Since we have semester break in February, I have finally found the time 
(and motivation) to put some effort into this thing.


So, I forked the OpenVPN plugin at some point and built my current 
solution on that foundation. This means that my plugin is actually 
pretty much pure C, so almost no dependencies (obviously, NM, WG and 
GLib stuff).

After briefly talking to my supervisor about making the thing public 
(which he considered to be a pretty positive step), I uploaded it from 
our internal GitLab to GitHub:
https://github.com/max-moser/network-manager-wireguard/ 
<https://github.com/max-moser/network-manager-wireguard/>


The basic workflow of creating a NMConnection (either from scratch 
through the Connection-Editor UI, or by importing a wg-quick formatted 
conf file [export works too]) and connecting to it works.

However, there are still a ton of issues open, of which I'll list just a 
few:

* the plugin sets up the connection by spawning wg-quick on a temporary 
conf file instead of implementing that logic directly
* the Editor UI isn't quite top notch and there are two tabs (IPv4 and 
IPv6) that I did not use, but also can't seem to get rid of
* internally, everything in the plugin is stored as data-item and not as 
secret
* etc.


However, I think that most of those problems are not actually that huge 
and could be fixed without tremendous effort -- they are just many in 
number.

So, if anybody would be interested in checking it out and maybe even 
contributing, I'd be very glad about that! :)



Best regards,

Max


[-- Attachment #2: Type: text/html, Size: 2421 bytes --]

Re: NetworkManager Plugin

[Jason A. Donenfeld]

Hey Max,

This is wonderful news. I'm happy to work with you to make sure this
comes out perfectly, and maybe when it's finished we can submit it
upstream to NetworkManager, similar to how systemd-networkd now has
WireGuard support built-in.

The biggest hurdle I currently see is entirely removing the dependency
on wg-quick and wg, and talking Netlink yourself to the kernel, just
like systemd-networkd does. It shouldn't be too hard to adopt the
libmnl-based code in wg(8) to be suitable for your usage; I can assist
with this. In general, the fwmark/routing logic of wg-quick should
probably be done in a NetworkManager-centric way, which means not
using wg-quick.

Looks like things are off to a great start!

Jason

Re: NetworkManager Plugin

[Jordan DeBeer]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

Hello Max,

I went ahead and tested this on Fedora 27 w/ NetworkManager 1.8.6-1.fc27
and was able to get it working.  A few things I noticed:

Starting the VPN with SELinux enabled results in a number of alerts.
Mostly for the sysctl source process.  This is to be expected as you
mentioned you were testing on Arch.  If this ever ends up getting packaged
for Fedora the policies can probably be added to the RPM.

The DNS field under Identity does not currently function.  I am not sure
how you want to handle this field as NetworkManager has their own DNS field
under the IPv4 tab in the GUI.

The Endpoint section of the GUI only accepts IP addresses and not FQDNs.

and the last thing I noticed: the Private Key section is required.  This
breaks functionality if you were to have your private key stored in a
password manager.  This is solvable by just pasting a properly formatted
key (I just used my public key) into the field and adding a Post Up script
to grab the private key string.

I am going to keep playing around with this and possibly work on packaging
it into an RPM.

This adds quite a bit of value to Wireguard imo so glad to see you worked
on this.  Thank you!

Cheers,
Jordan DeBeer

On Wed, Feb 14, 2018 at 10:28 AM, Jason A. Donenfeld <Jason@zx2c4.com>
wrote:

> Hey Max,
>
> This is wonderful news. I'm happy to work with you to make sure this
> comes out perfectly, and maybe when it's finished we can submit it
> upstream to NetworkManager, similar to how systemd-networkd now has
> WireGuard support built-in.
>
> The biggest hurdle I currently see is entirely removing the dependency
> on wg-quick and wg, and talking Netlink yourself to the kernel, just
> like systemd-networkd does. It shouldn't be too hard to adopt the
> libmnl-based code in wg(8) to be suitable for your usage; I can assist
> with this. In general, the fwmark/routing logic of wg-quick should
> probably be done in a NetworkManager-centric way, which means not
> using wg-quick.
>
> Looks like things are off to a great start!
>
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #2: Type: text/html, Size: 2889 bytes --]

Re: NetworkManager Plugin

[Maximilian Moser]

[-- Attachment #1: Type: text/plain, Size: 5577 bytes --]

Whoa, I actually kind of expected some response like "yeah nice, but
we've already done that plugin, so you can go home again"
I actually just wanted to get this thesis over with and thought, why not
post the result to the mailing list and see if anybody is still interested?

So I'm somewhat excited about the acceptance and the possible prospect
of this thing getting packaged for distros :D


Regarding the issues... About some of them, I did know in one way or the
other.
E.g. the Endpoint section only accepting IPs -- this one goes even
further: you also can't have an IP6 in square brackets as is usually
required for specification of ports; only hex digits, colons and maybe a
subnet postfix.
Also, the conf parsing part splits the input primarily by whitespaces,
so it'll give you an error if you have something like
"AllowedIPs=0.0.0.0/0" instead of "AllowedIPs = 0.0.0.0/0" in any line.

Most of the others were however issues that I hadn't thought of; maybe
it would be smart to put up some issue tracking and post them there? I'm
sure to forget half of them in about a week.


> The DNS field under Identity does not currently function.  I am not
> sure how you want to handle this field as NetworkManager has their own
> DNS field under the IPv4 tab in the GUI.
Yeah, that might be one conceptual challenge which I didn't really want
to face: Deciding which parts would be more appropriate in the IPv4 /
IPv6 tabs of the UI (which are not so easy to get rid of, if this is
possible at all).
Alongside the DNS, it might (or might not) make sense to put the
[Interface] Address into those tabs, and if possible, the [Peer]
Endpoint too... But I think it might also cause more confusion among
users if those settings are split up than it would help.

> and the last thing I noticed: the Private Key section is required. 
> This breaks functionality if you were to have your private key stored
> in a password manager.  This is solvable by just pasting a properly
> formatted key (I just used my public key) into the field and adding a
> Post Up script to grab the private key string.
I think the private key falls into the category of "secrets" instead of
"data items", so that might require an overhaul generally.
In the current version, secrets aren't used at all - which makes the
auth-dialog currently superfluous.
Making the private key into a secret might also legitimate the actual
use of the auth-dialog, since its job is primarily searching through
whereever (e.g. keyring or just plain asking the user via a dialog,
hence the name) and look if it can find the required secrets.

In the near future, I'll probably focus more on the written part of the
thesis, so fixing the issues will probably have to wait a while on my part.


> This adds quite a bit of value to Wireguard imo so glad to see you
> worked on this.  Thank you!  
Thank you for your interest and actually testing it on another system ;)


Best regards,
Max


On 14.02.2018 17:58, Jordan DeBeer wrote:
> Hello Max,
>
> I went ahead and tested this on Fedora 27 w/ NetworkManager
> 1.8.6-1.fc27 and was able to get it working.  A few things I noticed:
>
> Starting the VPN with SELinux enabled results in a number of alerts. 
> Mostly for the sysctl source process.  This is to be expected as you
> mentioned you were testing on Arch.  If this ever ends up getting
> packaged for Fedora the policies can probably be added to the RPM.
>
> The DNS field under Identity does not currently function.  I am not
> sure how you want to handle this field as NetworkManager has their own
> DNS field under the IPv4 tab in the GUI.
>
> The Endpoint section of the GUI only accepts IP addresses and not FQDNs.
>
> and the last thing I noticed: the Private Key section is required. 
> This breaks functionality if you were to have your private key stored
> in a password manager.  This is solvable by just pasting a properly
> formatted key (I just used my public key) into the field and adding a
> Post Up script to grab the private key string.
>
> I am going to keep playing around with this and possibly work on
> packaging it into an RPM. 
>
> This adds quite a bit of value to Wireguard imo so glad to see you
> worked on this.  Thank you! 
>
> Cheers,
> Jordan DeBeer
>
> On Wed, Feb 14, 2018 at 10:28 AM, Jason A. Donenfeld <Jason@zx2c4.com
> <mailto:Jason@zx2c4.com>> wrote:
>
>     Hey Max,
>
>     This is wonderful news. I'm happy to work with you to make sure this
>     comes out perfectly, and maybe when it's finished we can submit it
>     upstream to NetworkManager, similar to how systemd-networkd now has
>     WireGuard support built-in.
>
>     The biggest hurdle I currently see is entirely removing the dependency
>     on wg-quick and wg, and talking Netlink yourself to the kernel, just
>     like systemd-networkd does. It shouldn't be too hard to adopt the
>     libmnl-based code in wg(8) to be suitable for your usage; I can assist
>     with this. In general, the fwmark/routing logic of wg-quick should
>     probably be done in a NetworkManager-centric way, which means not
>     using wg-quick.
>
>     Looks like things are off to a great start!
>
>     Jason
>     _______________________________________________
>     WireGuard mailing list
>     WireGuard@lists.zx2c4.com <mailto:WireGuard@lists.zx2c4.com>
>     https://lists.zx2c4.com/mailman/listinfo/wireguard
>     <https://lists.zx2c4.com/mailman/listinfo/wireguard>
>
>


[-- Attachment #2: Type: text/html, Size: 8345 bytes --]

Re: NetworkManager Plugin

[Jason A. Donenfeld]

Hi Max,

On Thu, Feb 15, 2018 at 1:34 AM, Maximilian Moser
<e1326252@student.tuwien.ac.at> wrote:
> I actually just wanted to get this thesis over with and thought, why not
> post the result to the mailing list
> I'll probably focus more on the written part of the
> thesis, so fixing the issues will probably have to wait a while on my part.

I'm certainly not interested in "throw it over the fence" coding. I'm
happy to work with you on "the acceptance and the possible prospect of
this thing getting packaged for distros," as you wrote, but only if
you're actually committed to maintaining it. It sounds to me like this
is something in your mind that is "over with"? That's disapointing.

> Regarding the issues... About some of them, I did know in one way or the
> other.
> So I'm somewhat excited about the acceptance and the possible prospect of
> this thing getting packaged for distros :D

As I wrote earlier, this is going to require a lot of work to actually
bring to fruition. The first priority should be entirely dispensing
with the use of wg-quick. In order to aid these efforts, I spent some
time writing a mini single-file-c library that you can drop into your
project as a means for talking to the kernel and configuring devices
directly:

https://git.zx2c4.com/WireGuard/tree/contrib/examples/embeddable-wg-library/README

Should be pretty straight-forward to integrate. You'll basically only
need to use the "wg_set_device" function, and perhaps the
"wg_key_from_base64" function too.

Jason

Re: NetworkManager Plugin

[Maximilian Moser]

Hey Jason,


>> I actually just wanted to get this thesis over with and thought, why not
>> post the result to the mailing list
>> I'll probably focus more on the written part of the
>> thesis, so fixing the issues will probably have to wait a while on my part.
> I'm certainly not interested in "throw it over the fence" coding. I'm
> happy to work with you on "the acceptance and the possible prospect of
> this thing getting packaged for distros," as you wrote, but only if
> you're actually committed to maintaining it. It sounds to me like this
> is something in your mind that is "over with"? That's disapointing.

Oh sorry, that wasn't my intention to say. What I meant is that I wanted 
to get a working prototype ASAP, and if nobody is interested in it 
anymore, that's that.

However, this does not seem to be the case and I'll be glad to continue 
development on it. :)


Max


On 15/02/18 15:07, Jason A. Donenfeld wrote:
> Hi Max,
>
> On Thu, Feb 15, 2018 at 1:34 AM, Maximilian Moser
> <e1326252@student.tuwien.ac.at> wrote:
>> I actually just wanted to get this thesis over with and thought, why not
>> post the result to the mailing list
>> I'll probably focus more on the written part of the
>> thesis, so fixing the issues will probably have to wait a while on my part.
> I'm certainly not interested in "throw it over the fence" coding. I'm
> happy to work with you on "the acceptance and the possible prospect of
> this thing getting packaged for distros," as you wrote, but only if
> you're actually committed to maintaining it. It sounds to me like this
> is something in your mind that is "over with"? That's disapointing.
>
>> Regarding the issues... About some of them, I did know in one way or the
>> other.
>> So I'm somewhat excited about the acceptance and the possible prospect of
>> this thing getting packaged for distros :D
> As I wrote earlier, this is going to require a lot of work to actually
> bring to fruition. The first priority should be entirely dispensing
> with the use of wg-quick. In order to aid these efforts, I spent some
> time writing a mini single-file-c library that you can drop into your
> project as a means for talking to the kernel and configuring devices
> directly:
>
> https://git.zx2c4.com/WireGuard/tree/contrib/examples/embeddable-wg-library/README
>
> Should be pretty straight-forward to integrate. You'll basically only
> need to use the "wg_set_device" function, and perhaps the
> "wg_key_from_base64" function too.
>
> Jason

Re: NetworkManager Plugin

[Jason A. Donenfeld]

On Thu, Feb 15, 2018 at 3:35 PM, Maximilian Moser
<e1326252@student.tuwien.ac.at> wrote:
> However, this does not seem to be the case and I'll be glad to continue
> development on it. :)

Wonderful!

Re: NetworkManager Plugin

[Maximilian Moser]

Since we're already listed on the NetworkManager page [1], it'd be a 
shame to just drop it.
Also, it would be kind of a waste having gone through all the pain of 
getting a basic grasp on the workings of it all for nothing.
Still, I'll gladly accept contributions ;)

Oh right, maybe it'd be worth noting that Thomas Haller, one of the 
NetworkManager guys, has spoken in favour of native NM wireguard 
integration on the NM mailing list:
> Hi Maximilian,
>
>
> cool, thanks for letting us know.
>
> I added a link tohttps://wiki.gnome.org/Projects/NetworkManager/VPN
>
>
> I still think, it would be great to have wireguard support in
> NetworkManager not via a VPN plugin. But that is for another day.
>
>
> best,
> Thomas

-- Max


[1] 
https://wiki.gnome.org/Projects/NetworkManager/VPN#VPN_Plugins_maintained_by_third_parties


On 15/02/18 15:46, Jason A. Donenfeld wrote:
> On Thu, Feb 15, 2018 at 3:35 PM, Maximilian Moser
> <e1326252@student.tuwien.ac.at> wrote:
>> However, this does not seem to be the case and I'll be glad to continue
>> development on it. :)
> Wonderful!

Re: NetworkManager Plugin

[Maykel Moya]

On 15/02/18 15:57, Maximilian Moser wrote:

> Since we're already listed on the NetworkManager page [1], it'd be a
> shame to just drop it.
> Also, it would be kind of a waste having gone through all the pain of
> getting a basic grasp on the workings of it all for nothing.
> Still, I'll gladly accept contributions ;)

Wondering about the pic in slide 8 of
https://fosdem.org/2018/schedule/event/bulletinboard_dht/attachments/slides/2204/export/events/attachments/bulletinboard_dht/slides/2204/presentation.pdf

Regards,
maykel

[1] https://fosdem.org/2018/schedule/event/bulletinboard_dht/

Re: NetworkManager Plugin

[Jason A. Donenfeld]

On Thu, Feb 15, 2018 at 9:15 PM, Maykel Moya <mmoya@mmoya.org> wrote:
> Wondering about the pic in slide 8 of
> https://fosdem.org/2018/schedule/event/bulletinboard_dht/attachments/slides/2204/export/events/attachments/bulletinboard_dht/slides/2204/presentation.pdf

I think he's working on some wilder plugin that incorporates his DHT
stuff, which is a separate effort from Max's. My personal preference
is getting a lightweight but functional NetworkManager plugin out
there for users, that doesn't come with the baggage or bells&whistles
of the DHT. But for people using the DHT work, having the plugin for
that is undoubtedly useful.

Re: NetworkManager Plugin

[Max Moser]

I just read that he's on to something in Rust, don't know any specifics 
though.

I've written him an e-mail a couple of days ago, since some sort of 
comparison or joining forces may be beneficial for everybody.


On 16/02/18 06:33, Jason A. Donenfeld wrote:
> On Thu, Feb 15, 2018 at 9:15 PM, Maykel Moya <mmoya@mmoya.org> wrote:
>> Wondering about the pic in slide 8 of
>> https://fosdem.org/2018/schedule/event/bulletinboard_dht/attachments/slides/2204/export/events/attachments/bulletinboard_dht/slides/2204/presentation.pdf
> I think he's working on some wilder plugin that incorporates his DHT
> stuff, which is a separate effort from Max's. My personal preference
> is getting a lightweight but functional NetworkManager plugin out
> there for users, that doesn't come with the baggage or bells&whistles
> of the DHT. But for people using the DHT work, having the plugin for
> that is undoubtedly useful.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: NetworkManager Plugin

[Manuel Schölling]

Hi,

On Fri, 2018-02-16 at 06:33 +0100, Jason A. Donenfeld wrote:
> I think he's working on some wilder plugin that incorporates his DHT
> stuff, which is a separate effort from Max's. My personal preference
> is getting a lightweight but functional NetworkManager plugin out
> there for users, that doesn't come with the baggage or bells&whistles
> of the DHT. But for people using the DHT work, having the plugin for
> that is undoubtedly useful.

Yeah, I gave that presentation. The plugin I wrote is suppose to work
for both: raw wireguard and my wireguard-p2p solution, that lets you
circumvent the NAT and dyndns problems. I wrote it in Rust because I
really did not go through all the pain with GTK that Max went through
;)

My plugin comes independent of the DHT client (it just communicates
with it via dbus if the DHT client is installed). However, it's written
in Rust, so I don't think that it would be easy to get it accepted
upstream.

Re: NetworkManager Plugin

[Javier Arteaga]

Hi all,

First off, thanks for WireGuard and this effort!

I've tested the NM plugin on my Arch/GNOME3 setup and it works for me
too - congrats! I'm looking to get a bit more involved with the
community, so it would be my pleasure to contribute something back.

On Thu, Feb 15, 2018 at 2:07 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> As I wrote earlier, this is going to require a lot of work to actually
> bring to fruition. The first priority should be entirely dispensing
> with the use of wg-quick. In order to aid these efforts, I spent some
> time writing a mini single-file-c library that you can drop into your
> project as a means for talking to the kernel and configuring devices
> directly:

If nobody else is on this already then I'd like to take a stab at it.

Otherwise, I'll figure out other ways to help get this upstreamed :)

Cheers!

-- 
Javier Arteaga

Re: NetworkManager Plugin

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On Wed 2018-02-14 16:28:59 +0100, Jason A. Donenfeld wrote:

> This is wonderful news. I'm happy to work with you to make sure this
> comes out perfectly, and maybe when it's finished we can submit it
> upstream to NetworkManager, similar to how systemd-networkd now has
> WireGuard support built-in.

last time i looked, network-manager included a local copy of a big chunk
of systemd code.  so it's possible that a newer version of
network-manager will already have the systemd-networkd code available to
it, and you just need to hook into it correctly from the nm internals.

        --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]