Operating system|Ubuntu Linux 20.04.6| Webmin version|2.021| Usermin version|1.861| Virtualmin version|7.5| Authentic theme version|20.21| Kernel and CPU|Linux 5.4.0-146-generic on x86_64|
Hi
I have installed the OpenVPN Administration module and am trying to get the management system to work but it keeps telling me that:
Connection failed: :Failed to connect to 127.0.0.1:7504 : Connection refused
7504 being the port I have opened for both UDP and TCP traffic.
I know I had this working in the past but do not recall having to open ports for it. However, no matter what I try I cannot get it to connect. Can anyone help please? Not sure what other information to provide.
Have you verified OpenVPN is running and listening on port 7504? If this is on a local machine you are directly accessing I don’t think it would be a firewall problem. Is OpenVPN configured to listen on the local address or just remote?
We don’t maintain that module, and I’ve never used it. I don’t think I’ve ever seen the maintainer posting here, so it may be best to ask them directly on their github or whatever means they provide to contact them.
But, I will say that a firewall is generally irrelevant for local connections (firewalls don’t generally block access to the server itself). So, opening ports is potentially dangerous if 7504 is some sort of control port. 7504 is not the usual port for OpenVPN connections, so I’m just guessing here about what you’re trying to do with that port, I don’t know why you’d be trying to connect to a port that isn’t the OpenVPN port (though it is configurable).
As stated above, there is a low likely hood of this being a firewall issue. The commands listed only work for a specific firewall that isn’t the current default for VM.
They are not the maintainer of anything. They are a spam account posting ChatGPT-generated output. It is nonsense, completely useless. Shaped like an answer, but total bullshit.
I noticed the first such comment a couple days ago, and a couple more after that. This one was more subtle, and I didn’t even notice their first post being unusual…it was sort of unhelpful, but before I was looking for ChatGPT spam, I didn’t recognize it as being unhelpful in that particular way.
Their email address is in the StopForumSpam list, so it’s a confirmed spammer.
Please do hit the flag button on posts that are like that one…great grammar, seemingly concise and clear answer, but to a problem that isn’t the one OP is having or with made up solutions (like suggesting using ufw already tells us it doesn’t know anything about Virtualmin, suggesting firewall exceptions even though it’s a local connection and it doesn’t actually apply in most cases, is a human mistake to make, though, and lots of real people make that mistake here every week).
I didn’t see an end game so I wasn’t sure if it was some kid trying to sound important or ? Then I remembered.
This isn’t the original article I saw but it points to a rise in attempts to compromise Linux servers because they are way more effective at DDOS that IOT devices. That makes sites like this the potential ‘mother load’.
Have tried contacting the maintainer but no response despite several requests over the last couple of years. They are Italian and I do not think this is any longer of interest to them but it does work quite well.
So when I set up a VPN I get the option to have management overview (to see who connected and when) based (I think) on the OpenVPN management module. The admin is just a GUI to the OpenVPN commands and actually it is irrelevant as the problem is that it is not connecting to the port internally on the port I chose and designated for it to use. You are right that I do not need to open the port (and I will close it) as it should be an internal server access.
I have managed to get it to work. It seems the stop and start buttons do not work properly. I went into configuration for the module and removed the unnecessary @%s at the end of each command and now they do respond and show that the server is stopped then started. Restarting it has obviously reset the config file and it is now all working fine.
It may not be maintained but it appears to work well and if it is not broken we should not try to fix it! It is particularly useful for setting up and managing multiple CAs, VPNs and respective clients on the server and once it is understood is relatively simple to use.
The @ is intentional. OpenVPN can have many configurations, and the @ dictates which configuration is being managed.
e.g. if I had a config file named /etc/openvpn/home.conf or whatever, I could run systemctl status openvpn@home to query it (similar for start, stop, etc.). This is one of the cooler features of systemd.
I believe most distros today have client and server dirs for systemctl status openvpn-server@office or similar, as well. I usually use the base dir because my systems are only ever a client or a server never both, and I don’t like typing so much.
Of course, if you only have one, you can also just use openvpn instead of the per-config option. That works, too, as long as your distro package ships with such a systemd unit.