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
