https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/7?u=tphz IPFire 2.29 (x86_64) - Core-Update 197 Development Build: master/87e1047a After the upgrade, the selection "TLS Channel Protection" disappeared. When you select and click "Save Advanced Settings" - the setting does not save.
I have found the same effect. Although it is not shown on the Advanced Settings page the TLSAUTH setting of enabled or disabled and the TLS Has type are saved in the /var/ipfire/ovpn/settings file. I have also identified that if the hash type is changed then the ta.key file stays the same with what looks to be the SHA2-512 value. I have also identified that this issue with the TLS hash entry in the ta.key file not being updated when the TLS entry is modified was also showing this behavious in CU196 and probably for longer.
I have confirmed that the ta.key file was always the 2048 bit key, which I believe is the SHA2-512 hash, back in CU189 also.
(In reply to Adolf Belka from comment #2) > I have confirmed that the ta.key file was always the 2048 bit key, which I > believe is the SHA2-512 hash, back in CU189 also. So that problem is not coming from the OpenVPN-2.6 update, it has been present for a long time but nobody has flagged it up.
Ignore my entries about the ta.key not changing. I got mixed up. Once created the ta.key stays like that. It is used by the client to carry out the HMAC communication using the hash setting defined in the DAUTH option in the .ovpn file. So there is nothing wrong with the ta.key entry. The only issue is that the advanced settings are saved into the settings file and used by the client/server but are not saved into the Advanced Settings page, which always shows the initial set of settings rather than what has been saved. Sorry for my noise on this issue.
After having a look at the section to do with the advanced settings I realised that most of the parameters had their hash changed from %cgiparams to %vpnsettings except for the DCIPHER, DAUTH and TLSAUTH values. These stayed with %cgiparams and this hash is no longer filled from the settings file. Patch submitted to fix this. Tested out on my vm testbed system and it worked for me. https://lists.ipfire.org/development/20250820165147.21850-1-adolf.belka@ipfire.org/T/#u https://patchwork.ipfire.org/project/ipfire/list/?series=5102
Patch has been merged into next.
Also merged into master. After the nightly builds have completed then the fix can be evaluated in CU197 Testing.
Nightly build has been run so the change is available in Core-Update 197 Development Build: master/c293ac4b I have done a test of it and it worked for me. It would be good if the bug reporter can test this out to verify it is fixed.
(In reply to Adolf Belka from comment #8) > Nightly build has been run so the change is available in > Core-Update 197 Development Build: master/c293ac4b > > I have done a test of it and it worked for me. It would be good if the bug > reporter can test this out to verify it is fixed. It seems that after updating to version Core-Update 197 Development Build: master/87e1047a, the bug has been fixed. Regards
(In reply to iptom from comment #9) > (In reply to Adolf Belka from comment #8) > > Nightly build has been run so the change is available in > > Core-Update 197 Development Build: master/c293ac4b > > > > I have done a test of it and it worked for me. It would be good if the bug > > reporter can test this out to verify it is fixed. > > It seems that after updating to version Core-Update 197 Development Build: > master/87e1047a, the bug has been fixed. > > Regards That build version is from 9 days ago, before my patch fix was merged. Did you change the value in /opt/pakfire/db/core/mine from 197 to 196 and then do the update again? That should have resulted in a build version of c293ac4b
(In reply to Adolf Belka from comment #10) > (In reply to iptom from comment #9) > > (In reply to Adolf Belka from comment #8) > > > Nightly build has been run so the change is available in > > > Core-Update 197 Development Build: master/c293ac4b > > > > > > I have done a test of it and it worked for me. It would be good if the bug > > > reporter can test this out to verify it is fixed. > > > > It seems that after updating to version Core-Update 197 Development Build: > > master/87e1047a, the bug has been fixed. > > > > Regards > > That build version is from 9 days ago, before my patch fix was merged. > > Did you change the value in /opt/pakfire/db/core/mine from 197 to 196 and > then do the update again? That should have resulted in a build version of > c293ac4b Oops... Sorry, my mistake. Of course, after updating to Core Update 197 Development Build: master/c293ac4b, the bug is fixed. In the previous version, I tested the changes proposed in the link below. https://lists.ipfire.org/development/20250820165147.21850-1-adolf.belka@ipfire.org/T/#u
https://www.ipfire.org/blog/ipfire-2-29-core-update-197-released