Bug 11048

Could you please post what is being logged to /var/log/httpd/error_log?

Created attachment 409 [details]
log files

Here are all files in this folder zipped

I have the same problem. But it also belongs to existing ovpn files.
Tested with Core100

Do you need again the apache log?

It would be nice to get a solution. I need it for a ubuntu client auto connection when the system boots up.

Created attachment 508 [details]
OpenVPN page in IPFire

The Issue is with core 109 still there

also with Core 111

In logs i can find this:

[Sat Jun 17 08:58:41 2017] [error] [client 192.168.2.21] Mac verify error: invalid password?, referer: https://192.168.2.1:444/cgi-bin/ovpnmain.cgi
[Sat Jun 17 08:58:41 2017] [error] [client 192.168.2.21] openssl error: 256 at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 2292., referer: https://192.168.2.1:444/cgi-bin/ovpnmain.cgi
[Sat Jun 17 08:58:41 2017] [error] [client 192.168.2.21] Premature end of script headers: ovpnmain.cgi, referer: https://192.168.2.1:444/cgi-bin/ovpnmain.cgi

Okay, this issue are only with this single old Connection. When i create an new connection the unsecured download works...

Thia problem is still occurring in community forum

https://community.ipfire.org/t/download-of-openvpn-unsecure-client-zip-file-doesnt-worked/4022

and has also been found by myself and Erik Kapfer.


What happens is that if a secure connection is created (ie certificate with password) then when first created there is only the icon for the Secure package download displayed.

If the edit button for the connection is then pressed and saved (even without any changes) then the insecure package download is now also displayed.
If that icon is pressed then you get the "Internal Server Error" because a password is present when there should not be one.

Feedback from Erik is that a check in one part of ovpnmain.cgi is also needed in another part of that file.
I agreed with Erik that I would have a go at working on the solution for this bug.

Hence I am re-opening this bug.

Created attachment 828 [details]
httpd error log message

These are the error lines in the httpd error.log when the "Internal Server Error" message comes up after pressing the insecure icon on a connection with a secure certificate.

Created attachment 829 [details]
Secure connection after creation

This shows the connection immediately after creation with a secure certificate (ie with password)

Created attachment 830 [details]
Secure connection after creation, press edit & save

This shows the same connection with a secure certificate after pressing the edit symbol and then pressing save without changing anything.

Thank you Adolf for looking at this problem.

I would also like to throw in that we do not always need two options here. Can we not merge this into one file that doesn't even need to be zipped?

@Erik: Do you know if we can include the password-protected PKCS12 container in tags like we do with the PEM file?

I have had a look at the code around this section and the current files that are produced for download. I believe that it should be possible to create a single download package for this that contains the available options depending on whether a password has been entered or not.

I believe that it will need to stay as an archive file as in all options multiple files have to be provided.

I will have a go at the code and see if I can get it to work so that it provides only a single download package.

If I get into difficulties with the ovpnmain.cgi code I will contact Erik for help.

I have experimented with the ovpnmain.cgi code on my VM testbed and have been able to create a zip file with two directories in it, one containing the combined .p12 file and the other containing the ca and cert .pem files and the cert .key file.
the ta.key file is in both directories.

So proof of concept is made to be able to have a single file containing both options.
I still need to modify the code to enable the tailored .ovpn file to be created for each option.

I also need to look at the possibility to have a key with a password embedded as encrypted code in the .ovpn file when a password is defined. From searching I believe this can be done.
Need to prove this first in standalone fashion and if successful, will try to code it into ovpnmain.cgi.

Something has changed in ocpnmain.cgi since my last comment.

Now when an insecure connection is made both icons are shown at the same time immediately. If the secure version is clicked on to download it then the Internal Server Error no longer comes up, you get the download box opening up.

The .p12 certificate now opens without a password but trying to use it in a linux connection failed to work.

I am going to come back to this bug and just try and finds out how to make only one of the download icons show at a time.

Trying to get a single download file that had all options in proved a bit too difficult for me at that time.

This way we fix the bug of an incorrect download icon being shown and any further improvement to combine into one download file can be done as a next step later on, or in IPFire3.x where it might be easier.

My previous comment is incorrect. I had it the wrong way round. I was looking at a connection that had been created as an insecure one.

The original problem was if you create a sceure connection you just get the single icon but after editing you then get both icons and pressing the insecure icon causes the Internal Server Error. This is still occurring.

I had mixed up the order of the icons with the type of connection.

However I will still come back to this bug and look to fix the insecure icon being shown after editing the connection.

I have been able to make a fix that makes the icons work correctly so that the Download insecure Client Package (zip) icon will only show when a connection without a password has been created.

It should be possible to correct all connections that have never been edited, as part of the core upgrade.

However any connections already edited and showing the second icon for insecure client package I have not been able to figure out a way to identify and correct them. Hopefully the review of the patch submitted will be able to identify something.

The patch has been submitted to the dev mailing list and to patchwork.

https://lists.ipfire.org/pipermail/development/2023-February/015389.html
https://patchwork.ipfire.org/project/ipfire/patch/20230210181343.17763-1-adolf.belka@ipfire.org/

Good morning Adolf,
(In reply to Adolf Belka from comment #19)
> It should be possible to correct all connections that have never been
> edited, as part of the core upgrade.
> 
> However any connections already edited and showing the second icon for
> insecure client package I have not been able to figure out a way to identify
> and correct them. Hopefully the review of the patch submitted will be able
> to identify something.

a possible way to identify also connections which uses passwords but where falsely modified to 'no-pass' in ovpnconfig might be a openssl command.

openssl pkcs12 -info -in /var/ipfire/ovpn/certs/*.p12 -noout -password pass:''

since the password flag is empty, all encrypted *.p12 files delivers an "Mac verify error: invalid password?" this might be a way to investigate also already falsely modified 'pass' connections.

Since the OpenSSL command displays the output to STDERR and you want to handle the output via grep (searching e.g. for 'error') you might need to redirect STDERR to STDOUT which looks e.g. like this -->

openssl pkcs12 -info -in /var/ipfire/ovpn/certs/*.p12 -noout -password pass:'' 2>&1 | grep 'error'

To get the host connection names e.g. awk can be useful -->

awk -F',' '/host/ { print $3 }' /var/ipfire/ovpn/ovpnconfig

so with a for loop like e.g. this -->

for x in $(awk -F',' '/host/ { print $3 }' /var/ipfire/ovpn/ovpnconfig); do
        if [[ -n $(openssl pkcs12 -info -in /var/ipfire/ovpn/certs/${x}.p12 -noout -password pass:'' 2>&1 | grep 'error')  ]]; then 
                echo ${x} >> /tmp/ovpn_rw_pass
        fi
done

you get a list under '/tmp/ovpn_rw_pass' with all connection names which uses a 'pass' .

The last part would be, to modify the listed connections in the respective column in ovpnconfig ?

As an idea if you want to give it a try. Hope it helps.

Best,

Erik

Hi Michael,
have just seen your question
(In reply to Michael Tremer from comment #14)
> @Erik: Do you know if we can include the password-protected PKCS12 container
> in tags like we do with the PEM file?

i don´t think that this is possible. Inline file support does only exist for 'tls-auth', 'key', 'cert', 'ca' and since OpenVPN-2.6 'peer-fingerprint' as far as i know.

Best,

Erik

So i need to revert my statement according to the inline support. Just found this --> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-6/#inline-file-support so it seems to be possible but it has to be base64 encoded.

Best,

Erik

(In reply to Erik Kapfer from comment #20)
> Good morning Adolf,
> 
> a possible way to identify also connections which uses passwords but where
> falsely modified to 'no-pass' in ovpnconfig might be a openssl command.
> 
> openssl pkcs12 -info -in /var/ipfire/ovpn/certs/*.p12 -noout -password
> pass:''
> 
> since the password flag is empty, all encrypted *.p12 files delivers an "Mac
> verify error: invalid password?" this might be a way to investigate also
> already falsely modified 'pass' connections.
> 


Hi Erik,

Thanks very much for your input. That indeed sounds like a viable approach.

I will do some testing out on my vm testbed and after confirmation, suggest it to @Michael and @Peter for inclusion in the update.sh script for the core updates.

(In reply to Adolf Belka from comment #23)
Hello Adolf,
> (In reply to Erik Kapfer from comment #20)
> Hi Erik,
> 
> Thanks very much for your input. That indeed sounds like a viable approach.
> 
> I will do some testing out on my vm testbed and after confirmation, suggest
> it to @Michael and @Peter for inclusion in the update.sh script for the core
> updates.
your welcome but you would need another command to modify ovpnconfig at the end. May something like awk might be helpful for this. NF=$43 for the 'pass' substitution and NF=$3 for the connection name may some sub function in a for loop might do this ? Haven´t checked it yet but may you, Michael or Peter have an idea.

Best,

Erik

Hi all,
to step out of the personal email communication and take all together, in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=f873bcdb07001cfc5571cb6cf98e3df3a8e83515 the current development state can be found.

Best,

Erik

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=762c88ec4d85e3a4f7265b887f054cbe7703eb7c
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=82822934ba769bca4235cd2a02f848cdc8511120
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=070abb0d011ff71e5aefd170dcb366d81bdf2497
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=18bece0edbd817933f48fdbffcffffd074e42c05
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=9cac1034bcfe423c4a5e0f547664fbabcf9050e6

Thank you very much indeed for this!

Core Update 175 Testing has been released.

https://blog.ipfire.org/post/ipfire-2-27-core-update-175-is-available-for-testing

Tested this out in vm testbed.

Discovered that a .p12 cert without password that was created with openssl 1.1.1 ends up with an error message with openssl3. This means that it flags up for both the 'Encrypted' and 'error' grep entries which means that it ends up being entered into ovpnconfig twice, once with pass and the second with no-pass. After reboot there is only one of those entries left in ovpnconfig but in my test it was the wrong one, ie the entry with pass was kept, which means a cert without password was no shown as having a password.

The update.sh script needs to look for 'verify error' instead of just 'error'

However also need to understand the impact of the error message from openssl3 for a .p12 cert without password created with openssl-1.1.1 but checked with openssl-3.x
This did not happen for any of the certs with a password. The info message for those was the same with openssl-1.1.1 as it was with openssl-3.x

Have requested for the patch set submission to be reverted until I can understand what is happening here and fix it.

Therefore bug moved back to on-dev.

Some reports have also occurred in the forum on Core Update 175 with regard to an imported net2net profile from an earlier Core Update.

https://community.ipfire.org/t/test-ipfire-cu175/9762

I have also realised that any restore from a backup made with a Core Update before 175 will also have blanks for index 43 in many cases.

Therefore as well as fixing what I reported earlier about an insecure entry ending up duplicated with both pass and no-pass, I will also need to ensure that the code from the update.sh file is used in IPFire to deal with any imported profiles or with any backup restores.

Previous comment mentioned index 43. This should be index 41

There is something confusing in the index numbers in ovpnmain.cgi

There is an entry
$confighash{$key}[41] = "pass";
but in ovpnconfig the pass entry ends up in 43 if the first entry is 1

but in another part of ovpnmain.cgi there is the entry

$cgiparams{'TLSAUTH'}		= $confighash{$cgiparams{'KEY'}}[41];

which also references the index 41 but the tlsauth entry in ovpnconfig is two places before the pass entry.

I need to look at how ovpnconfig is created.

Hello Adolf,
(In reply to Adolf Belka from comment #31)
> There is something confusing in the index numbers in ovpnmain.cgi
> 
> There is an entry
> $confighash{$key}[41] = "pass";
> but in ovpnconfig the pass entry ends up in 43 if the first entry is 1
> 
> but in another part of ovpnmain.cgi there is the entry
> 
> $cgiparams{'TLSAUTH'}		= $confighash{$cgiparams{'KEY'}}[41];
> 
> which also references the index 41 but the tlsauth entry in ovpnconfig is
> two places before the pass entry.
> 
> I need to look at how ovpnconfig is created.

the index for TLSAUTH was reserved at that time of development in case TLS-Auth had also belong to Net2Net connections which never happens, i don´t know from whom and why it has been used for "pass" at that time but since TLS-Auth is only for Roadwarrior in usage, you can leave it behind (remove it) since "/var/ipfire/ovpn/settings" deliver here the "On/OFF" information for the configuration files.

Best,

Erik

P.S.: Couldn´t saw/see the rest since i didn´t know about the OpenSSL-3.x development and didn´t use it either.

Thanks Erik for the explanation.

I have another question. When a net2net client profile package is imported then index [41] is set to 'disabled' in ovpnmain.cgi line number 3432.

What is the purpose of this entry 'disabled'. I can't seem to find it being used anywhere but it replaces the no-pass entry we set when we created the connection package.

With 'disabled' in that index then the CFonnection status fails to display correctly. It is blank without any words like DISCONNECTED or any colour like green or red.

If I change line 3432 so that it sets no-pass in index [41] then the status for that imported connection info is show correctly.

Before making that change I want to understand if there is some reason for that 'disabled' entry in index [41] for imported connection packages.

Your welcome,
(In reply to Adolf Belka from comment #33)
> Thanks Erik for the explanation.
> 
> I have another question. When a net2net client profile package is imported
> then index [41] is set to 'disabled' in ovpnmain.cgi line number 3432.
> 
> What is the purpose of this entry 'disabled'. I can't seem to find it being
> used anywhere but it replaces the no-pass entry we set when we created the
> connection package.
> 
> With 'disabled' in that index then the CFonnection status fails to display
> correctly. It is blank without any words like DISCONNECTED or any colour
> like green or red.
> 
> If I change line 3432 so that it sets no-pass in index [41] then the status
> for that imported connection info is show correctly.
> 
> Before making that change I want to understand if there is some reason for
> that 'disabled' entry in index [41] for imported connection packages.

'disable' is no variable nor is it a OpenVPN directive (can not be seen in client/server configuration), it is not configurable via WUI, so i think it is a placeholder to reserve [41] but to check this for sure, a N2N connection can be start up without line 3432 ?

Best,

Erik

(In reply to Erik Kapfer from comment #34)
> 
> 'disable' is no variable nor is it a OpenVPN directive (can not be seen in
> client/server configuration), it is not configurable via WUI, so i think it
> is a placeholder to reserve [41] but to check this for sure, a N2N
> connection can be start up without line 3432 ?
> 
> Best,
> 
> Erik

I don't have a n2n configuration set up yet in my vm testbed. It is on my long list of things to do mut not yet done.

So I can not test if a connection actually works if that line is removed.

Are you able to do a n2n connection test with that line removed?
If not then I will have a look at getting a n2n setup running on my vm testbed.

(In reply to Adolf Belka from comment #35)
> (In reply to Erik Kapfer from comment #34)
> > 
> > 'disable' is no variable nor is it a OpenVPN directive (can not be seen in
> > client/server configuration), it is not configurable via WUI, so i think it
> > is a placeholder to reserve [41] but to check this for sure, a N2N
> > connection can be start up without line 3432 ?
> > 
> > Best,
> > 
> > Erik
> 
> I don't have a n2n configuration set up yet in my vm testbed. It is on my
> long list of things to do mut not yet done.
> 
> So I can not test if a connection actually works if that line is removed.
> 
> Are you able to do a n2n connection test with that line removed?
> If not then I will have a look at getting a n2n setup running on my vm
> testbed.

Am currently do not use OpenVPN in general but we can open up a connection if you want, in that case we need to arrange a date for this.

Best,

Erik

(In reply to Erik Kapfer from comment #36)
> Am currently do not use OpenVPN in general but we can open up a connection
> if you want, in that case we need to arrange a date for this.
> 
> Best,
> 
> Erik

If you don't use it currently then don't worry about it.

I am working on setting up both ens of a net2net tunnel in my vm testbed.

Just been reading through the wiki. Seems not too bad to do.

Will then test out that both with and without line 3432 in ovpnmain.cgi

I got a net2net configuration working on my vm testbed.

Have tested operation of OpenVPN net2met with line 3432 of ovpnmain.cgi commented out in both IPFire ends. Everything worked as expected.

Also imported the net2net client package while that line was commented out and again everything worked as expected.

In my updated patch set I will replace "disabled" in line 3432 with "no-pass".

Once I have all the changes made I will be able to test it out on my vm IPFire at both ends of the net2net tunnel and confirm that everything works now as it should do.

*** Bug 13129 has been marked as a duplicate of this bug. ***

Response to @Man Grove from bug#13129

I reverted the patches but can't revert the actions from the update.sh script.

If you look in /var/ipfire/ovpn/ovpnconfig at each of the n2n connections what do you find near the end of the line. There should be an entry at index 43 of no-pass. I suspect it will be an entry of disabled. It could also be pass but should not be.

I would like to know what entry you find.

(In reply to Adolf Belka from comment #40)
> Response to @Man Grove from bug#13129
> 
> I would like to know what entry you find.

The last entries look like this:

udp4,1185,off,1500,,,,,,,,SHA512,AES-256-CBC,disabled

So, your suspicion was right. :-)

(In reply to Man Grove from comment #41)
> 
> The last entries look like this:
> 
> udp4,1185,off,1500,,,,,,,,SHA512,AES-256-CBC,disabled
> 
> So, your suspicion was right. :-)

That is good because then the fix I have added to the patch set for this bug will solve that.

I have a n2n test configuration set up now but it would be good if you, as a real n2n user, can test out the final revised patch set I submit for this bug. It will end up in CU176 as 175 will shortly get released.

In terms of your CU175 system I realised, after some thought during the night, that reverting the previous patch set just means that it will not be installed in fresh updates to CU175 Testing.
Once you have those patches installed then that won't be reverted by a Core Update.

You have two options.

1) Install Core Update 174 from fresh and then update to Core Update 175 Testing, although you might want to wait for the full CU175 release as it will have a newer version of OpenSSL than is currently there.

2) Copy into your IPFire system the CU174 versions of the files that were modified.
These are:-
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;h=51d6e8431d6a00ffbb87aa24591c1fb67f0059b8;hb=refs/heads/core174
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=langs/de/cgi-bin/de.pl;h=33730f0c319d8f3ae1b6cffc88db42d0d558cf46;hb=refs/heads/core174
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=langs/en/cgi-bin/en.pl;h=729516538bcf40fc40007f92d4a2d0779fe2807f;hb=refs/heads/core174
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=lfs/web-user-interface;h=da76a7d10efd31eb4e01a5973474f4aaf457d778;hb=refs/heads/core174


When you have copied in the two language files you will need to run
update-lang-cache

(In reply to Adolf Belka from comment #42)
>
> I have a n2n test configuration set up now but it would be good if you, as a
> real n2n user, can test out the final revised patch set I submit for this
> bug. It will end up in CU176 as 175 will shortly get released.

OK, is that revised patch set what you are referring to here below?

> 2) Copy into your IPFire system the CU174 versions of the files that were
> modified.
> These are:-
> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;
> h=51d6e8431d6a00ffbb87aa24591c1fb67f0059b8;hb=refs/heads/core174
> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=langs/de/cgi-bin/de.pl;
> h=33730f0c319d8f3ae1b6cffc88db42d0d558cf46;hb=refs/heads/core174
> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=langs/en/cgi-bin/en.pl;
> h=729516538bcf40fc40007f92d4a2d0779fe2807f;hb=refs/heads/core174

This changed nothing -- for a second run, I also changed the "disabled" to "no-pass" in the config files. No dice. Rebooted between every such change. BTW, the "disabled" entry doesn't change, if that's something you want -- it's still there after a reboot + disable/enable cycle of the connection.

> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=lfs/web-user-interface;
> h=da76a7d10efd31eb4e01a5973474f4aaf457d778;hb=refs/heads/core174

Can't figure out where this file should go, but it doesn't seem related to anything OpenVPN-ish?

(In reply to Man Grove from comment #43)
> (In reply to Adolf Belka from comment #42)
> >
> > I have a n2n test configuration set up now but it would be good if you, as a
> > real n2n user, can test out the final revised patch set I submit for this
> > bug. It will end up in CU176 as 175 will shortly get released.
> 
> OK, is that revised patch set what you are referring to here below?

No. That patch set is only partially on my own testbed system. I was meaning that you can test CU176 Testing when it comes out with the updated patch set, to confirm if everything is working as expected.

> 
> > 2) Copy into your IPFire system the CU174 versions of the files that were
> > modified.
> > These are:-
> > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;
> > h=51d6e8431d6a00ffbb87aa24591c1fb67f0059b8;hb=refs/heads/core174
> > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=langs/de/cgi-bin/de.pl;
> > h=33730f0c319d8f3ae1b6cffc88db42d0d558cf46;hb=refs/heads/core174
> > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=langs/en/cgi-bin/en.pl;
> > h=729516538bcf40fc40007f92d4a2d0779fe2807f;hb=refs/heads/core174
> 
> This changed nothing -- for a second run, I also changed the "disabled" to
> "no-pass" in the config files. No dice. Rebooted between every such change.
> BTW, the "disabled" entry doesn't change, if that's something you want --
> it's still there after a reboot + disable/enable cycle of the connection.

I don't understand that. With the file changes made with the ovpnmain.cgi and de.pl/en.pl all back to their CU174 status then the n2n should work the same as it did with CU174. The profile would have had disabled in it for the CU174 systems. You can check and confirm that by looking at the contents of ovpnconfig in a backup file made from CU174 or earlier.

What errors are you getting in the logs when you are trying this profile after copying in the CU174 ovpnmain.cgi file

> 
> > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=lfs/web-user-interface;
> > h=da76a7d10efd31eb4e01a5973474f4aaf457d778;hb=refs/heads/core174
> 
> Can't figure out where this file should go, but it doesn't seem related to
> anything OpenVPN-ish?

Sorry, my fault. This file is only for the build process and is not needed in the installation. Ignore it.


It might be the simplest to do a fresh install of CU174 and wait for the full release of CU175, probably later this week.

(In reply to Adolf Belka from comment #44)
> What errors are you getting in the logs when you are trying this profile
> after copying in the CU174 ovpnmain.cgi file

Same as before:

11:51:38	n2nTEST[4559]: 	Exiting due to fatal error
11:51:38	n2nTEST[4559]: 	neither stdin nor stderr are a tty device and you have neither a controlling tty nor systemd - can't ask for 'Enter Private Key Password:'. If you used --daemo n, you need to use --askpass to make passphrase-protected keys work, and you can not use --auth-nocache.
11:51:38	n2nTEST[4559]: 	NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
11:51:38	n2nTEST[4559]: 	MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1191
11:51:38	n2nTEST[4558]: 	library versions: OpenSSL 3.1.0 14 Mar 2023, LZO 2.10
11:51:38	n2nTEST[4558]: 	OpenVPN 2.5.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINF O] [AEAD] built on May 24 2023
11:51:38	n2nTEST[4558]: 	WARNING: file '/var/ipfire/ovpn/certs/n2nTEST.p12' is group or others accessible
11:51:38	n2nTEST[4558]: 	WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discoura ged and considered insecure
11:51:38	n2nTEST[4558]: 	Cipher negotiation is disabled since neither P2MP client nor server mode is enab led

Well I installed 170; changed to Testing; updated to 175 Testing; rebooted. Restored a 174 backup and rebooted. Didn't work, same error. Restored a 173 backup for giggles, rebooted, same error. Updated the three files you linked. Same error. Wiped everything, installed 174 Stable, restored 174 backup, this immediately worked after a disable/enable. Last lines in ovpnconfig is as before:

udp4,1185,off,1500,,,,,,,,SHA512,AES-256-CBC,disabled

As the n2n connection didn't work from the command line, either, in 175 -- doesn't this mean something else is afoot?

Do you want me to upgrade to 175 Testing again?

(In reply to Man Grove from comment #46)
> Well I installed 170; changed to Testing; updated to 175 Testing; rebooted.
> Restored a 174 backup and rebooted. Didn't work, same error. Restored a 173
> backup for giggles, rebooted, same error. Updated the three files you
> linked. Same error. Wiped everything, installed 174 Stable, restored 174
> backup, this immediately worked after a disable/enable. Last lines in
> ovpnconfig is as before:
> 
> udp4,1185,off,1500,,,,,,,,SHA512,AES-256-CBC,disabled
> 
> As the n2n connection didn't work from the command line, either, in 175 --
> doesn't this mean something else is afoot?
> 
> Do you want me to upgrade to 175 Testing again?

No don't bother with CU175 Testing again. Stay with CU174.

I have figured out why you are having the problem still with CU175 Testing.

The reversion of the patch set was implemeted in next (which will become CU176) but it has not yet been applied to master (CU175 Testing). I had thought it had been update in one of the recent nightly builds but obviously not.

I will flag this up on the dev mailing list so that the reversion is also done on master befrore CU175 is released.

Thanks for the feedback.

@man grove

The old patch set reversion was merged into master (Core Update 175).

I tested this and got the same error message as you have been doing.

After some investigation I have identified that this is due to the change to openssl-3.x from openssl-1.1.1x

See Bug#13137. That bug will need to be fixed to be able to solve this bug.

An updated patch set has been submitted to fix this issue.

Tested on vm testbed and confirmed to fix both road warrior and net2net connections.

Also updates all existing connections without losing any of them as occurred with the previous patch set.

https://lists.ipfire.org/pipermail/development/2023-September/016551.html
https://patchwork.ipfire.org/project/ipfire/list/?series=3932

Confirmed working in 180 Testing with the same configuration that broke earlier. :-) Great work, thanks!

(In reply to Man Grove from comment #50)
> Confirmed working in 180 Testing with the same configuration that broke
> earlier. :-) Great work, thanks!

When you say it is working in CU180 Testing do you mean that you manually patched the appropriate files and tested it or that you presumed the change was in CU180 Testing? The patch set I submitted ysterday has not been merged yet so is not in any of the branches yet. Will likely end up in CU181.

The patch set has been merged into the next branch (Core Update 181)

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=8c5e71db2a53b3b443598a53dd01e43832234ca5

(In reply to Adolf Belka from comment #51)
> (In reply to Man Grove from comment #50)
> > Confirmed working in 180 Testing with the same configuration that broke
> > earlier. :-) Great work, thanks!
> 
> When you say it is working in CU180 Testing do you mean that you manually
> patched the appropriate files and tested it or that you presumed the change
> was in CU180 Testing? The patch set I submitted ysterday has not been merged
> yet so is not in any of the branches yet. Will likely end up in CU181.

Ouch, sorry. Thought it was in 180 Testing based on the timeframe.

@man grove

Don't worry. I had a lot of things I was working on and this bug just got left to one side by myself until recently so it is my fault.

It has been merged into next now which will become CU181 Testing, probably in 2 or 3 weeks, so it would be good if you can test at that time and hopefully confirm that everything works correctly this time round. Fingers crossed.

patch to include the script that adds the pass/no pass into the ovpnconfig to the backup.pl file.

This ensures that any restore of an earlier ovpnconfig without the pass/no pass entries has them added.

The script works successfully on any ovpnconfig version that already includes the pass/no pass entries.

https://lists.ipfire.org/mailman3/hyperkitty/list/development@lists.ipfire.org/thread/V63OMKF6RKMWZRJK2MD7IFC3GQV2PASZ/
https://patchwork.ipfire.org/project/ipfire/patch/20231015162822.7763-1-adolf.belka@ipfire.org/

(In reply to Adolf Belka from comment #55)
> 
> It has been merged into next now which will become CU181 Testing, probably
> in 2 or 3 weeks, so it would be good if you can test at that time and
> hopefully confirm that everything works correctly this time round. Fingers
> crossed.

Confirmed working -- if it made it into 181. :-)

I can confirm that it is in Core Update 181.

Core Update 181 Testing has been released

https://blog.ipfire.org/post/ipfire-2-27-core-update-181-is-available-for-testing

I have tested out Core Update 181 and the bug has been fixed after the core update.

Also tested out restoring from an earlier backup and the result is also working correctly.

https://blog.ipfire.org/post/ipfire-2-27-core-update-181-released