core
core copied to clipboard
opnsense
Allow OpenVPN client to read username and password from management interface
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
- [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
Is your feature request related to a problem? Please describe.
Dynamic passwords are not supported by the current OpenVPN client implementation. I understand that his is not easy with the current implementation structure. If there is an option to get the username and password from the OpenVPN management interface in client mode, then it is easy to write a service that listens at the interface to provide username and password if OpenVPN requests it.
Describe the solution you like A simple patch like this would allow to get the username and password from the management interface, if the user name and password are "$management". No GUI change is required. The feature is only for people that implement a corresponding OpenVPN management interface listener.
OpenVPN.php:
if (!empty((string)$node->username) && !empty((string)$node->password)) {
if ((string)$node->username == '$management' && (string)$node->password == '$management') {
$options['auth-user-pass'] = null;
$options['management-query-passwords'] = null;
$options['auth-nocache'] = null;
}
else {
$options['auth-user-pass'] = [
"filename" => "/var/etc/openvpn/instance-{$node_uuid}.up",
"content" => "{$node->username}\n{$node->password}\n"
];
}
}
Describe alternatives you considered Allow to use OTP passwords in OpenVPN for clients.
Additional context
Thank you for creating an issue. Since the ticket doesn't seem to be using one of our templates, we're marking this issue as low priority until further notice.
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
The easiest option to gain traction is to close this ticket and open a new one using one of our templates.
I'm not against adding options, but it should be very clear how people should use them and don't abuse existing fields.
Ok, the official version would be to add a check mark in the GUI for this option and to write a help text. But I see the problem, that if you enable this option and the server is requesting a password it will hang, until you implement the service. If the option is "hidden" the you could not enable it by accident. An what about simply adding a comment to the help text of username and password?
What about adding management-query-passwords, auth-user-pass and auth-nocache to the VPN options field?
Maybe with the restriction that management-query-passwords and auth-user-pass is only allowed, if no username and password is specified?
the more important question is how people are supposed to use this "new" feature....
This is only possible by adding a service that opens the existing management interface and listens for incoming requests. This is why I wanted to "hide" the feature, because you can't use ist without adding custom code.
Then its unlikely we should add it as a feature as we can't explain how and why people should use it.
My basic problem is, that OTP is not supported for client connections and it's not possible any more to add custom options. Implementing OTP for clients connection would be the correct solution.
Without a way for others to use a feature, we're not planning to add it. You can always use our documented hooks to start a manual openvpn process for example or build a custom plugin for internal use.
What about adding the auth-nocache option? At the moment I am already using a custom plugin, but I have to invalidate the password now via the management interface. With this option things would be easier ...
it might be better to open a ticket describing which problem you would like to solve, I don't mind adding options which are usable for others, as long as it's clear which scenario they should be used in.
If the password is fixed the option basically makes not much sense, only if you want to modify the password. I could only argument, that for "safety reasons" it's not good to keep the password in memory ...
Suricata allow to add custom options in /usr/local/opnsense/service/templates/OPNsense/IDS/custom.yaml.
If you could provide also a custom options file for OpenVPN this would solve all problems ...
... I could only argument, that for "safety reasons" it's not good to keep the password in memory
For a client which stores its password on the same machine that wouldn't make much sense I suppose.
If you could provide also a custom options file for OpenVPN this would solve all problems ...
OpenVPN doesn't support include directives...
OpenVPN doesn't support include directives...
This is true, but OpenVPN.php could call a custom script (if present) at the end, as a hook to allow modification of the created files.
At the moment we don't plan to add pluggable hooks there, also to avoid hard to support community support cases.
My current solution is to permanently update automatically the OpenVPN settings from a script but creating no backups for the configuration. My hope is that this ticket will trigger other users to request something similar ...
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.