Re: NetworkManager Plugin

[Maximilian Moser <e1326252@student.tuwien.ac.at>]

[-- 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 --]