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

2020-08-17 Thread Gert Doering
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 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


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

2020-08-17 Thread Gert Doering
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 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] 2.5-beta-1 Wintun requires SYSTEM privileges

2020-08-17 Thread Rafael Gava
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
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


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

2020-08-17 Thread tincanteksup

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