User cannot use openvpn

[hildeb]

The log only consists of:

Tue Jun 20 10:00:53 2017 OpenVPN 2.4.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on May 11 2017
Tue Jun 20 10:00:53 2017 Windows version 6.1 (Windows 7) 64bit
Tue Jun 20 10:00:53 2017 library versions: OpenSSL 1.0.2k  26 Jan 2017, LZO 2.10
Enter Management Password:
Tue Jun 20 10:00:53 2017 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Tue Jun 20 10:00:53 2017 Need hold release from management interface, waiting...
Tue Jun 20 10:00:54 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Jun 20 10:01:05 2017 MANAGEMENT: Client disconnected
Tue Jun 20 10:03:15 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Jun 20 10:03:37 2017 MANAGEMENT: Client disconnected
Tue Jun 20 10:03:56 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Jun 20 10:04:24 2017 MANAGEMENT: Client disconnected
Tue Jun 20 10:04:36 2017 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Tue Jun 20 10:04:58 2017 MANAGEMENT: Client disconnected

[tct]

You could try increasing the log verbosity.

[hildeb]

So what happens is this: The GUI cannot connect to the openvpn process by means of the management interface.

All I see is "client connected from [AF_INET]127.0.0.1:25340" and 56seconds later "Client disconnected"

But I can connect to locahost:25340, and am greeted with a dialog asking me to enter the management password (which I don't know).

So why won't the GUI connect properly?

[tct]

Please post your client config file.

Do you require --askpass ?

[hildeb]

# Konfiguration fuer Charite-OpenVPN
client
dev tun

<connection>
proto udp
remote openvpn.charite.de
port 1194
explicit-exit-notify
nobind
</connection>

<connection>
proto udp
remote 193.175.73.200
port 1194
explicit-exit-notify
nobind
</connection>

<connection>
proto tcp
remote openvpn.charite.de
port 1194
</connection>

<connection>
proto tcp
remote 193.175.73.200
port 1194
</connection>

resolv-retry infinite

cipher AES-256-CBC
auth SHA256
remote-cert-tls server
verify-x509-name 'C=DE, ST=Berlin, L=Berlin, O=Charite-VPN, OU=GB-IT, CN=openvpn.charite.de, emailAddress=vpn@charite.de' subject
remote-cert-eku "TLS Web Server Authentication"

persist-key
persist-tun
comp-lzo
verb 4
reneg-sec 0
auth-user-pass
auth-nocache
script-security 2
mute-replay-warnings

key-direction 1
<tls-auth>
...
</tls-auth>


<ca>
...
</ca>

<key>
</key>

<cert>
...
</cert>

[krm]

Recently I saw this problem quite often with different versions of Windows (7,8,10 - we have hundreds of OpenVPN users) and different versions of OpenVPN Client (from 2.4.3 to 2.4.6). What I found out is that this happens when process openvpn.exe did not terminate when terminating the last OpenVPN connection. Mostly it suffices to terminate the process (once I even saw two processes openvpn.exe which I both terminated). Sometimes then it still doesn't work and log window is completeley white then. In this case I deactived and activated the TAP network adapter and then it worked again.

So what's clear then is that reboot also helps. The bad thing is that this situation not only comes up when a windows computer has not been shutdown for months (only put to sleep). It sometimes already happens when you try to connect the second time.

I don't think that our configuration is important to debug this but anyway here it is:
httpS://www.scc.kit.edu/scc/net/openvpn/os/windows/kit.ovpn

I actually don't think that this is related to #1051.

Please tell me if you need more information.

[Selva Nair]

As you suspected, most likely this is due to a stale openvpn process running with management interface listening on the same port as what the GUI is trying to use for a new instance.

All I see is "client connected from [AF_INET]127.0.0.1:25340" and 56seconds later "Client disconnected"

I have seen such behaviour only when debugging after breaking the GUI code in some bad way :)

But I can connect to locahost:25340, and am greeted with a dialog asking me to enter the management password (which I don't know).

This shows openvpn is running with no management client connected (the GUI in this case). Else it will not prompt for the management password as only one client at a time is supported by that interface. If, for some reason, the GUI fails to connect to the MI and leaves the process running, then there is no way for it to connect back to it as the password is promptly cleared from memory.

In such cases, any further attempts to start openvpn should fail with an error like "socket bind failed on 127.0.0.1:25340" as the port will be in use. But even that the log could be lost as the running process may hold a write lock on the log file.

Although the GUI tries hard to stop openvpn.exe (or kill, if necessary) on disconnect, the patched version I had linked to in #1051 tries even harder. Here is a direct link to the executable.

​​https://github.com/selvanair/openvpn-gui/releases/download/mgmt-timeout/openvpn-gui-timeout.exe

Though this issue is unrelated to 1051, the above patch may help -- could you please test whether it makes a difference? Make sure any running instances of openvpn are killed before starting this GUI. Also ensure openvpnservice or openvpnservicelegacy are not running and openspnserviceinteractive is running -- that is the default.

[krm]

Thanks for your explanations. That makes sense that trying harder to kill could help. I will try to find persons who can test it. It will take some time until I can come back to you with results. I hope it will help. :)

[krm]

Hi again, there was only feedback from one person. She experienced the issue very often, but with selvanair's binary she never had the issue again. Any chance to get this upstream? :)

[Gert Döring]

Came across this ticket today, searching for something else.

@selva, has this ever been integrated? Anything left to be done here?

[Selva Nair]

Somehow this never got into the repo. Originally the patch was made to address #1050, but that turned out to be due to two independent issues: slow access to the DC and management interface port conflict.

However, there is no need to give up on the management interface connection unless OpenVPN process itself dies to fails to start. So, this patch is still useful. I'll revive it.

[Selva Nair]

Fixed by ​PR418.