Opened 7 years ago

Closed 4 years ago

#823 closed Bug / Defect (fixed)

openvpn-gui 2.4 need administrative privilege at first connection only

Reported by: r2d42 Owned by: Selva Nair
Priority: major Milestone: release 2.4.9
Component: Windows GUI Version: OpenVPN 2.4.0 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: windows, gui
Cc:

Description

Windows 10 Pro
openvpn 2.4
installer openvpn-install-2.4.0-I601.exe

The first connection after installation fail with the following error:

open_tun
TAP-WIN32 device [Ethernet] opened: \\.\Global\{93D4B60C-EFCC-421C-9675-70A8ADF3F0A3}.tap
NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
ERROR: netsh command failed: returned error code 1
NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
ERROR: netsh command failed: returned error code 1
NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
ERROR: netsh command failed: returned error code 1
NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
ERROR: netsh command failed: returned error code 1
NETSH: command failed
Exiting due to fatal error

Starting openvpn-gui with administrative privileges can successfully connect,
after that, the client can work without problem also without administrative privileges.

log of the administrative connection:

open_tun
TAP-WIN32 device [Ethernet] opened: \\.\Global\{93D4B60C-EFCC-421C-9675-70A8ADF3F0A3}.tap
NETSH: C:\WINDOWS\system32\netsh.exe interface ip set address Ethernet dhcp
Set TAP-Windows TUN subnet mode network/local/netmask = 172.20.37.0/172.20.37.2/255.255.255.0 [SUCCEEDED]
Notified TAP-Windows driver to set a DHCP IP/netmask of 172.20.37.2/255.255.255.0 on interface {93D4B60C-EFCC-421C-9675-70A8ADF3F0A3} [DHCP-serv: 172.20.37.254, lease-time: 31536000]
Successful ARP Flush on interface [10] {93D4B60C-EFCC-421C-9675-70A8ADF3F0A3}
do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Initialization Sequence Completed

Change History (10)

comment:1 Changed 7 years ago by Gert Döring

This can only happen if something else has turned off DHCP on the tap adapter beforehand - which is not something OpenVPN should normally ever do (it can happen if you run openvpn with administrative privileges and set --ip-win32 ipapi), and which is not done on installation.

And indeed, this is a bit of a nuisance, but I'm not sure we can do something about it - we could add the "activate DHCP!" bit to the interactive service, but this really is a "you have changed settings with admin privileges before, so you need admin privileges to change it back" situation. On a fresh install (including initial installation of the TAP driver), you'd never see this.

comment:2 Changed 7 years ago by r2d42

I'll try it on a windows fresh installation and come back with the results.

comment:3 Changed 7 years ago by Selva Nair

If this issue can happen anytime someone uses --ip-win32 ipapi as admin followed by a connection using interactive service (i.e limited user), then this is more than a nuisance.

But in my tests, after setting IP using --ipapi the interface shows (using netsh)

Configuration for interface "Adapter1"
    DHCP enabled:                         Yes
    IP Address:                           10.8.0.18
    Subnet Prefix:                        10.8.0.16/30 (mask 255.255.255.252)
    InterfaceMetric:                      5

So dhcp stays enabled (no idea what that exactly means as ip was set statically). And, subsequent connection using dhcp (as limited user) does succeed.

But if an ip address is manually set on the adapter, DHCP enabled changes to "no" and the error reported by r2d42 is reproduced.

We could implement dhcp mode setting through interactive service.

comment:4 Changed 7 years ago by Selva Nair

Using --ip-win32 netsh as admin does disable dhcp. I think while closing tun we could/should reset the adapter to use dhcp in such cases.

comment:5 in reply to:  4 Changed 7 years ago by Gert Döring

Replying to selvanair:

Using --ip-win32 netsh as admin does disable dhcp. I think while closing tun we could/should reset the adapter to use dhcp in such cases.

Ah, that's the one I remembered. Sorry for the ipapi confusion.

Do we detect "interface is set to DHCP?" today? If yes, restoration to the original setup would certainly the right thing to do. If we do not know what the DHCP state was when we started, shall we still set to "DHCP"?

(Are there any benefits on Vista+ in using netsh as compared to ipapi? Maybe that code path should just go...)

comment:6 Changed 7 years ago by Selva Nair

When user says --ip-win32 netsh we do remove any prior address on the interface so resetting it to use dhcp on tun-close looks acceptable to me.

We do check the DHCP state first but I think its not saved. But I do think we should just get rid of the netsh option -- I have seen AddIpAddress() (API call) failures only when the address exists on some interface. In such cases netsh also fails. An advantage of AddIpAddress() is that it adds a temporary address unlike netsh.

That said, a couple of things (IMHO:)

(i) We put so much effort into get this non-privileged mode working nicely on Windows, so its a pity to error-out trying to set the interface to use dhcp. This should be fixed.

(ii) We have too many options exposed to the user in --ip-win32. That whole option could be deprecated. Default to auto = dynamic or adaptive. Manual method is already handled by ifconfig-noexec. The code should figure out how best to set the address on an interface, not the user (say prefer dhcp if that fails ipapi via service). Power users can always use --ifconfig-noexec + a script.

(iii)We do re-write route-method to use service if interactive service is in use no matter what the user specified; re-writing ip-win32 to dynamic (unless manual is specified) with service helping when needed looks like the smart thing to do.

Version 0, edited 7 years ago by Selva Nair (next)

comment:7 Changed 7 years ago by tct

CC

comment:8 Changed 4 years ago by Gert Döring

Milestone: release 2.4.0release 2.4.9
Owner: set to Selva Nair
Status: newassigned

It seems that we managed to have two trac tickets on the same issue - so this one got fixed as a side effect of fixing #1111 :-)

commit 78d4f0ad106720d8988e144f6d30ec11d84dee2f (release/2.4)
Author: Selva Nair <selva.nair@…>
Date: Tue Oct 2 16:01:13 2018 -0400

Enable dhcp on tap adapter using interactive service


Currently, if dhcp on the TAP interface is disabled, OpenVPN
on Windows tries to enable it using netsh but that succeeds only when
run with admin privileges.


When interactive service is available, delegate this task to the
service.


Trac: #1111
Tested on Windows 7

@Selva: do you want to keep this ticket as a reminder that you wanted do more work on (ii) and (iii) or do we consider the GUI and iservice changes "good enough for now" and close it?

comment:9 Changed 4 years ago by Selva Nair

If we have a wish-list for 2.5 let's add "simplify ip-win32 options" to it and close this.

comment:10 Changed 4 years ago by Selva Nair

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.