Silent failure of PLAP on adding management password #567
Comments
|
Moved to a new issue --- #77 was about a feature request that has been completed and closed. Better to open new issues for reporting errors like this or to request improvements. Based on what you describe, my guess would be: you added the password, restarted the service, then edited the password file and did not restart the service again. That would lead to a management password mismatch and the only error would be in the event log. We should probably show an error popup for this --- iirc, there was some reason not to, but I'll reconsider. At least we've to return a relevant reason for failure to PLAP screen.
OpenVPN daemon for persistent connections is started by OpenVPNService and it must log something to the log file --- even if the startup failed for some reason. I guess you mean that the log file does not show anything related to the failure of PLAP or GUI. That would be the case if the connection to management interface failed due to management password mismatch -- in that case GUI/PLAP logs a warning to Windows EventLog. Restart OpenVPNService and check the log file in BTW, unlike user configs, you have to always restart OpenVPNService after editing a config file in |
@selvanair I have restarted the OpenVPNService and tested again with OpenVPN GUI and PLAP: the same behavior as mentioned before. On the log file of the config I only see 3 lines with OpenVPN version, OS version and OpenSSL version... Can't find any warning logged to the EventLog (only that the service stopped and started again)... :( If I connect using telnet it asks for a password and connects if correct password is provided... I'm using last OpenVPN 2.6 Beta2... |
|
Your config may have verb < 3. If you increase that to 3 (or better 4 for testing) and restart the service you will see more in logs -- like management port being listened on and that its waiting for username/password from management. Then when you connect using telnet, GUI or PLAP it should log a line showing connected to management client and when the client disconnects. The only reason I can think of is password mismatch (like the passwd.txt file may have some hidden characters, wrong encoding etc.. ). Keep password pure ascii to avoid such issues. But even then the GUI should log to EventLog. Anyway, try removing the password so that you can confirm that you have a working configuration. If adding 'passwd.txt' is the only change to a working setup I can't see how this could happen. |
@selvanair I now added 2022-12-22 09:49:41 us=640000 OpenVPN 2.6_beta2 [git:none/566c0791caddc52e] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Dec 15 2022 I can connect to the management interface with telnet using the password set on 'passwd.txt'
If I remove the 'passwd.txt' the configuration works and log file shows: 2022-12-22 09:59:07 us=937000 OpenVPN 2.6_beta2 [git:none/566c0791caddc52e] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Dec 15 2022 I also have checked that 'passwd.txt' is ANSI encoded (I think this also can't be the problem because authentication over telnet works). If I copy my config to the I also have found another problem with OpenVPN GUI: if there is no opvn profile on the |
In that case passwd.txt is not used as the GUI sets it own random password for non-persistent connections
I cannot reproduce this. See image below with only persistent profiles: But the opposite is possible: i.e., if you have the same config in config-auto and config, only the latter will show up. Always use unique file names for configs. This is something that could be improved, but its not an easy fix. Back to your issue with PLAP, I'm out of ideas. Looking at the logs it shows PLAP or GUI connects to the management and immediately disconnects. The only reason I can think of is password mismatch but that should log to EventLog. Do you mind sharing the config and passwd.txt (you can replace the password with something simple)? The certificates and key can be removed from the config as I only need to test startup. Preferably, share as an archive (say zip) so that the files and their encoding are preserved. |
|
Hi @selvanair I think I have found the problem: after changing the password on 'passwd.txt' to prepare the file for sending it to you, this worked! Regarding the OpenVPN GUI showing the persistent connections, it only shows it when one profile connects successfully. If there is a problem (like my case), then the OpenVPN GUI doesn't show the sub-menu for persistent connections. Thanks again for your help! |
|
That's a bug. Now that we allow user to set management password through a file, we have to support longer passwords. Will fix.
I tested using a long password. The config does still show up in the menu and continues to show even though connection attempts fail. Even when there are no other configs. Also, I do get a warning in the EventLog saying management password mismatch. Please check again -- in the event log look for OpenVPN-GUI as the source. Once the event is found, you have to go to its details tab to see the actual error. The GUI should ignore a persistent config only if parsing the config fails as that could be legitimate -- like an admin sets restrictive permissions to block users from accessing these configs. Otherwise it should show up in the menu even if the connection cannot be successfully completed. If there is only one config in total, the GUI always uses an alternate format for the menu where connect/disconnect etc are directly displayed in the main menu with no config-specific sub-menus. This has always been the case. |
|
Thanks @selvanair! Please ignore the OpenVPN GUI problem, this was a fault on my side, it works now correctly... Merry Christmas! :) |
As we now allow users to set a management password (for persistent connections), the max size of password should match what openvpn.exe can handle (128 or 4096 bytes depending on build options). Increase the buffer size to 4096 though such large passwords may not work in practice. 127 bytes + NUL, may be a safe upper limit. For the random password used for connections spawned by the GUI, the current size of 15 bytes + NUL is retained. Fixes: OpenVPN#567 Signed-off-by: Selva Nair <selva.nair@gmail.com>
As we now allow users to set a management password (for persistent connections), the max size of password should match what openvpn.exe can handle (128 or 4096 bytes depending on build options). Increase the buffer size to 4096 though such large passwords may not work in practice. 127 bytes + NUL, may be a safe upper limit. For the random password used for connections spawned by the GUI, the current size of 15 bytes + NUL is retained. Fixes: #567 Signed-off-by: Selva Nair <selva.nair@gmail.com>
Now that I would like to test it on our corporate environment, I have added a password file to the management interface like this:
management 127.0.0.1 8888 passwd.txtThe passwd.txt file has one line with the management interface password. I've copied the file to the same path as the ovpn (C:\Program Files\OpenVPN\config-auto), but after this, I can see the PLAP on Windows Logon screen and when I choose the ovpn profile it doesn't ask any username/password (or any OpenVPN window) and immediately shows that the connection failed.
If I try to start the connection with the OpenVPN GUI then I see a quick window opening and closing again. Log file does not log anything.
If I remove the passwd.txt parameter from the management configuration, it works like expected.
Am I missing something or doing something wrong?
Thanks again for all you work for making this PLAP a reality! :)
Originally posted by @gitnewcomer in #77 (comment)
The text was updated successfully, but these errors were encountered: