Management interface via TCP
-
Hi all,
I'm trying to set up the openvpn management interface on a pfsense 2.1 box. It should listen to one of the interfaces so a 3rd party NMS can connect to it. I have tried using the management directive like so (under advanced options on openVPN config page):
management 192.168.54.2 7000
However, telnet to the socket does not succeed. So I gave "verb 9" and found this in the openvpn log:
Feb 18 20:03:38 openvpn[47434]: MANAGEMENT: unix domain socket listening on 192.168.54.2
In great disbelief, I checked the docs again:
–management IP port [pw-file]
Enable a TCP server on IP:port to handle daemon management functions. pw-file, if specified, is a password file (password on first line) or "stdin" to prompt from standard input. The password provided will set the password which TCP clients will need to provide in order to access management functions.The management interface can also listen on a unix domain socket, for those platforms that support it. To use a unix domain socket, specify the unix socket pathname in place of IP and set port to 'unix'. While the default behavior is to create a unix domain socket that may be connected to by any process, the –management-client-user and --management-client-group directives can be used to restrict access.(...)
Why in hells name does it take an IP for a "path to a unix domain socket" ???
The docs do state clearly that, in order to use a unix domain socket, specific options must be set! >:(On a side note: The openvpn docs are somewhat confusing on the syntax. Is it "management <ip><port>" or "management <ip>:<port>" ?
I tried both and I guess it's " <ip><port>" as the "<ip>:<port>" notation causes openvpn to fail, complaining about a config error.Confused, I googled around some more and found this:
Revision 71ca2cb2
Added by Ermal Luçi over 1 year agoTicket #826. Convert to unix domain sockets for management interface so we do not have problems when interface is any.
It appears as if there was a problem with openvpn binding to 127.0.0.1. And instead of fixing the bug, someone broke existing and documented functionality and introduced undocumented behaviour - "so we do not have problems" ??? Come on now… and if there's a bug with the packet filter, someone will just disable it "so we do not have problems"? That's ridiculous!
Clearly, I must be mistaken. Can anyone shed some light here because I must get this to work?
I need to connect the management interface via TCP.</port></ip></port></ip></port></ip></port></ip> -
It was changed from TCP to sockets because it then can't run out of ports and you don't have to worry about conflicting ports and keeping track of ports. It's not working around a bug, it's doing things in a better fashion. You can't do TCP and sockets at the same time, which is your one and only problem. Apparently OpenVPN has unusual quirks when you try to do both from your description. Since our built in functionality does things in the better way with sockets, you're either going to have to hack the source and break the built-in OpenVPN status capabilities, or make your application work with sockets.
-
@cmb:
It was changed from TCP to sockets because it then can't run out of ports and you don't have to worry about conflicting ports and keeping track of ports. It's not working around a bug, it's doing things in a better fashion. You can't do TCP and sockets at the same time, which is your one and only problem. Apparently OpenVPN has unusual quirks when you try to do both from your description. Since our built in functionality does things in the better way with sockets, you're either going to have to hack the source and break the built-in OpenVPN status capabilities, or make your application work with sockets.
Now that's some very bad engineering practice for sure, and -perhaps- a bitter attitude :-(
Let me explain:
OpenVPN is a well known SSL VPN software, which was added to pfSense. pfSense supports openVPN, so to speak. This implies a lot of things in people's heads, whether want it or you're going to admit it or not. Let's consider this real world example:
A junior system engineer may choose pfSense for it's openVPN support (amongst other things). She may do so because she's familiar with the software and, considering the features, performance and supported platforms of the software, deem it appropriate to implement a particular subsystem in their network, such as a VPN concentrator. She assumes from previous experience (and can re-assure herself by carefully reading the documentation on openvpn.net) that openVPN has a management interface that operates over TCP, and that it will she will be able to connect an existing, third party NMS running on Windows over an IP network to an openVPN server. She will plan her project accordingly, taking utmost care that all interface requirements will be met by verifying documentation and project requirements over and over again. Needless to say that she wasn't able to meet the project deadline. Why? Because someone at pfSense high-handedly decided that breaking documented functionality in openVPN will be JUST FINE, the reason being "so we don't have problems", as documented in redmine. I'm getting red angry when I just think about it - what kind of engineering practice is this?!
Well. And you're telling me that I either need to setup a dev box, download and setup a myriad of tools and accounts, get into openVPN development first, then learn the basics of pfSense development as to finally fix somebody elses screw-up?
Doing so is giving yet another good example of how exactly arrogance and elitism will marginalize and kill the open source: "We broke something ? Oh why dont you fix it then, you have the source!". This just doesn't compute: Most people working with computers today need their computers to get actual work done. And even if they are computer freaks, they often lack the time to indulge in fixing problems caused by bad engineering practice and the lack of quality assurance in someone else's work. Often, these people have little time to get their own work done and fix their own little bugs. Expecting them to fix things that you have broken -in total ignorace- on your own, will only lead to one thing: Your demise.
Reminds me of my Sony Ericsson K700i cellphone I got from my telco a few years ago. Turned out that it couldn't play MP3 ringtones due to the stupid vodafone branding. But the MP3 ringtones was (among other things) why I wanted the K700i after all! I wrote to the telco (swisscom) and complained that they were trying to sell me some weird device. telling me it's a SE K700i, when it wasn't: The official datasheet from the manufacturer said it can play MP3 ringtones and the device they sold me couldn't. So -very clearly- it didn't meet manufacturer specs and could thus hardly be considered a SE K700i!
Big difference is: The telco refunded me my phone, and added 60 bucks to my account for notifying them of the problem… ;-)
-
That all being said, I might add that the intention was to enable TCP sockets, while we didn't care for the built in status page. However it turned out that any IP socket we threw at the management directive is being interpreted as unix socket. Hence the problem is absolutely not that we can't have unix and tcp sockets at the same time.
The problem is that openVPN management interface on pfSense doesn't work with TCP sockets!
-
Using Unix domain sockets is a perfectly valid and fully supported means of managing stock OpenVPN. Using your logic, I could just as easily and correctly say your application is broken because it requires TCP for management, nothing at all wrong with using sockets to manage OpenVPN. Not a single bad practice here on our part.
Your only legit complaint is the commit log wasn't nearly as descriptive or even accurate as the discussion we had about changing it. You clearly don't understand the problems in using TCP ports and I don't have time to explain it to you.
-
Stop.
We have here, it seems, a failure to communicate!
First, I don't question the legitimacy of your elite unix domain socket techniques, and I understand the reasons for using them in your application.
Then I have to excuse myself for the rant! Reading the note in redmine, I freaked. Like, wtf! You will probably agree with me that reliable documentation is the only thing that separates us IT folks from untold chaos and eternal pain.
So lets again look at the issue:
- openVPN documents the standard interface to be TCP
- openVPN documents the interface to optionally support unix domain sockets
- openVPN documents a specific syntax for the management directive, in order to activate unix sockets.
- Put a management directive into the openvpn config on pfSense, giving an IP address and a port number, and you'll see the openVPN on pfSense wrongfully assuming the given IP address or DNS name to be a unix domain socket name when checking server logs:
Feb 18 20:03:38 openvpn[47434]: MANAGEMENT: unix domain socket listening on 192.168.54.2Maybe it's just the GUI overwrites the port number part of the management directive with the string "unix", thereby effectively activating unix socket mode. Maybe it's a nasty, ugly, dirty hack that doesn't really work right in the openVPN build used in pfSense. Maybe it's a bug in openVPN itself. I don't know.
My point is: You can not specify a TCP socket for openvpn management in pfSense, because it will always go into unix domain socket mode.
That's not as it should be.
-
It's more accurate to say:
You can't effectively override the management behavior.
However, if you can't, that's a bug in OpenVPN not a bug in our config
Our config puts, for example:
management /var/etc/openvpn/client1.sock unixWhich is exactly what the man page says:
The management interface can also listen on a unix domain socket, for those platforms that support it. To use a unix domain socket, specify the unix socket pathname in place of IP and set port to 'unix'.If you add a second management line (via advanced options) and it ignores your IP or port, that's OpenVPN misinterpreting your config. It will typically just take the last line that matches. If it's adding them together it's inconsistent.
The GUI doesn't change your advanced options, they're just placed into the config at the end.
To comment further you'll have to show us what's in /var/etc/openvpn/*.conf for the connection in question.
-
Incredibly hackish workaround:
1. Install nmap package and shellcmd package
2. Add shellcmd to run an ncat instance to bind a tcp port to that unix socket:ncat -l -k -p 5001 -c 'nc -U /var/etc/openvpn/server1.sock'Telnet to port 5001, and you'll be connected to the unix socket.
Be aware though that if two clients (yours and Status > OpenVPN) try to read at the same time, whoever attached first will work, the other will get nada.
-
It's more accurate to say:
You can't effectively override the management behavior.
However, if you can't, that's a bug in OpenVPN not a bug in our config
[…]
If you add a second management line (via advanced options) and it ignores your IP or port, that's OpenVPN misinterpreting your config. It will typically just take the last line that matches. If it's adding them together it's inconsistent.
Thank you Jimp! Now this becomes clearer: OpenVPN apparently starts treating everything in any management directive as unix domain socket, as soon as this mode is activated once. I'll report this inconsistency to openVPN. Maybe a fix can make it into the upcoming 2.3!
ncat -l -k -p 5001 -c 'nc -U /var/etc/openvpn/server1.sock'I wrote a plugin that reads the openvpn status php.
Gave me some ideas, I'll work more on this when I have time.Thanks again!
Chris
