However, I have been using port 14 for something else for years.
So question is 2 fold:
1) Is it possible in future to surface this configuration (port logs are read on by the GUI)?
2) Is it possible to configure this through "Additional Config"? Currently I can change management port through this field. But I dont seem to see a way to make the Status page read from that new changed port.
Joined: 18 Mar 2014 Posts: 12904 Location: Netherlands
Posted: Thu Jun 09, 2022 7:04 Post subject:
Since the beginning of times the DDWRT OpenVPN Status Page has been querying the management interface of the Open VPN Server on port 14 and the OpenVPN Client on port 16.
So better not use those ports elsewhere.
In the openvpn.conf the management interface is, of course, set accordingly.
You can override this in the additional config but you can not set the GUI to query another port that is fixed so the OpenVPN status page is blank.
However you can query the management interface from CLI, I am doing that for a setup with two OpenVPN clients where I have set the management port of the second client on port 17:
As @egc stated, while you can change the management port via the Additional Config field, it's NOT going to change the port the webpage source code uses to access that service.
Could this port be exposed in the GUI for such purposes? Of course, although this is a good example of further complicating the GUI, which is already pretty complicated as it is. So I don't know if this is something @egc would want to consider.
Frankly, I don't think it's necessary to use the management port for these purposes anyway. Such information could be gleaned from the OpenVPN client using the following in the config file.
Code:
status /tmp/openvpncl/status
Now the stats would be updated every 60 secs in that file (it takes an optional third argument to change the update period) and available for display. And it would eliminate those annoying warning messages in the syslog about the management UI not using a password, and the CMD messages as well. On the downside, a refresh of the page would only change if the status file had been updated since the last refresh.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu Jun 09, 2022 18:14 Post subject:
Well there is a reason why many knobs are hidden and only available to those who venture outside comfort zones and have enough experience to know better.
I would say in addition to whats been said, that some clients need to be equally as flexible in order to communicate properly with servers, and some crap is still closed source, like much of OpenVPN is apparently.
Thats not to say there aren't ways around things, but it not so cut and try.
Joined: 18 Mar 2014 Posts: 12904 Location: Netherlands
Posted: Fri Jun 10, 2022 10:42 Post subject:
eibgrad wrote:
As @egc stated, while you can change the management port via the Additional Config field, it's NOT going to change the port the webpage source code uses to access that service.
Could this port be exposed in the GUI for such purposes? Of course, although this is a good example of further complicating the GUI, which is already pretty complicated as it is. So I don't know if this is something @egc would want to consider.
Frankly, I don't think it's necessary to use the management port for these purposes anyway. Such information could be gleaned from the OpenVPN client using the following in the config file.
Code:
status /tmp/openvpncl/status
Now the stats would be updated every 60 secs in that file (it takes an optional third argument to change the update period) and available for display. And it would eliminate those annoying warning messages in the syslog about the management UI not using a password, and the CMD messages as well. On the downside, a refresh of the page would only change if the status file had been updated since the last refresh.
At least if *I* was going to consider allowing a user-defined port, I'd seriously consider revamping the process entirely to use the status file.
Thanks for your comment.
I indeed was not contemplating adding a GUI option (as the American saying is: You cannot be too rich or too thin but you can have too much GUI options )
This is not much sought after and we have good workarounds, using the command line or your excellent option (thanks for that).
However at this moment the GUI is querying the conf file for the used management port but it starts from the top and of course does find the DDWRT port first and does not take the port from the additional config into account.
Joined: 18 Mar 2014 Posts: 12904 Location: Netherlands
Posted: Sun Jun 19, 2022 16:42 Post subject:
The scripts were already parsing the management port.
But as the management port was already set by DDWRT they always return that port.
I added tail (see: https://svn.dd-wrt.com/changeset/49252 )
So that it just uses the last added management port
(If you now a better solution of course always welcome, but this seems to work )
can confirm its working (note need to CTRL + SHIFT + R after switching ports).
perhaps its a good time to make sure that the rest of the config file is queried bottom up as well? Because for example verb 3 is pre-set in the file. While debugging I set it to verb 5 via additional parameters (to get extra debug) but not sure it was working, at least I didnt get the info I was looking from from the logs.
Another solution perhaps less elegant but more geeky would be to make the config field pre-populate the defaults from /tmp/openvpn/openvpn.conf in it. And then when applied overwrite the file. So that basically the GUI text field is mirror of the openvpn.conf instead of being additional appendage. Basically enabling you to edit the entire config file instead of just adding to it.
Joined: 18 Mar 2014 Posts: 12904 Location: Netherlands
Posted: Mon Jun 20, 2022 12:21 Post subject:
Duxa wrote:
can confirm its working (note need to CTRL + SHIFT + R after switching ports).
perhaps its a good time to make sure that the rest of the config file is queried bottom up as well? Because for example verb 3 is pre-set in the file. While debugging I set it to verb 5 via additional parameters (to get extra debug) but not sure it was working, at least I didnt get the info I was looking from from the logs.
Another solution perhaps less elegant but more geeky would be to make the config field pre-populate the defaults from /tmp/openvpn/openvpn.conf in it. And then when applied overwrite the file. So that basically the GUI text field is mirror of the openvpn.conf instead of being additional appendage. Basically enabling you to edit the entire config file instead of just adding to it.
The way OpenVPN is using its config file and how DDWRT uses it (to parse the management port) are different.
OpenVPN should use the last entry (not for everything sometimes you cannot set a duplicate entry but OpenVPN will warn against that).