Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

[Lev Stipakov]

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}

real0m2,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
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

[Simon Rozman]

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  
Sent: Monday, November 25, 2019 10:04 AM
To: Selva Nair 
Cc: openvpn-devel 
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}

real0m2,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

Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

[Selva Nair]

Hi

On Mon, Nov 25, 2019 at 4:03 AM Lev Stipakov  wrote:

> 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}
>
> real0m2,090s
>
> I don't think we want to add it to connection time.
>

No, we don't want that.

I do realize what I wrote earlier was far from ideal. I had forgotten my
travails two years back attempting to add dynamic tap adapter creation to
OpnVPN

As an easy way for supporting multiple tunnels, can we treat success of
open-device + ring-buffer-registration calls together as a successful open
of the adapter, and move on to the next one when that fails? That would be
very similar to what we do for tapwindows right now.

To assist users, when we fail with no free adapters, we could add a feature
to the GUI to add a new one using the RunAsAdmin shell-execute we already
have support for. Will need an improved devcon/tapinstall that does not
reset all adapters when a new one is added, except when unavoidable due to
driver version change.

Simon's suggestion of persistent adapters as required and kept disabled
when not in use sounds interesting. As some providers do supply 100's of
configs, I think we should refrain from creating one adapter per ovpn,
though. They should be using multiple --remote lines in a single config,
but, for that to work well, we need to improve --management-remote option
to provide a friendly UI for remote selection.

Selva
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 3/7] wintun: implement opening wintun device

[Gert Doering]

Hi,

On Mon, Nov 25, 2019 at 09:44:19AM +, Simon Rozman wrote:
> 1.if adapter "My VPN Connection" doesn't exist, create it.
> 2.else enable it
> 3.use it
> 4.disable it

> 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. 

I like the initial approach, but the "pile-up" is annoying.

What about "do this for .ovpn configs that contain a --dev-node setting,
and otherwise just try to enumerate 'OpenVPN Wintun 1', 'OpenVPN Wintun 2',
... and create those as-needed?

This should keep the numbers down...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


smime.p7s
Description: S/MIME cryptographic signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Support for wolfSSL with OpenVPN v2.4.8

[Juliusz Sosinowicz]

Hi David,

I apologize for the delayed response. I will rebase our OpenVPN work off 
of the master branch this week in anticipation for a possible inclusion 
in version 2.5.


Regarding your question "What kind of commitment will we see from the 
WolfSSL organization?":
We have a large customer driving the use of wolfSSL with OpenVPN. We've 
done the initial porting and testing. We will update the port when 
needed and continue to support this effort.
We will also be making public marketing posts and annoucements for 
OpenVPN support on our blog (https://www.wolfssl.com/blog/) and 
subscribed mailing lists.


We understand your concern about the intrusiveness of this patch. The 
majority of insertions occur in the configure and try to follow the 
structure of how other cryptographic backends are compiled against. The 
"Emulate X since these are defined as macros" additions are 
unfortunately necessary as these functions are defined as macros in our 
library. AC_CHECK_FUNCS will not check if the function exists behind a 
macro. Defining these macros in the configure script allows for minimal 
interference in the rest of OpenVPN code. The rest of the changes in the 
patch are library inclusions as some things are defined in slightly 
different locations than OpenSSL. The file  holds the 
configure options for the wolfSSL library. It is necessary to include so 
that the header files know what should be included and defined.


I hope this email clears things up as to why some changes were necessary.

Sincerely
Juliusz

On 14/11/2019 12:25, David Sommerseth wrote:

On 14/11/2019 11:22, Juliusz Sosinowicz wrote:

From: David Garske 

wolfSSL:

Support added in: https://github.com/wolfSSL/wolfssl/pull/2503

```sh
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl
./autogen.sh
./configure --enable-opensslall --enable-des3 --enable-crl --enable-certgen 
--enable-certext --enable-aesctr --enable-sessioncerts CFLAGS="-DWOLFSSL_DES_ECB 
-DHAVE_EX_DATA"
make
sudo make install
```

OpenVPN:

```sh
autoreconf -i -v -f
./configure --with-crypto-library=wolfssl
make
make check
sudo make install
```

NAK.

This patch adds a new feature to the 2.4 branch.  We don't really want to do
that, especially if the change is intrusive (13 files changed, 108 insertions
<< that is intrusive).  WolfSSL support will at best see the light in the
coming 2.5 release (At the hackathon we aim for late 2020Q1 or 2020Q2)

In previous rounds we have asked a lot of questions; there has been no real
responses to those.  This has not even been touched in the relation to this 
patch.

One good thing I do see, is that it seems to try to use an OpenSSL support
layer in WolfSSL - which is good.  But then I wonder why we see additions like
this all over.

+#ifdef ENABLE_CRYPTO_WOLFSSL
+#include 
+#endif

In addition, the change in configure.ac with all the AC_DEFINE lines, tagged
with "Emulate X since these are defined as macros" is also making a lot of
mess.

And then comes the most critical point to all of this:  Who will maintain
WolfSSL support in OpenVPN once this has been applied?  What kind of
commitment will we see from the WolfSSL organization?

The OpenVPN developers community will have an IRC meeting next Thursday (Nov
21 @ 20:00 CET, #openvpn-meeting on FreeNode [1]).  I strongly recommend you
to attend this meeting to follow up your request.


[1] You need to have your nick registered to join
 





___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel