I know. The tap.c code needs an upgrade, not to evaluate all drivers, but just compatible drivers when creating a new adapter. This speeds things a lot. There's a flag that needs to be changed. Somewhere deep on my TODO lists.
I would suggest against temporary adapters on Windows. This is OK on Linux, but
Windows is not Linux. Apart from the time penalty you already discovered, there
are more annoying issues with temporary adapters: adapters always get a new
GUID on creation, making NLA think it's a new network each time. This will keep
resetting the firewall profile assigned to the adapter and piling up network
IDs in user registry at each connection attempt. Also, changing bindings on
adapters don't persist (vmWare, VirtualBox, Hyper-V bindings comes to my mind)…
I am testing an intermediate approach to adapter management on Windows,
inspired by Microsoft's own way how Windows handle dial-up adapters:
1. if adapter "My VPN Connection" doesn't exist, create it.
2. else enable it
3. use it
4. disable it
In my observation, this is the most streamlined approach on Windows. It avoids
adapter creation burden, while still (re)creates it on demand. Disabling
adapter when it is not in use releases the resources, removes the adapter from
the network stack, halts the adapter, unloads the driver when the last of the
adapters (of the same driver) is disabled… Like adapter was deleted, only its
settings persist in registry.
An annoyance here is, the adapters pile up over time. On multi-user computers,
OpenVPN GUI don't have a complete overview which one are stale (no
corresponding .ovpn file exist anymore) to clean them. Cleaning requires
elevation… An admin user may use Device manager to clean them, uninstaller
should clean them. Both are not ideal. On test computers with lots of
configuration fuss that might be a problem. On production computers this
shouldn't be a big issue. Mind that even Hyper-V doesn't clean up adapters if
you install and uninstall it on Windows.
Maybe we could save the absolute path to .ovpn file in the adapter registry to
assign it to a particular profile. Interactive service could periodically
delete orphaned adapters. I'm not worried about .ovpn-less tunnels: users
running openvpn.exe specifying all settings in the command line know what
they're doing.
Best regards,
Simon
From: Lev Stipakov <lstipa...@gmail.com>
Sent: Monday, November 25, 2019 10:04 AM
To: Selva Nair <selva.n...@gmail.com>
Cc: openvpn-devel <openvpn-devel@lists.sourceforge.net>
Subject: Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun
device
Hi,
(cc:ed to -devel)
I would vote for B and not the combination.
With wintun there is no backwards compatibility requirements, so we could use a
cleaner, consistent and simpler approach (i.e B). Do not create any adapter
during installation and dynamically create a temporary adapter at connection
time.
My main concern with creating tun adapter on demand is that it is far from
instant:
$ time ./tapctl.exe create --hwid wintun
{D9F56B7A-3054-4ADC-9457-61030F0B469D}
real 0m2,090s
I don't think we want to add it to connection time.
Creating one persistent adapter per profile (as viscosity does for tapwindows
and wireguard seems to do for wintun)
If I remember right, wireguard doesn't create persistent adapter, instead it
adds/removes it on demand.
If --dev-node is specified, we open the named adapter which the user is
supposed to have created as we do for tapwindows.
Yes, I plan to add support for --dev-node for wintun.
--
-Lev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
