IPFire is displaying incorrect status for some clients connected to OpenVPN. Although the clients are connected and can be pinged, as well as access web services, IPFire shows them as disconnected with the message ‘NOPE, NO CONNECTION.’ What could be causing this issue?
The OpenVPN Roadwarrior diagram shows traffic for the client, and the OpenVPN Roadwarrior connection log shows that the client has been connected for 16 hours.
Is there anything obviously different between the clients showing CONNECTED when connected and those showing DISCONNECTED when connected?
I am presuming that you have refreshed the page after a little while to allow OpenVPN to update the Connection status. However if a connection has been running for 16 hours then accessing the WUI OpenVPN page should immediately show it as CONNECTED.
There
The last on ist connected, but the status shows discon…when i remove the checkbox, the color change from red to blue, after i set the checkbox, the color change to red. The client ist reachable but the status says disconn…
The only thing I can think of is that the client involved is responding in some non-standard way to the test for being connected.
I have had a look through the OpenVPN cgi code and basically IPFire use’s the Perl Net::Telnet module to make a TCP connection and get a state message back. The return message from running the Net::Telnet command is parsed for the state information and if the state is “CONNECTED” then the box is made Green with CONNECTED or in your case VERBUNDEN.
The only thing I can think of is that the involved client is providing a different state message.
Is URI0010 a different type of client from the other two?
These are all mobile routers of the Comtime-LTE type. They all have the same SIM cards in them (iot, Sunrise) and they are all provided with a standard configuration where only the OPEN VPN is still configured.
Is there a way to test the connection check manually?
You write that it would establish a telnet connection to test. Maybe I’ll test it from the IPFire console…
It is not telnet itself that is being run. It is the Net::Telnet perl module that is then using the telnet protocol. So you would need to run the perl module with appropriate options from the command line.
You would need to look at the cgi code to figure out what sort of perl commands would be needed.
The code getting the status is in lines 5431 to 5454. The variable @output has the response that the net::telnet module has received.
I have identified the problem. My colleague has created the clients incorrectly… When creating, you enter the connection name and optionally the note. Where you enter the name for generating the certificate, he entered the note and not the name of the connection.
If the connection name and the name of the certificate do not match, the status for the VPN client in the WEB UI no longer works. I am surprised that it is even possible to enter different things there if the UI no longer works afterwards. Perhaps it is possible to link the fields so that they always match.
I imagine that an error used to occur here when this did not match.
I will check that out on my vm testbed but I don’t expect to have a problem. My production IPFire has connection names that use the client hostname but the certificate identity is the FQDN and those work fine for me, including the connection status.
Also the indication for the certificate CN is given as
User’s full name or system hostname:
I will set up and test two client connections using your info as follows:- _____________
Name URI0008
Remark UR_DOS_WTA2
Certificate CN URI0008 _____________
Name URI0010
Remark UR_DOS_WTA4
Certificate CN UR_DOS_WTA4 _____________
Are the above settings as you meant for a client that had a working or a non working status?
If yes then I will create and test them out on my vm testbed and report back what I find.
The Certificate Common Name does not have to be the same as the connection name and having done a quick search there does not appear to be a big restriction on what can be used. I will go into more detail in the RFC later.
However it looks like somewhere in the IPFire code it does not like the underscore, or maybe it splits at the underscore and therefore the CN for the status check.
I will have a more detailed look through it to find how to fix that, because it looks to be a bug.
Anyway the following results were found by myself.
_____________
Status showed as CONNECTED very quickly
Name URI0008
Remark UR_DOS_WTA2
Certificate CN URI0008 _____________
Status stayed at DISCONNECTED
Name URI0010
Remark UR_DOS_WTA4
Certificate CN UR_DOS_WTA4 _____________
Status showed as CONNECTED very quickly
Name URI0011
Remark UR_DOS_WTA5
Certificate CN UR-DOS-WTA5 _____________
So changing the underscore to a dash for the certificate CN allowed the status command to work with no problems.
I have also found the place in the openvpn cgi code where common name is extracted from a status variable and any underscores are replaced by spaces. Then after this it checks if that common name matches what is stored in the hash file for the client connection.
So if you use underscores then they are replaced by spaces and the CN no longer matches.
Not sure why that regex is used there, because the $cn created is local to a small section of code only.
I will try out the cgi code with the underscore to space regex commented out and see what happens.
EDIT:
The connection with the certificate common name set to UR_DOS_WTA4 now shows the status CONNECTED once the client has connected to the IPFire server.
Just need to figure out if that causes any other issue before submitting a patch fix to the development mailing list.
Either the underscores should not be excluded, or if that gives a big problem elsewhere then when you enter an underscore in the certificate common name section it should flag up an error and say underscore is not allowed.
I checked out the RFC5280 and basically the Common Name can use any characters or string that are in UTF8String.
My CN = Samsung_S21_Black and Remark was Samsung S21 Black, Friendly name = SamsungS21Black - so my status is alwaysDISCONNECTED
Above are from OpenVPN App for Android, “Generated Config” section…
I Edited inside IpFire the Remark to Samsung_S21_Black leaving friendly name the same (friendly name matches what I see in the OpenVPN app for Android), but no success: status is always DISCONNECTED
Any other hints?
Thank you,
H&M
Late edit: in core 172 the status was correctly displayed. Now I am with core 176…
Having read my post number 11 in this thread, I have realised that I forgot to take the next step of submitting a patch to correct that regex with the underscore.
The issue is not with the friendly name. It is with the extraction of the common name from the Status feedback. That regex removes any underscores and replaces them with spaces. Then that CN is compared to the stored hash value for the CN of the certificate you created. But those will never match as the certificate CN has the underscores while the status feedback has replaced the underscores with spaces.
I will do a patch submission so that underscores can be used. To fix it on your system until then you will need to recreate the client connection again but replace the underscores with hyphens for example, so it becomes Samsung-S21-Black. That will then allow the connection status to work again.
The only other alternative would be to change the code in the openvpn cgi code to not replace the underscores with spaces. It is a few months since I looke at that issue so I can’t remember exactly where the code is so I would recommend recreating the client connection certificate with a new CN without underscores.
