Created attachment 1180 [details] error message from n2n client when trying to connect With an existing n2n connection where the .p12 certificate was created with openssl-1.1.1x then with openssl-3.x the client end of the tunnel fails to run. Attached error message shows that the failure is fatal and the connection is not made.
The use of the -legacy option with the openssl command is not usable in this case as the failure is not occurring due to any openssl command in ovpnmain.cgi The problem is that openvpn is using openssl-3.x when it is opening the .p12 file to access the contents. However I have identified that the option for the openvpn configuration file of using providers legacy default is also available in the openvpn-2.5.x series. I had originally thought it was only in openvpn-2.6.x I added that option line manually to the n2n conf file at the client end and this allowed the n2n connection to successfully connect. The option is not needed at the server end as there, individual .pem files are specified for the ca, servercert and serverkey while at the client end the combined .p12 file is used. I believe this will only be an issue for existing n2n clients and that new n2n connections made with openssl-3.x will work properly. I will check this out to confirm. If that is correct then the fix for this basically has to be some code in the update.sh script to add in the providers legacy default line to any existing n2n client connections. I will also have to look at the restore function of the IPFire backup to do an openssl check on any n2n .p12 certificates that get restored to see if they need to have the providers legacy default line added to the configuration file. This might take me a day or two to figure out and test but I will try and do it as quickly as feasible.
@Michael Your suggestion in the email about making a modification in the openssl configuration file is a good idea. I will give that a try on my n2n vm setup. I will also try re-uploading the client package from the n2n server to the n2n client and see if that then works without needing the "providers legacy default" line added.
Putting the legacy provider into the openssl.cnf file allowed the downloading of the previously created insecure .p12 file without needing the -legacy option in the openssl commands for extracting the certificate and the key. However it made no difference to the n2n client connection. This still failed when the "providers legacy default" option line was removed from the n2n conf file. This looks like the use of openssl has been built into the openvpn binary and is not using the openssl.cnf file or is ignoring the legacy portion of it if it exists. As we already have the -legacy option in the ovpnmain.cgi openssl commands that need to use it for accessing or extracting the contents from .p12 files then it seems best to leave those as they are and not add in the extra legacy lines into the openssl.cnf file I will focus on how to get the "providers legacy default" line into the n2n conf file.
I have been able to modify ovpnmain.cgi so that if the n2n client connection is deleted and re uploaded then the line "providers legacy default" is added to the end of the n2nconf file. It should be possible to search all the n2n config files in /var/ipfire/ovpn/n2nconf/ and if they have the word client in the first line then to add "providers legacy default" at the end of those files using the update.sh script.
I have found some additional locations in the ovpnmain.cgi perl code where I make it add the line "providers legacy default" to the n2n configuration file. This now means that when an existing client package is re-uploaded it will have that line added but also for an existing client package without that line that was unable to connect, just selecting the edit pencil option and saving without changing anything results in the n2n configuration file having the line included and being able to connect successfully again. So at the worst people having a problem connecting with an existing n2n configuration just need to go to the client end, select the edit icon for each connection and then save and they should all be able to connect. This should be a reasonable approach for dealing with any restores from a CU before 175. It just needs to be written into the wiki which I will do when CU175 is released. I will now look at some code to be able to add to the update.sh script to try and update all existing client configs to have that line included without any manual intervention by the users.
Patch to fix this bug plus a patch adding code to the Core Update update.sh script to find all n2n config files and add "providers legacy default" if it is not yet present. Successfully tested out on my vm testbed running with a n2n openvpn tunnel bbetween two vm IPFire systems. https://lists.ipfire.org/pipermail/development/2023-June/016005.html https://patchwork.ipfire.org/project/ipfire/list/?series=3676
Additional patch created and submitted which will add the line "providers legacy default" to the OpenVPN N2N Client configs during restore if it is not already present. https://lists.ipfire.org/pipermail/development/2023-June/016014.html https://patchwork.ipfire.org/project/ipfire/patch/20230605115529.5601-1-adolf.belka@ipfire.org/
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=0b216134c2107ac0dccccac15a97db0082c84678 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=2054306c632046c052e67eee1220abef42c34b5d https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=9eb2086e0f3b6feb6e52d01c7faf5d79791650ea Thank you very much! I'll update the draft for the C175 release note accordingly.
Additional commit merged to correct incorrect return values on iscertlegacy subroutine. https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=0ebb271d1ec8b68f73dbd396b0f3a0aa4a50a501
Modified patch that only uses the legacy options for certificates that are legacy based. https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=7dec360355f0eb5bb9bc61b32a08e733aa070b40
Verified on CU175 Testing
CU175 released. https://blog.ipfire.org/post/ipfire-2-27-core-update-175-released Confirmed working after return code corrected (comment 9)