[Openvpn-devel] On tap-windows6 adapter installation by tapctl.exe

2020-09-02 Thread Selva Nair
Hi,

tldr: a fix for Trac 1321

Currently tapctl.exe does the following to create an adapter and install
the driver on it.

1. Create a device info structure
2. Set the hardware id on it
3. Search the driver store for the latest matching driver
4. Select the driver, set it in the device info and then call
SetupDiCallClassInstaller() with
  (a) DIF_REGISTERDEVICE
  (b) DIF_REGISTER_COINSTALLERS
  (c) DIF_INSTALL_INTERFACES
  (d) DIF_INSTALLDEVICE

As per setupapi.dev.log, it appears that step 4 (d) is failing with some
access error to the driver store unless elevated to SYSTEM (see Trac 1321).
This leaves the adapter not fully configured. Hard to say exactly what
fails as none of the function calls return any error.

I propose to replace 4(d) with a call to DiInstallDevice() instead. My
tests show this completes without error.

This also has an advantage that we could call it with driver_info = NULL
which will force the system to use the latest matching driver. That would
also eliminate step 3 which is right now very inefficient, though not
required to fix the problem at hand.

If this sounds sane, I'll submit a patch.

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


Re: [Openvpn-devel] [PATCH] openvpnmsica: make adapter renaming non-fatal

2020-09-02 Thread Lev Stipakov
Hi,

>> Warning is printed inside tap_delete_adapter().
>
> tap_delete_adapter() is not called here.

Right, I managed to mistype tap_set_adapter_name().

> I was suggesting that if we do check the return value, let us also print a 
> warning
> that renaming failed. That can't be done anywhere except just before 
> converting the error
> to SUCCESS.

I realized that warning inside tap_set_adapter_name() also
displays a messagebox, which we probably don't want to show.

I'll send a v2 which prints warning and doesn't display a messagebox.

-- 
-Lev


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


Re: [Openvpn-devel] [PATCH] openvpnmsica: remove adapter renaming

2020-09-02 Thread Simon Rozman via Openvpn-devel
Hi,

Adapter name already is configurable in openvpn-build/windows-msi/msi.wxs: 
https://github.com/Amebis/openvpn-build/blob/5f5ba807de2bad50d01a5b08dfc6fad98ee41213/windows-msi/msi.wxs#L1300

Regards, Simon

From: Selva Nair 
Sent: Wednesday, September 2, 2020 3:12 PM
To: Lev Stipakov 
Cc: Lev Stipakov ; openvpn-devel 

Subject: Re: [Openvpn-devel] [PATCH] openvpnmsica: remove adapter renaming

Hi,

I would suggest to keep this renaming but make it not fatal. A descriptive name 
is nice to have and we could even make the name configurable at some point in 
future.

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


Re: [Openvpn-devel] [PATCH] openvpnmsica: make adapter renaming non-fatal

2020-09-02 Thread Selva Nair
Hi

On Wed, Sep 2, 2020 at 9:54 AM Lev Stipakov  wrote:

> Hi,
>
> >>  if (dwResult != ERROR_SUCCESS)
> >>  {
> >> -tap_delete_adapter(NULL, ,
> );
> >> +/* failed renaming is not a fatal error, continue
> */
> >> +dwResult = ERROR_SUCCESS;
> >
> >
> > This looks strange. If we are going to rewrite dwResult, why set it and
> check it at all, just call
> > tap_set_adapter() without storing the return value and add the comment.
>
> I think this is good for documentation purposes - that we are aware
> that function may fail, but in this case it is not fatal and we continue.
>

That's achieved also by just adding a comment that we don't check the
return value as failure is not fatal. Anyway, this works too.


>
> > Or, better, print a warning message saying the rename failed.
>
> Warning is printed inside tap_delete_adapter().
>

tap_delete_adapter() is not called here. I was suggesting that if we do
check the return value, let us also print a  warning that renaming failed.
That can't be  done anywhere except just before converting the error
to SUCCESS.

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


Re: [Openvpn-devel] [PATCH] openvpnmsica: make adapter renaming non-fatal

2020-09-02 Thread Lev Stipakov
Hi,

>>  if (dwResult != ERROR_SUCCESS)
>>  {
>> -tap_delete_adapter(NULL, , 
>> );
>> +/* failed renaming is not a fatal error, continue */
>> +dwResult = ERROR_SUCCESS;
>
>
> This looks strange. If we are going to rewrite dwResult, why set it and check 
> it at all, just call
> tap_set_adapter() without storing the return value and add the comment.

I think this is good for documentation purposes - that we are aware
that function may fail, but in this case it is not fatal and we continue.

> Or, better, print a warning message saying the rename failed.

Warning is printed inside tap_delete_adapter().

-- 
-Lev


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


Re: [Openvpn-devel] [PATCH] openvpnmsica: make adapter renaming non-fatal

2020-09-02 Thread Selva Nair
Hi

On Wed, Sep 2, 2020 at 9:39 AM Lev Stipakov  wrote:

> From: Lev Stipakov 
>
> For some users renaming adapter mysteriously fails
> (https://github.com/OpenVPN/openvpn-build/issues/187),
>
> Since renaming is just a a "nice to have", make it not fatail.
>
> Signed-off-by: Lev Stipakov 
> ---
>  src/openvpnmsica/openvpnmsica.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/openvpnmsica/openvpnmsica.c
> b/src/openvpnmsica/openvpnmsica.c
> index 31e90bd2..d5b3f09e 100644
> --- a/src/openvpnmsica/openvpnmsica.c
> +++ b/src/openvpnmsica/openvpnmsica.c
> @@ -1100,7 +1100,8 @@ ProcessDeferredAction(_In_ MSIHANDLE hInstall)
>  dwResult = tap_set_adapter_name(, szName);
>  if (dwResult != ERROR_SUCCESS)
>  {
> -tap_delete_adapter(NULL, ,
> );
> +/* failed renaming is not a fatal error, continue */
> +dwResult = ERROR_SUCCESS;
>

This looks strange. If we are going to rewrite dwResult, why set it and
check it at all, just call
tap_set_adapter() without storing the return value and add the comment.

Or, better, print a warning message saying the rename failed.

Selva


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


[Openvpn-devel] [PATCH] openvpnmsica: make adapter renaming non-fatal

2020-09-02 Thread Lev Stipakov
From: Lev Stipakov 

For some users renaming adapter mysteriously fails
(https://github.com/OpenVPN/openvpn-build/issues/187),

Since renaming is just a a "nice to have", make it not fatail.

Signed-off-by: Lev Stipakov 
---
 src/openvpnmsica/openvpnmsica.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/openvpnmsica/openvpnmsica.c b/src/openvpnmsica/openvpnmsica.c
index 31e90bd2..d5b3f09e 100644
--- a/src/openvpnmsica/openvpnmsica.c
+++ b/src/openvpnmsica/openvpnmsica.c
@@ -1100,7 +1100,8 @@ ProcessDeferredAction(_In_ MSIHANDLE hInstall)
 dwResult = tap_set_adapter_name(, szName);
 if (dwResult != ERROR_SUCCESS)
 {
-tap_delete_adapter(NULL, , );
+/* failed renaming is not a fatal error, continue */
+dwResult = ERROR_SUCCESS;
 }
 }
 }
-- 
2.17.1



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


Re: [Openvpn-devel] [PATCH] openvpnmsica: remove adapter renaming

2020-09-02 Thread Selva Nair
Hi,

I would suggest to keep this renaming but make it not fatal. A
descriptive name is nice to have and we could even make the name
configurable at some point in future.

Selva

On Wed, Sep 2, 2020 at 8:40 AM Lev Stipakov  wrote:

> From: Lev Stipakov 
>
> Renaming doesn't work on some machines (
> https://github.com/OpenVPN/openvpn-build/issues/187)
> and we couldn't find the cause. Also others do not seem to do it, so let's
> get rid of it.
>
> Signed-off-by: Lev Stipakov 
> ---
>  src/openvpnmsica/openvpnmsica.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/src/openvpnmsica/openvpnmsica.c
> b/src/openvpnmsica/openvpnmsica.c
> index 31e90bd2..10d4a1cc 100644
> --- a/src/openvpnmsica/openvpnmsica.c
> +++ b/src/openvpnmsica/openvpnmsica.c
> @@ -1094,15 +1094,6 @@ ProcessDeferredAction(_In_ MSIHANDLE hInstall)
>
>  GUID guidAdapter;
>  dwResult = tap_create_adapter(NULL, NULL, szHardwareId,
> , );
> -if (dwResult == ERROR_SUCCESS)
> -{
> -/* Set adapter name. */
> -dwResult = tap_set_adapter_name(, szName);
> -if (dwResult != ERROR_SUCCESS)
> -{
> -tap_delete_adapter(NULL, ,
> );
> -}
> -}
>  }
>  else if (wcsncmp(szArg[i], L"deleteN=", 8) == 0)
>  {
> --
> 2.17.1
>
>
>
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] OpenVPN 2.5-beta3 released

2020-09-02 Thread Gert Doering
Hi,

On Wed, Sep 02, 2020 at 10:03:11AM +0200, Thomas Schäfer wrote:
> Am 01.09.20 um 22:14 schrieb Gert Doering:
> > On Tue, Sep 01, 2020 at 08:07:20PM +0200, Thomas Schäfer wrote:
> >>>  - IPv4-only VPN
> >> Typo?
> > 
> > We can do that!
> 
> Is it new in 2.5?

The --block-ipv6 command is new.

> Asking again, just to understand the difference
> 
>   "IPv6-only operation"
> I can remove all IPv4-related config

Correct.

> and
> 
>   "IPv4-only VPN"
> means better protection to prevent IPv6-leaks in an intended IPv4-only 
> operation mode

No, the point is "--block-ipv6", not "IPv4 only VPN".  OpenVPN could
always do "IPv4 only VPN" :-)

The scenario here is:

 - user has IPv4+IPv6 at home
 - user uses a VPN service from a VPN provider that only does IPv4
   ("IPv4-only VPN")
 - user accesses www.google.de -> packets go via IPv6, bypassing VPN

if you have that scenario, you can either get a better VPN provider, or
use --block-ipv6 with the IPv4-only VPN provider, to prevent leaking.

(And thanks for the test result)

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


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


[Openvpn-devel] [PATCH] openvpnmsica: remove adapter renaming

2020-09-02 Thread Lev Stipakov
From: Lev Stipakov 

Renaming doesn't work on some machines 
(https://github.com/OpenVPN/openvpn-build/issues/187)
and we couldn't find the cause. Also others do not seem to do it, so let's get 
rid of it.

Signed-off-by: Lev Stipakov 
---
 src/openvpnmsica/openvpnmsica.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/src/openvpnmsica/openvpnmsica.c b/src/openvpnmsica/openvpnmsica.c
index 31e90bd2..10d4a1cc 100644
--- a/src/openvpnmsica/openvpnmsica.c
+++ b/src/openvpnmsica/openvpnmsica.c
@@ -1094,15 +1094,6 @@ ProcessDeferredAction(_In_ MSIHANDLE hInstall)
 
 GUID guidAdapter;
 dwResult = tap_create_adapter(NULL, NULL, szHardwareId, 
, );
-if (dwResult == ERROR_SUCCESS)
-{
-/* Set adapter name. */
-dwResult = tap_set_adapter_name(, szName);
-if (dwResult != ERROR_SUCCESS)
-{
-tap_delete_adapter(NULL, , );
-}
-}
 }
 else if (wcsncmp(szArg[i], L"deleteN=", 8) == 0)
 {
-- 
2.17.1



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


[Openvpn-devel] Summary of the community meeting (2nd September 2020)

2020-09-02 Thread Samuli Seppänen
Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wed 2nd September 2020
Time: 11:30 CEST (9:30 UTC)

Planned meeting topics for this meeting were here:



Your local meeting time is easy to check from services such as



SUMMARY

janjust, lev, mattock and plaisthos participated in this meeting.

---

Talked about OpenVPN 2.5-beta3. There are two known issues it in. The
first one is in the MSI installer:



The second issue manifests itself in the GUI, but is actually tapctl.exe
related (i.e. in the OpenVPN repo):



These need to be fixed.

--

Janjust noticed that (when using OpenVPN 2.5) Networkmanager is set to
ignore any ipv6 settings yet the default ipv6 route is over the VPN.
This seems like a Networkmanager bug, but janjust will investigate a bit
more.

--

Noted that WolfSSL has not responded to our request to provide an easy
fix and it has been 1.5 months now.

--

Plaisthos is working on implementing peer fingerprinting support. This
will also allow to do quick setup with self-signed certificates without
a CA. Each VPN client will have a fingerprint on the server side, so you
will need to restart the server when you add/remove a client.

--

Full chatlog attached
(12:30:56) mattock2: Hi!
(12:32:15) plaisthos: hey!
(12:33:49) janjust_ [~janjust@2001:610:120:e034::1001] è entrato nella stanza.
(12:34:23) janjust_ ha abbandonato la stanza (quit: Client Quit).
(12:34:54) mattock2: So: postpone 2.5.0 - thoughts?
(12:35:31) janjust [~janjust@2001:610:120:e034::1001] è entrato nella stanza.
(12:35:59) mattock2: There are a few major issues, in openvpn-gui and in MSI
(12:36:03) janjust: morning folks... and I immediately see a nicety of 
openvpn+networkmanager ;)
(12:36:43) mattock2: morning!
(12:36:43) lev__: what is GUI issue
(12:36:58) mattock2: second connection fails
(12:37:19) mattock2: can't recall the gui iasue ID
(12:37:20) plaisthos: what is a GUI?
(12:37:24) lev__: ah I think this is not about GUI
(12:37:45) plaisthos: janjust: if we wait for good networkmanager support, we 
can wait another 4 years I guess ;P
(12:37:48) mattock2: yeah  not really, but manifests itself in the gui
(12:37:53) lev__: it is just tap adapters created manually are missing registry 
key "allownonadmin"
(12:38:08) lev__: not sure why/how that regressed
(12:38:39) plaisthos: side note: WolfSSL has now been silent for 1,5 month for 
the quick fix for their OpenVPN support
(12:40:29) mattock2: yep, I recall we agree to not include wolfssl in 2.5 and 
if they continue silence then throw it out completely in 2.6
(12:40:36) lev__: mattock2: https://community.openvpn.net/openvpn/ticket/1321
(12:41:01) janjust: plaisthos yeah I know but I had not expected this: I told 
networkmanager to ignore any ipv6 settings yet my default ipv6 route is over 
the VPN
(12:41:51) lev__: I can look at it unless somebody fixes it first
(12:41:57) lev__: (allownonadmin)
(12:42:10) mattock2: go for it lev
(12:42:10) lev__: (after fixing/mitigating renaming issue)
(12:43:14) mattock2: +1
(12:46:01) mattock2: anyhow
(12:46:24) mattock2: postponing 2.5.0?
(12:46:28) janjust: just wondering about allownonadmin + openvpn interactive 
service etc...  does the gui filter any options before passing them on to the 
iservice?
(12:50:00) lev__: IIRC certain options can only be used by users in Admin group 
or configs in special place
(12:50:51) janjust: ah good
(12:52:46) lev__: yeah, "/* Authorized group who can use any options and config 
locations */"
(12:53:33) plaisthos: janjust: that sounds more like a networkmanager bug that 
anything else
(12:54:31) janjust: plaisthos: I agree and I'll need to test it with the latest 
(git) version of networkmanager before I file a bug report
(12:59:56) plaisthos: short status update: I am working on implement a 
(13:00:03) plaisthos: 
(13:00:06) plaisthos: fp1
(13:00:07) plaisthos: fp2
(13:00:10) plaisthos: 
(13:00:20) plaisthos: option to pin certificates of the peer
(13:00:45) plaisthos: This will also allow to do quick setup with self-signed 
certificates without a CA
(13:05:20) janjust: oh sweet!more or less the "pre-shared public key" method
(13:06:35) plaisthos: yeah
(13:06:44) plaisthos: and also allows use to deprecate --secret/static keys
(13:06:57) plaisthos: since from a user perspective it is almost as easy to 
setup
(13:07:31) janjust: throw in TOFU and openvpn is behaving more and more the 
same as SSH ;)
(13:08:46) plaisthos: TOFU?
(13:08:53) plaisthos: ah trust on first usage
(13:09:04) plaisthos: you will still need to do that manually
(13:09:25) plaisthos: but I am makeing that easy for you since I print the 
fingerprint of the peer in the error message
(13:13:05) janjust: yeah and with SSH it's the client that needs to 

Re: [Openvpn-devel] OpenVPN 2.5-beta3 released

2020-09-02 Thread Thomas Schäfer

Am 01.09.20 um 22:14 schrieb Gert Doering:

Hi,

On Tue, Sep 01, 2020 at 08:07:20PM +0200, Thomas Schäfer wrote:

 - IPv4-only VPN

Typo?


We can do that!


Is it new in 2.5?

Asking again, just to understand the difference

 "IPv6-only operation"
I can remove all IPv4-related config

and

 "IPv4-only VPN"
means better protection to prevent IPv6-leaks in an intended IPv4-only 
operation mode


positive test feedback:

I tested yesterday my setup with with 2.5beta3

linux as server (2.5beta3)
android as client
Windows 10 (2.5beta3) as client

transport: IPv6 only,
payload: IPv4/IPv6 with redirecting all traffic.

It (still) works.

Thank You!


Thomas


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


Re: [Openvpn-devel] OpenVPN 2.5-beta3 released

2020-09-02 Thread Samuli Seppänen
Argh yes. Copy-and-paste from the 2.5-beta1 release notes which had that
typo :).

Samuli

Il 01/09/20 21:07, Thomas Schäfer ha scritto:
>> - IPv4-only VPN
> 
> Typo?
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



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