Opened 17 months ago

Last modified 14 months ago

#823 new Bug / Defect

openvpn-gui 2.4 need administrative privilege at first connection only

Reported by: r2d42 Owned by:
Priority: major Milestone: release 2.4.0
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 (7)

comment:1 Changed 17 months 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 17 months ago by r2d42

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

comment:3 Changed 17 months ago by selvanair

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 17 months ago by 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.

comment:5 in reply to:  4 Changed 17 months 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 17 months ago by selvanair

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 fall back to 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.

Last edited 17 months ago by selvanair (previous) (diff)

comment:7 Changed 14 months ago by tincantech

CC

Note: See TracTickets for help on using tickets.