Opened 10 years ago
Last modified 7 years ago
#131 new Bug / Defect
client management interface user authentication abort inconsistency
Reported by: | bwess | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Management | Version: | OpenVPN 2.3.1 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | management windows |
Cc: |
Description
Setup:
- OpenVPN client on Windows started by the OpenVPN service wrapper
- Configuration with auth-user-pass, management-hold, management-query-passwords and auth-retry interact
Demo:
- telnet to the management port
- enter hold release (you are queried for username/password)
- change your mind (imagine pressing cancel instead of ok in a GUI)
- enter signal SIGHUP or signal SIGUSR1
Result:
The OpenVPN process exits. This Shouldn't Happen(tm). It even happens if you complete entering username and password but enter the signal within a certain time frame.
Change History (5)
comment:1 Changed 8 years ago by
Keywords: | management added |
---|
comment:2 Changed 8 years ago by
Priority: | major → minor |
---|
Indeed, this is reproduceable on Windows 7. First you need to install telnet. Next, launch OpenVPN from an administrator command-prompt or Git bash, e.g.
$ cd /c/Program\ Files/OpenVPN/config $ ../bin/openvpn.exe --config openvpn.ovpn
OpenVPN is now waiting for the management "hold release" command. Once that command is issued (see above), it asks for credentials. Now, instead of giving it the credentials return to the other command-prompt with OpenVPN and press F3 (HUP). This kills the OpenVPN process as reported.
OpenVPN 2.3.1 man-page says this:
SIGHUP Cause OpenVPN to close all TUN/TAP and network connections, restart, re-read the configuration file (if any), and reopen TUN/TAP and network connections.
So, the observed behavior is not consistent with what the man-page says.
I'm not sure what the actual impact is, i.e. is there a real-life situation where this could be a serious problem. Also, the problem seems to be reproduceable only on Windows, but not on Linux. Changing priority to minor for now.
comment:3 Changed 7 years ago by
Component: | Generic / unclassified → Management |
---|---|
Keywords: | windows added |
Version: | 2.2.0 → 2.3.1 |
comment:4 Changed 7 years ago by
Hello,
This is still a problem on version 2.3.2. In fact, OpenVPN exits no matter what signal you send it (SIGUSR1/2/SIGHUP). There doesn't seem to be a way to put OpenVPN back in a fresh state using the management interface when this state is reached - do you have any workarounds?
Regards
comment:5 Changed 7 years ago by
Log:
Thu Apr 03 10:26:42 2014 us=918722 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Thu Apr 03 10:26:42 2014 us=934350 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:7505
Thu Apr 03 10:26:42 2014 us=934350 Need hold release from management interface, waiting...
Thu Apr 03 10:26:50 2014 us=698922 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:7505
Thu Apr 03 10:26:54 2014 us=682783 MANAGEMENT: CMD 'hold release'
Thu Apr 03 10:26:59 2014 us=978929 MANAGEMENT: CMD 'signal SIGHUP'
Thu Apr 03 10:26:59 2014 us=978929 MANAGEMENT: Client disconnected
Thu Apr 03 10:26:59 2014 us=978929 ERROR: could not read Auth username/password/ok/string from management interface
Thu Apr 03 10:26:59 2014 us=978929 Exiting due to fatal error
Tried to reproduce this on Ubuntu 12.10 but failed. I appended the following to a known-good config:
This freezes the OpenVPN process until I issue "hold release" using telnet:
At this point I gave the OpenVPN process a SIGHUP as root:
This does not kill the OpenVPN process. Is this the correct sequence of steps, or did I misunderstand something? What does "change your mind" mean exactly?
I'll retry this on Windows 7 to see if this is specific to that platform.