Using WireGuard on Windows as non-admin - proper solution?

[Viktor H]

Hello,

Jason, thanks for a quick reply and a PoC. I have tested it and it seems 
to work fine.
(small note: non-admin user can't Activate the tunnel via systray 
context menu, they have to open up GUI and click "Activate"; 
deactivation via systray context menu works)

As for the concept itself, I feel I am not qualified to judge the 
security implication of this solution since my knowledge of Windows 
security and network internals are next to none.

I have also tested increasing metric on the wg interface above the 
metric of local link with the same IP subnet [1] and that also seemed to 
work, therefore enabling the option for "always-on" setup.
I have however experienced that there might be a problem in the case of 
pushed DNS server since it might hinder normal (non-VPN-related) usage 
of the Internet, e.g. in the case the pushed DNS server does not resolve 
IPv6 addresses but the client does have IPv6 connectivity.

It seems that the "Network Configuration Operator" as Patrik Kolmqvist 
suggested might be one of the routes to do it properly. OpenVPN afaik 
uses its own group "OpenVPN Administrators" for this kind of thing [2] 
though again, I am not experienced enough to be able to consider 
security of this approach.

Finally thanks for pointing out the ACL setting for the service option, 
that seems to be similar or equal to the solution on Reddit I posted 
earlier, so I'll look into it further.

Thanks everyone.

Viktor

[1] 
https://docs.microsoft.com/en-us/powershell/module/nettcpip/set-netipinterface?view=win10-ps
[2] https://community.openvpn.net/openvpn/wiki/OpenVPN-GUI-New#gui-group

On 13.11.2020 3:16, Jason A. Donenfeld wrote:
> Hi Viktor,
>
> I am actually interested in solving this. I took an initial stab at it
> here, but I'm not super comfortable with the implementation or the
> security implications:
> https://git.zx2c4.com/wireguard-windows/commit/?h=jd/unprivd-knob
>
> Aside from doing this from within our existing UI, the general
> solution using the service-based building blocks is to simply allow
> users to start and stop services that begin with "WireGuardTunnel$".
> So the flow is something like:
>
> 1. wireguard /installtunnelservice  path\to\sometunnel.conf.
> 2. Change the ACLs on WireGuardTunnel$sometunnel to fit your user.
> 3. Have the user use `net start` and `net stop`, or similar, to
> control whether the service is up or down.
>
> That's not super pretty, but it should work, and it is automatable.
> Meanwhile, I'll keep thinking about various ways to do this in a more
> "first-party" way.
>
> Jason