Re: [Openvpn-devel] 2.5-beta-1 Wintun requires SYSTEM privileges
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
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
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
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