client management interface user authentication abort inconsistency

[bwess]

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.

[Samuli Seppänen]

Tried to reproduce this on Ubuntu 12.10 but failed. I appended the following to a known-good config:

management 127.0.0.1 9544
management-query-passwords
management-hold
auth-user-pass
auth-retry interact

This freezes the OpenVPN process until I issue "hold release" using telnet:

$ telnet 127.0.0.1 9544
... management interface output ---
hold release
... prompts for credentials ...

At this point I gave the OpenVPN process a SIGHUP as root:

$ kill -s SIGHUP <process-id>

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.

[Samuli Seppänen]

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.

[_bt]

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

[_bt]

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

[Gert Döring]

Can someone re-test this on 2.5 or 2.6_beta2? A number of management interface state fixes have been merged in the past 8 years, so it might have been fixed, or not...

[Selva Nair]

This has been "always" like this on all platforms, not just on Windows. Management-hold is not required to trigger this either. Just try to abort the user/pass query to management interface by signal SIGUSR1 signal SIGHUP, and the process exits (M_FATAL)instead of restarting.

What has changed over the years on Windows is that openvpnsev2 is better at restarting the daemon, so openvpn.exe does get restarted in about 10 seconds.

In fact our persistent and PLAP connections show this behaviour -- if user aborts the user/pass dialog, we send a SIGHUP and detach causing the process to exit and then gets restarted by the service.

An option is to not send SIGUSR1 or SIGHUP to get back into hold, but just detach from the management interface. Then the daemon will wait in the user/pass query state which is very much like management-hold and will prompt for it again when the management client connects next time.