openvpn-devel — OpenVPN developers list

[Openvpn-devel] [PATCH] tun.c: enable using wintun driver under SYSTEM

[Lev S. <lst...@gm...>]

From: Lev Stipakov <le...@op...>

Commit 6d19775a468 has removed SYSTEM elevation hack,
but introduced regression - inability to use wintun without interactive service.

Proceed with ring buffers registration even if iservice is unavailable and display
relevant error message.

Trac #1318

Signed-off-by: Lev Stipakov <le...@op...>
---
 src/openvpn/tun.c | 30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)

diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 30454454..62557364 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -6158,12 +6158,32 @@ wintun_register_ring_buffer(struct tuntap *tt, const char *device_guid)
     }
     else
     {
-        msg(M_FATAL, "ERROR:  Wintun requires SYSTEM privileges and therefore "
-                     "should be used with interactive service. If you want to "
-                     "use openvpn from command line, you need to do SYSTEM "
-                     "elevation yourself (for example with psexec).");
-    }
+        if (!register_ring_buffers(tt->hand,
+                                   tt->wintun_send_ring,
+                                   tt->wintun_receive_ring,
+                                   tt->rw_handle.read,
+                                   tt->rw_handle.write))
+        {
+            switch (GetLastError())
+            {
+                case ERROR_ACCESS_DENIED:
+                    msg(M_FATAL, "ERROR:  Wintun requires SYSTEM privileges and therefore "
+                                 "should be used with interactive service. If you want to "
+                                 "use openvpn from command line, you need to do SYSTEM "
+                                 "elevation yourself (for example with psexec).");
+                    break;
+
+                case ERROR_ALREADY_INITIALIZED:
+                    msg(M_NONFATAL, "Adapter %s is already in use", device_guid);
+                    break;
 
+                default:
+                    msg(M_NONFATAL | M_ERRNO, "Failed to register ring buffers");
+            }
+            ret = false;
+        }
+
+    }
     return ret;
 }
 
-- 
2.17.1

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Lev S. <lst...@gm...>]

Hi,

As Gert mentioned, OpenVPN will set what is needed when connection is
established - just double-checked that this is indeed the case.

> So it didn’t read the .ovpn (to select dhcp) and it didn’t have anything to populate the IP/subnet/dns etc.  This can’t be right.  At the least it should be set to dhcp by default with static IPs added later if necessary.  Or am I doing something wrong?

Apart from missing values when the adapter is not connected, do you
experience any other issues?

-Lev

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Marvin A. <vol...@gm...>]

I noticed the same issue.  I tried upgrading from an earlier version with an .ovpn file (with all settings and inline certs etc that was working previously).  The .ovpn is configured as client to receive dhcp address from the server.  

But when we ran the upgrade .msi, which created both a TAP and wintun interfaces, the TAP was fine but the wintun had static IPs selected with no IPs entered.  Unless someone has some programming smoke and mirrors, that’s asking for a failure.  

So it didn’t read the .ovpn (to select dhcp) and it didn’t have anything to populate the IP/subnet/dns etc.  This can’t be right.  At the least it should be set to dhcp by default with static IPs added later if necessary.  Or am I doing something wrong?

Marvin 

> On Aug 18, 2020, at 11:03 PM, Gert Doering <ge...@gr...> wrote:
> 
> Hi,
> 
>> On Tue, Aug 18, 2020 at 07:30:12PM -0300, Rafael Gava wrote:
>> Inspecting the wintun interface through the properties I saw that on the
>> TCP/IPv4 Properties the default option selected is "Use the following IP
>> address" but the IP address and the Subnet mask were empty. Should that be
>> a problem?
> 
> No.  OpenVPN will set what is needed.
> 
> 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                             ge...@gr...
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Gert D. <ge...@gr...>]

Hi,

On Tue, Aug 18, 2020 at 07:30:12PM -0300, Rafael Gava wrote:
> Inspecting the wintun interface through the properties I saw that on the
> TCP/IPv4 Properties the default option selected is "Use the following IP
> address" but the IP address and the Subnet mask were empty. Should that be
> a problem?

No.  OpenVPN will set what is needed.

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                             ge...@gr...

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Rafael G. <ga...@gm...>]

Hello Guys, sorry for the late reply.

Ok, I'll wait for the fix to retest.

Another question...

Inspecting the wintun interface through the properties I saw that on the
TCP/IPv4 Properties the default option selected is "Use the following IP
address" but the IP address and the Subnet mask were empty. Should that be
a problem?

BR

Rafael

On Tue, Aug 18, 2020 at 5:15 PM Selva Nair <sel...@gm...> wrote:

> Hi
>
> On Tue, Aug 18, 2020 at 3:42 PM Gert Doering <ge...@gr...> wrote:
>
>> Hi,
>>
>> On Tue, Aug 18, 2020 at 03:29:19PM -0400, Selva Nair wrote:
>> > > If you already have SYSTEM, accessing wintun from openvpn directly
>> will
>> > > also work and should bring quite a bit of speed improvement.
>> >
>> > I was wrong to assume that this just works. Looking at it again, the
>> current
>> > implementation of wintun support does not seem to cover this. Meaning
>> the
>> > only working approach is to use the interactive service.
>>
>> Indeed, you are right.  Somewhere on the track we lost the ability
>> to do wintun "from OpenVPN" if we *have* SYSTEM.
>>
>> This is the code in tun.c
>>
>>     if (tt->options.msg_channel)
>>     {
>>         ret = service_register_ring_buffers(tt);
>>     }
>>     else
>>     {
>>         msg(M_FATAL, "ERROR:  Wintun requires SYSTEM privileges and
>> therefore "
>>                      "should be used with interactive service. If you
>> want to "
>>                      "use openvpn from command line, you need to do
>> SYSTEM "
>>                      "elevation yourself (for example with psexec).");
>>     }
>>
>>
>> ... so while I'm happy that we got rid of impersonating SYSTEM, the
>> current
>> code does not even try anymore, just assumes "if there is no message
>> channel,
>> we have not enough privileges".
>>
>> OTOH the message is severely misleading now, since it suggests "having
>> the right privileges will make this work".
>>
>>
>> This needs fixing - either we *try*, and if we fail, print the message
>> about insufficient privileges, or we change the message to actually
>> print something like "Wintun support is only possible if the interactive
>> service is used.  Do not run from the CLI.  Use the GUI in non-admin
>> mode.".
>>
>
> We have all the necessary code to do "register ring buffers" that the
> service uses, so just calling it and printing that message on failure
> should fix it.
>
> Looks like something lost by Lev during a rebase or conflict resolution.
>
> Trac #1318
>
> Selva
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Selva N. <sel...@gm...>]

Hi

On Tue, Aug 18, 2020 at 3:42 PM Gert Doering <ge...@gr...> wrote:

> Hi,
>
> On Tue, Aug 18, 2020 at 03:29:19PM -0400, Selva Nair wrote:
> > > If you already have SYSTEM, accessing wintun from openvpn directly will
> > > also work and should bring quite a bit of speed improvement.
> >
> > I was wrong to assume that this just works. Looking at it again, the
> current
> > implementation of wintun support does not seem to cover this. Meaning the
> > only working approach is to use the interactive service.
>
> Indeed, you are right.  Somewhere on the track we lost the ability
> to do wintun "from OpenVPN" if we *have* SYSTEM.
>
> This is the code in tun.c
>
>     if (tt->options.msg_channel)
>     {
>         ret = service_register_ring_buffers(tt);
>     }
>     else
>     {
>         msg(M_FATAL, "ERROR:  Wintun requires SYSTEM privileges and
> therefore "
>                      "should be used with interactive service. If you want
> to "
>                      "use openvpn from command line, you need to do SYSTEM
> "
>                      "elevation yourself (for example with psexec).");
>     }
>
>
> ... so while I'm happy that we got rid of impersonating SYSTEM, the current
> code does not even try anymore, just assumes "if there is no message
> channel,
> we have not enough privileges".
>
> OTOH the message is severely misleading now, since it suggests "having
> the right privileges will make this work".
>
>
> This needs fixing - either we *try*, and if we fail, print the message
> about insufficient privileges, or we change the message to actually
> print something like "Wintun support is only possible if the interactive
> service is used.  Do not run from the CLI.  Use the GUI in non-admin
> mode.".
>

We have all the necessary code to do "register ring buffers" that the
service uses, so just calling it and printing that message on failure
should fix it.

Looks like something lost by Lev during a rebase or conflict resolution.

Trac #1318

Selva

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Gert D. <ge...@gr...>]

Hi,

On Tue, Aug 18, 2020 at 09:42:48PM +0200, Gert Doering wrote:
> Indeed, you are right.  Somewhere on the track we lost the ability
> to do wintun "from OpenVPN" if we *have* SYSTEM.

commit 6d19775a468, I acked it, and I should have looked closer at
all the line that got removed...

Anyway.  That's what it is right now: only iservice.

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                             ge...@gr...

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Gert D. <ge...@gr...>]

Hi,

On Tue, Aug 18, 2020 at 03:29:19PM -0400, Selva Nair wrote:
> > If you already have SYSTEM, accessing wintun from openvpn directly will
> > also work and should bring quite a bit of speed improvement.
> 
> I was wrong to assume that this just works. Looking at it again, the current
> implementation of wintun support does not seem to cover this. Meaning the
> only working approach is to use the interactive service.

Indeed, you are right.  Somewhere on the track we lost the ability
to do wintun "from OpenVPN" if we *have* SYSTEM.

This is the code in tun.c

    if (tt->options.msg_channel)
    {
        ret = service_register_ring_buffers(tt);
    }
    else
    {
        msg(M_FATAL, "ERROR:  Wintun requires SYSTEM privileges and therefore "
                     "should be used with interactive service. If you want to "
                     "use openvpn from command line, you need to do SYSTEM "
                     "elevation yourself (for example with psexec).");
    }


... so while I'm happy that we got rid of impersonating SYSTEM, the current
code does not even try anymore, just assumes "if there is no message channel,
we have not enough privileges".

OTOH the message is severely misleading now, since it suggests "having
the right privileges will make this work".


This needs fixing - either we *try*, and if we fail, print the message
about insufficient privileges, or we change the message to actually
print something like "Wintun support is only possible if the interactive
service is used.  Do not run from the CLI.  Use the GUI in non-admin mode.".

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                             ge...@gr...

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Selva N. <sel...@gm...>]

Hi,

On Tue, Aug 18, 2020 at 3:21 PM Gert Doering <ge...@gr...> wrote:

> Hi,
>
> On Tue, Aug 18, 2020 at 12:09:11PM -0700, Marvin Adeff wrote:
> > I???m sorry for the confusing response.
> >
> > Our systems do M2M monitoring and need to run OpenVPN even without a
> user logged in.  In previous versions we created a script run as a service
> (as SYSTEM) that started OpenVPN (using certificates for authentication).
> It also monitored tunnel status and restarted OpenVPN if necessary.  We
> never used the GUI.
> >
> > So we are watching how v2.5 develops to know how we will need to
> implement the new version.  We are also very interested in seeing what
> speed improvements wintun will offer.
> >
> > I hope that is clearer.
>
> Thanks for the clarification.
>
> In that regard, 2.5 will bring no surprises - if you already have SYSTEM
> privileges, and do not want/need a GUI, you can "just run OpenVPN" as
> you did before.
>
> You can do this with your script, or with the "openvpnsrv2" service,
> which basically runs openvpn on all config it finds in its config
> directory at system startup.  Not sure if these instances get restarted
> at exit (last time I looked at this was before 2.4.0 release...).
>
> If you already have SYSTEM, accessing wintun from openvpn directly will
> also work and should bring quite a bit of speed improvement.
>

I was wrong to assume that this just works. Looking at it again, the current
implementation of wintun support does not seem to cover this. Meaning the
only working approach is to use the interactive service.

If developing a new service, I would suggest to have
the service talk to the interactive service for starting openvpn. It will
return you the PID of openvpn.exe which can be monitored. An advantage
of this approach is that your service and openvpn.exe can run with limited
privileges like LOCAL SERVICE or a dedicated openvpn service user.
That said, I don't know anyone who has tested such a usage though it
should work in theory.

Selva

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Gert D. <ge...@gr...>]

Hi,

On Tue, Aug 18, 2020 at 12:09:11PM -0700, Marvin Adeff wrote:
> I???m sorry for the confusing response.  
> 
> Our systems do M2M monitoring and need to run OpenVPN even without a user logged in.  In previous versions we created a script run as a service (as SYSTEM) that started OpenVPN (using certificates for authentication).  It also monitored tunnel status and restarted OpenVPN if necessary.  We never used the GUI. 
> 
> So we are watching how v2.5 develops to know how we will need to implement the new version.  We are also very interested in seeing what speed improvements wintun will offer. 
> 
> I hope that is clearer. 

Thanks for the clarification.

In that regard, 2.5 will bring no surprises - if you already have SYSTEM
privileges, and do not want/need a GUI, you can "just run OpenVPN" as
you did before.

You can do this with your script, or with the "openvpnsrv2" service, 
which basically runs openvpn on all config it finds in its config
directory at system startup.  Not sure if these instances get restarted 
at exit (last time I looked at this was before 2.4.0 release...).

If you already have SYSTEM, accessing wintun from openvpn directly will 
also work and should bring quite a bit of speed improvement.  

The tricky part is "run from an interactive session" where you can get
Administrator privs, but not SYSTEM (unless you play dirty tricks, which
half the virus scanners out there will flag as "MALWARE!")...

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                             ge...@gr...

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Marvin A. <vol...@gm...>]

Hi Gert,

I’m sorry for the confusing response.  

Our systems do M2M monitoring and need to run OpenVPN even without a user logged in.  In previous versions we created a script run as a service (as SYSTEM) that started OpenVPN (using certificates for authentication).  It also monitored tunnel status and restarted OpenVPN if necessary.  We never used the GUI. 

So we are watching how v2.5 develops to know how we will need to implement the new version.  We are also very interested in seeing what speed improvements wintun will offer. 

I hope that is clearer. 

Marvin 

> On Aug 18, 2020, at 11:18 AM, Gert Doering <ge...@gr...> wrote:
> 
> Hi,
> 
> On Tue, Aug 18, 2020 at 08:55:31AM -0700, Marvin Adeff wrote:
>>> An additional check in openvpn.exe whether it's started as SYSTEM could be
>>> useful as well, but less critical, IMO.
>> Yes Please!  We run 2500+ systems that run it this way as SYSTEM.  
> 
> "this way" is quite a bit unclear here - in the thread context,
> "this way" would be "run from the GUI", which never runs as SYSTEM.
> 
> Can you elaborate a bit more how you run OpenVPN?
> 
> 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                             ge...@gr...

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Gert D. <ge...@gr...>]

Hi,

On Tue, Aug 18, 2020 at 08:55:31AM -0700, Marvin Adeff wrote:
> > An additional check in openvpn.exe whether it's started as SYSTEM could be
> > useful as well, but less critical, IMO.
> Yes Please!  We run 2500+ systems that run it this way as SYSTEM.  

"this way" is quite a bit unclear here - in the thread context,
"this way" would be "run from the GUI", which never runs as SYSTEM.

Can you elaborate a bit more how you run OpenVPN?

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                             ge...@gr...

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Selva N. <sel...@gm...>]

>
>
>
> An additional check in openvpn.exe whether it's started as SYSTEM could be
> useful as well, but less critical, IMO.
>
> Yes Please!  We run 2500+ systems that run it this way as SYSTEM.
>

In most such cases (not using the GUI) one could use the automatic service
which runs as SYSTEM. For those running interactively from the command line
(for occasional use),  the logs should already show what's wrong, isn't it?
Anyway, I was not aware of a wide-spread use-case that doesn't rely on one
of the services.

Even with an early error-out it one will have to check the logs (or use the
GUI) to see what went wrong.

Selva

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Marvin A. <vol...@gm...>]

Hi,

> An additional check in openvpn.exe whether it's started as SYSTEM could be
> useful as well, but less critical, IMO.
Yes Please!  We run 2500+ systems that run it this way as SYSTEM.  

Marvin 

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Selva N. <sel...@gm...>]

Hi

On Tue, Aug 18, 2020 at 2:33 AM Gert Doering <ge...@gr...> wrote:

> Hi,
>
> On Tue, Aug 18, 2020 at 08:23:35AM +0200, Gert Doering wrote:
> > This can also happen if you run the GUI with admin privs (because then
> > it will not use the iservice *but* openvpn needs *more* privs than
> > "just administrator", and wintun can not be used at all).
>
> Continueing this thought: I think we might want to abort earlier in
> the OpenVPN startup in this case, that is, "wintun and no iservice pipe".
>

+1 to that. Should be easy to add this check in the GUI.

I think we can also relax the "do not connect to iservice if admin"
restriction
as that was added to protect against some Windows Vista mis-behaviour.

An additional check in openvpn.exe whether it's started as SYSTEM could be
useful as well, but less critical, IMO.

Selva

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Lev S. <lst...@gm...>]

Hi,

> Continueing this thought: I think we might want to abort earlier in
> the OpenVPN startup in this case, that is, "wintun and no iservice pipe".

.. and not running under NT AUTHORITY\SYSTEM.

> Lev, what do you think?

Depends if amount of code to check the above mentioned condition would
outweigh its benefits.

-- 
-Lev

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Gert D. <ge...@gr...>]

Hi,

On Tue, Aug 18, 2020 at 08:23:35AM +0200, Gert Doering wrote:
> This can also happen if you run the GUI with admin privs (because then
> it will not use the iservice *but* openvpn needs *more* privs than
> "just administrator", and wintun can not be used at all).

Continueing this thought: I think we might want to abort earlier in
the OpenVPN startup in this case, that is, "wintun and no iservice pipe".

Lev, what do you think?

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                             ge...@gr...

Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Gert D. <ge...@gr...>]

Hi,

On Tue, Aug 18, 2020 at 12:06:18AM -0300, Rafael Gava wrote:
> 2020-08-17 19:15:39 us=424470 ERROR:  Wintun requires SYSTEM privileges and
> therefore should be used with interactive service. If you want to use
> openvpn from the command line, you need to do SYSTEM elevation yourself
> (for example with psexec).

This can also happen if you run the GUI with admin privs (because then
it will not use the iservice *but* openvpn needs *more* privs than
"just administrator", and wintun can not be used at all).

[..]
> 1) Is there any problem in using openvpn with the wintun interface from an
> unsigned built release?
> 2) Is there any problem with wintun in using an unsigned nsis installer
> than the .msi one?

Not that I'm aware.  This looks more like "iservice not being used due
to admin privs when running the GUI".

You can crosscheck this fairly easy - if wintun does not work with the
message above, try running with the old tun/tap driver.  If that works,
and you see successful "netsh" commands in the log to set up routing, you 
are running with admin privs.

> 3) I'm also trying to generate a msi installer with vagrant msibuilder but
> I'm getting the following error:

I can't say anything about that, sorry...

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                             ge...@gr...

[Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges

[Rafael G. <ga...@gm...>]

Hello Everyone

Could you please give me an insight of what is going here... :-)

I'm trying to use and test the openvpn version 2.5_beta1 with the wintun
interface on a windows 10 machine based on a release built from the source
code.
In order to do that, I'm using the openvpn-vagrant with the
openvpn-build-bionic vm to generate a nsis installer. Well, so far, I'm
building an unsigned release.
After setting the environment variables, downloading the code and running
the ./openvpn-build/windows-nsis/build-complete script, the compilation
completes successfully and an exe file is generated.

In a Windows 10 machine, the installation of this generated exe runs ok but
when I try to connect to a server from the Openvpn-GUI using the wintun
interface, I always get the following error:

2020-08-17 19:15:39 us=419470 Outgoing Data Channel: Using 160 bit message
hash 'SHA1' for HMAC authentication
2020-08-17 19:15:39 us=419470 Incoming Data Channel: Cipher 'BF-CBC'
initialized with 128 bit key
2020-08-17 19:15:39 us=419470 WARNING: INSECURE cipher (BF-CBC) with block
size less than 128 bit (64 bit).  This allows attacks like SWEET32.
Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Support for these insecure ciphers will be removed in OpenVPN 2.6.
2020-08-17 19:15:39 us=419470 Incoming Data Channel: Using 160 bit message
hash 'SHA1' for HMAC authentication
2020-08-17 19:15:39 us=419470 WARNING: cipher with small block size in use,
reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
2020-08-17 19:15:39 us=419470 interactive service msg_channel=0
2020-08-17 19:15:39 us=421471 ROUTE_GATEWAY 10.1.1.1/255.255.0.0 I=10
HWADDR=92:e9:37:4c:bb:99
2020-08-17 19:15:39 us=421471 open_tun
2020-08-17 19:15:39 us=424470 MANAGEMENT: Client disconnected
2020-08-17 19:15:39 us=424470 ERROR:  Wintun requires SYSTEM privileges and
therefore should be used with interactive service. If you want to use
openvpn from the command line, you need to do SYSTEM elevation yourself
(for example with psexec).
2020-08-17 19:15:39 us=424470 Exiting due to fatal error

It seems that the openvpn.exe is unable to open the pipe with the
Interactive Service (interactive service msg_channel=0). If I download and
install the OpenVPN-2.5-beta.msi from the openvpn.net, wintun works
perfectly.

So, now is the point that I'm stuck. What am I doing wrong or missing?

Moreover, I have a couple questions that you guys might help:

1) Is there any problem in using openvpn with the wintun interface from an
unsigned built release?
2) Is there any problem with wintun in using an unsigned nsis installer
than the .msi one?
3) I'm also trying to generate a msi installer with vagrant msibuilder but
I'm getting the following error:

PS O:\windows-msi> cscript build.wsf msi
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

BUILD: tmp\x86\msi.wixobj
RUN: "C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe" -nologo -ext
WixNetFxExtension -arch "x86" -dPRODUCT_PUBLISHER="OpenVPN Technologies,
Inc." -dPRODUCT_NAME="OpenVPN" -dPRODUCT_VERSION="2.5.003"
-dPACKAGE_VERSION="2.5-20200304" -dPRODUCT_TAP_WIN_NAME="TAP-Windows"
-dPRODUCT_TAP_WIN_COMPONENT_ID="tap0901" -dPRODUCT_PLATFORM="x86"
-dPRODUCT_CODE="
{E5931AF4-2A8F-48A5-AFC8-E996BB49D024}"
-dUPGRADE_CODE="{1195A47B-A37A-4055-9D34-B7A691F7E97B}"
-dCONFIG_EXTENSION="ovpn" -dPROGRAM_FILES_DIR="ProgramFilesFolder"
-dOPENSSL_PLAT="" -out "tmp\x86\msi.wixobj" "msi.wxs"
msi.wxs
O:\windows-msi\msi.wxs(724) : error CNDL0104 : Not a valid source file;
detail: 'yes' is an unexpected token. Expecting
white space. Line 724, position 157.

O:\windows-msi\build.wsf(163, 20) Microsoft JScript runtime error: WiX
compiler returned non-zero.

PS O:\windows-msi>

Please, any help is very welcome!

Thanks in Advance

Rafael

Re: [Openvpn-devel] 2.5-beta-1 Windows installer problems

[tincanteksup <tin...@gm...>]

Final update:

So, IPv4 not working was my own error .. sorry for the false alarm.

As for the non-admin user trying to install drivers, this does still happen.

However, what I think is happening is this:

1. Login as admin - install openvpn OK
2. logout/login as normal user
3. Openvpn does "Setting up personal settings for user foo"
4. The installer also asks the user to install TAP and wintun.
5. On Win7 the user is not prompted for admin password so no changes are 
made to the system.

Openvpn then works ipv4 and v6 Tap and wintun.


The same is true for W10 with the exception that: when openvpn is 
uninstalled only either the current user "personal settings" are removed 
or the admin "personal settings" are removed, depending on who is logged 
in at uninstall.

Then the next install does not need to do the "personal settings" for 
the "other" user because they are already there and so the installer 
does not erroneously try to install the drivers again when the user changes.

That is my best guess.

I don't think anybody needs to respond to this thread any further.

Regards
Richard




On 16/08/2020 14:05, tincanteksup wrote:
> I tried this again on a completely fresh Win10 VM.
> 
> The experience was the same, IPv6 works v4 does not.
> 
> When installing as an admin user and then switching to a non-admin, the 
> installation still continues but does ask for admin password.  But the 
> result is still the same, no IPv4.
> 
> Uninstalling and then installing as a non-admin from scratch seems a lot 
> smoother but the final result is the same, no IPv4.
> 
> Summary:
> 
> Win10 install from non-admin seems to be cleanly done but the result is 
> no Ipv4.
> 
> Win10 install as admin user is not so clean.  OpenVPN installer seems to 
> be left in an incomplete state until a non-admin user logs in.  In my 
> opinion, this is not ideal considering the number of single user 
> machines in use.  Microsoft do what they must to protect the system when 
> a single user machine is in use, openvpn should not be so picky..
> 
> Win7 .. same result, no Ipv4.
> 
> Win7 install seems to have the same issues of who is allowed to install 
> openvpn but does a bad job of it, no admin password prompt.
> 
> I know this is a beta so I'm not complaining, only offering feedback
> 
> Regards
> 
> 
> 
> 
> On 15/08/2020 19:31, tincanteksup wrote:
>> Comment inline:
>>
>> On 15/08/2020 19:29, tincanteksup wrote:
>>> Hi,
>>>
>>> I would like to document the very strange issues I had testing the 
>>> 2.5 MSI installers.
>>>
>>> The first test was on a Win7-Ent/32bit VM with 32bit installer.  The 
>>> second test was a real PC with Win7-HomePro/64bit (yeah, user did not 
>>> want w10) 64bit installer. The third test was Win10/64bit VM 64bit 
>>> installer.
>>>
>>> The results were almost identical:
>>>
>>> 1. Logged in as admin user.
>>> 2. Installed over previous installation.
>>>     Completed apparently OK ?
>>> 3. On testing the VPN I found that:
>>>     IPv6 worked (could ping both ways)
>>>     IPv4 did not (could not ping either way)
>>>     Firewall disabled. Dual stack VPN.
>>> 4. Logged out/Logged in as normal user.
>>> 5. OpenVPN Installer forced a re-install of the TAP/wintun drivers.
>>>     The user could select "do not install" but the installer was 
>>> auto-run.
>>
>> I did "Install" the drivers as non-admin user and was *not* prompted 
>> for admin password.
>>
>>
>>>     The user was *not* prompted for admin password.
>>> 6. Using the same VPN config as above, the VPN now functions correctly.
>>>
>>> The only difference was that on Win10 I could not test logging back 
>>> in as a standard user because my VM could not be activated.
>>>
>>> I do not know where would be the bast place to raise these issues and 
>>> so sent my feedback to the list for further consideration.
>>>
>>> Regards
>>> Richard

[Openvpn-devel] [PATCH applied] Re: Improve the documentation for --dhcp-option

[Gert D. <ge...@gr...>]

Acked-by: Gert Doering <ge...@gr...>

Thanks!

Your patch has been applied to the master and release/2.5 branch.

commit 2da29362cc93aa1b8c24386e162b9cdd3b55c3b1 (master)
commit 64f0b1c07e1d4579cdb3d6a9df27555071c1ed04 (master)
Author: Selva Nair
Date:   Sun Aug 16 15:06:39 2020 -0400

     Improve the documentation for --dhcp-option

     Signed-off-by: Selva Nair <sel...@gm...>
     Acked-by: Gert Doering <ge...@gr...>
     Message-Id: <159...@gm...>
     URL: https://www.mail-archive.com/ope...@li.../msg20759.html
     Signed-off-by: Gert Doering <ge...@gr...>


--
kind regards,

Gert Doering

[Openvpn-devel] [PATCH v2] Improve the documentation for --dhcp-option

[<sel...@gm...>]

From: Selva Nair <se...@ga...>

- Stress that these are handled internally only on some platforms
- Correct the statement about wintun 
- Document DOMAIN-SEARCH

Signed-off-by: Selva Nair <sel...@gm...>
---
v2: Rebase to master and reword to match the new rst version
    Add doc for DOMAIN-SEARCH

 doc/man-sections/vpn-network-options.rst | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/doc/man-sections/vpn-network-options.rst b/doc/man-sections/vpn-network-options.rst
index 7100c1ae..825dd1ca 100644
--- a/doc/man-sections/vpn-network-options.rst
+++ b/doc/man-sections/vpn-network-options.rst
@@ -93,12 +93,18 @@ routing.
   or :code:`tap`.
 
 --dhcp-option args
-  Set additional network settings via DHCP.  On Windows, this is parsed by
-  the ``tap-windows6`` or ``wintun`` driver.  On other platforms these
-  options can be picked up by an ``--up`` script or plug-in if it has been
-  pushed by the OpenVPN server.  The option will then be saved in the
-  client's environment before the ``--up`` script is called, under the name
-  :code:`foreign_option_{n}`.
+  Set additional network parameters on supported platforms. May be specified
+  on the client or pushed from the server. On Windows these options are
+  handled by the ``tap-windows6`` driver by default or directly by OpenVPN
+  if dhcp is disabled or the ``wintun`` driver is in use. The
+  ``OpenVPN for Android`` client also handles them internally.
+
+  On all other platforms these options are only saved in the client's
+  environment under the name :code:`foreign_options_{n}` before the
+  ``--up`` script is called. A plugin or an ``--up`` script must be used to
+  pick up and interpret these as required. Many Linux distributions include
+  such scripts and some third-party user interfaces such as tunnelblick also
+  come with scripts that process these options.
 
   Valid syntax:
   ::
@@ -108,6 +114,11 @@ routing.
   :code:`DOMAIN` ``name``
         Set Connection-specific DNS Suffix to :code:`name`.
 
+  :code:`DOMAIN-SEARCH` ``name``
+        Add :code:`name` to the domain search list.
+        Repeat this option to add more entries. Up to
+        10 domains are supported.
+
   :code:`DNS` ``address``
         Set primary domain name server IPv4 or IPv6 address.
         Repeat this option to set secondary DNS server addresses.
-- 
2.17.1

Re: [Openvpn-devel] 2.5-beta-1 Windows installer problems

[tincanteksup <tin...@gm...>]

I tried this again on a completely fresh Win10 VM.

The experience was the same, IPv6 works v4 does not.

When installing as an admin user and then switching to a non-admin, the 
installation still continues but does ask for admin password.  But the 
result is still the same, no IPv4.

Uninstalling and then installing as a non-admin from scratch seems a lot 
smoother but the final result is the same, no IPv4.

Summary:

Win10 install from non-admin seems to be cleanly done but the result is 
no Ipv4.

Win10 install as admin user is not so clean.  OpenVPN installer seems to 
be left in an incomplete state until a non-admin user logs in.  In my 
opinion, this is not ideal considering the number of single user 
machines in use.  Microsoft do what they must to protect the system when 
a single user machine is in use, openvpn should not be so picky..

Win7 .. same result, no Ipv4.

Win7 install seems to have the same issues of who is allowed to install 
openvpn but does a bad job of it, no admin password prompt.

I know this is a beta so I'm not complaining, only offering feedback

Regards




On 15/08/2020 19:31, tincanteksup wrote:
> Comment inline:
> 
> On 15/08/2020 19:29, tincanteksup wrote:
>> Hi,
>>
>> I would like to document the very strange issues I had testing the 2.5 
>> MSI installers.
>>
>> The first test was on a Win7-Ent/32bit VM with 32bit installer.  The 
>> second test was a real PC with Win7-HomePro/64bit (yeah, user did not 
>> want w10) 64bit installer. The third test was Win10/64bit VM 64bit 
>> installer.
>>
>> The results were almost identical:
>>
>> 1. Logged in as admin user.
>> 2. Installed over previous installation.
>>     Completed apparently OK ?
>> 3. On testing the VPN I found that:
>>     IPv6 worked (could ping both ways)
>>     IPv4 did not (could not ping either way)
>>     Firewall disabled. Dual stack VPN.
>> 4. Logged out/Logged in as normal user.
>> 5. OpenVPN Installer forced a re-install of the TAP/wintun drivers.
>>     The user could select "do not install" but the installer was 
>> auto-run.
> 
> I did "Install" the drivers as non-admin user and was *not* prompted for 
> admin password.
> 
> 
>>     The user was *not* prompted for admin password.
>> 6. Using the same VPN config as above, the VPN now functions correctly.
>>
>> The only difference was that on Win10 I could not test logging back in 
>> as a standard user because my VM could not be activated.
>>
>> I do not know where would be the bast place to raise these issues and 
>> so sent my feedback to the list for further consideration.
>>
>> Regards
>> Richard

[Openvpn-devel] [PATCH applied] Re: Changes.rst: fix mistyped option names

[Gert D. <ge...@gr...>]

Your patch has been applied to the master and release/2.5 branch.

commit bf911882532f87ae866fc3662bf7e1e136a2195e (master)
commit edc02b3be8fc50760df3e41438339759c45bfb23 (release/2.5)
Author: Magnus Kroken
Date:   Sat Aug 15 14:05:21 2020 +0200

     Changes.rst: fix mistyped option names

     Signed-off-by: Magnus Kroken <mk...@gm...>
     Acked-by: Gert Doering <ge...@gr...>
     Message-Id: <202...@gm...>
     URL: https://www.mail-archive.com/ope...@li.../msg20749.html
     Signed-off-by: Gert Doering <ge...@gr...>


--
kind regards,

Gert Doering

[Openvpn-devel] [PATCH applied] Re: doc: fix typos in cipher-negotiation.rst

[Gert D. <ge...@gr...>]

Your patch has been applied to the master and release/2.5 branch.

commit e33f44754a5f81ea013070dba3cdc162f41d1257 (master)
commit 4764868240ed215c91de659c742c393ebb602eeb (release/2.5)
Author: Magnus Kroken
Date:   Sat Aug 15 14:05:22 2020 +0200

     doc: fix typos in cipher-negotiation.rst

     Signed-off-by: Magnus Kroken <mk...@gm...>
     Acked-by: Gert Doering <ge...@gr...>
     Message-Id: <202...@gm...>
     URL: https://www.mail-archive.com/ope...@li.../msg20748.html
     Signed-off-by: Gert Doering <ge...@gr...>


--
kind regards,

Gert Doering