Hi,
The Wintun doesn't create its own communication I/O device. Running a separate NdisRegisterDeviceEx() device came with a big can of worms, so we decided not to run our own, but rather piggy-back on the existing NDIS one from the NdisMRegisterMiniportDriver() that we tap on. Technically, we could limit it to a single client handle, but this device is primarily used by Windows to manage the adapter, therefore we must not tweak it in this direction. As Lev said: Wintun adds an IOCTL call to register ring buffers and it is this IOCTL that has a refcounting implemented to deny secondary connection attempts. Unfortunately for OpenVPN, this IOCTL is restricted to privileged processes only. You cannot use it to detect which Wintun adapters are in use by an unprivileged openvpn.exe process. WireGuard is very strict about which TUN adapter it will use – it will never ever use a lottery to pick one. We have more options here: A. Wintun adapter can be explicitly chosen by configuration only (by name or GUID). With tapctl.exe utility users can make an adapter with predefined name and put this name into .ovpn. If the Wintun adapter is not specified explicitly => configuration error. Less lottery; predictable tunnel-adapter mapping when running multiple tunnels; disturbed users because there is an inconsistency between TAP-Windows6 and Wintun adapter selection logic. B. The tapctl.exe code is in OpenVPN repo already and could be integrated in openvpn.exe and interactive service to create Wintun adapter on demand. But, you have to take responsibility to clean what you have created. Pretty much the same as A), but nicer for user. In the long term, I'd suggest this "create adapter if doesn't exist" approach even for TAP-Windows6 adapters. C. Use adapter media state to see if particular Wintun adapter is already in use or not. Mind that registering buffer also sets MediaConnectStateConnected, and stays connected until its client closes handle or dies. This allows OpenVPN to extend its "use first available adapter" approach to Wintun adapters. Best regards, Simon From: Selva Nair <selva.n...@gmail.com> Sent: Tuesday, November 19, 2019 7:03 PM To: Lev Stipakov <lstipa...@gmail.com> Cc: Lev Stipakov <l...@openvpn.net>; openvpn-devel <openvpn-devel@lists.sourceforge.net> Subject: Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device Hi Lev, On Tue, Nov 19, 2019 at 12:23 PM Lev Stipakov <lstipa...@gmail.com <mailto:lstipa...@gmail.com> > wrote: Hi, Apart from the error message, there is a larger issue especially when we use iservice. In that case, we have to preserve privilege separation and allowing a user to open a device handle in use by another has to be avoided. Do you see it as a security issue when handle can be opened by another process? I don't know the internals of wintun to know that for sure. To read / write to tunnel one needs to register ring buffers, and this call will fail for any other process. Am I missing something here? Hopefully, Simon can confirm whether that provides a sufficient safety net. Selva
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
