Opened 6 years ago
Closed 15 months ago
#905 closed Bug / Defect (fixed)
User cannot use openvpn
Reported by: | hildeb | Owned by: | Selva Nair |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Generic / unclassified | Version: | OpenVPN 2.4.0 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | Selva Nair |
Description
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
Change History (12)
comment:1 Changed 6 years ago by
comment:2 Changed 6 years ago by
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?
comment:4 Changed 6 years ago by
Cc: | Selva Nair added |
---|
comment:5 Changed 6 years ago by
# 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>
comment:6 Changed 5 years ago by
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.
comment:7 Changed 5 years ago by
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.
comment:8 Changed 5 years ago by
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. :)
comment:9 Changed 5 years ago by
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? :)
comment:10 Changed 2 years ago by
Owner: | set to Selva Nair |
---|---|
Status: | new → assigned |
Came across this ticket today, searching for something else.
@selva, has this ever been integrated? Anything left to be done here?
comment:11 Changed 2 years ago by
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.
You could try increasing the log verbosity.