[Testing] IPFire 2.29 – Core Update 197

Community
1

Hi all,

We’ve opened up IPFire 2.29 – Core Update 197 for testing.
Blog post with full details: https://www.ipfire.org/blog/ipfire-2-29-core-update-197-is-available-for-testing

Highlights

  • OpenVPN 2.6 upgrade – modernised codebase with better security and wider client compatibility. Existing configs should keep working.

    • Single-file client export (no more ZIPs).

    • Cipher negotiation by default (with fallback for older clients).

    • Compression removed upstream; server tries to disable it where possible.

    • Subnet topology dropped: each client now uses a single IP, expanding pool capacity.

    • Many UI clarifications; most settings can be changed without stopping road-warrior first.

  • Power saving / CPU frequency – systems now clock down by default using Intel P-State or the kernel’s schedutil governor (where supported), reducing power and heat. cpufrequtils is no longer needed.

  • Plus the usual stack of security and package updates, kernel rebase, and a few nice quality-of-life fixes (see blog).

What we need you to test

1) OpenVPN

  • Connectivity with older and newer clients (Windows, macOS, Linux, mobile).

  • Importing the single-file client config into your clients.

  • Behaviour of cipher negotiation (and any fallback).

  • Any warnings related to compression on legacy clients.

  • Road-warrior restart behaviour (clients should reconnect cleanly).

Please include client OS/version, OpenVPN client version, and any relevant logs if you hit issues.

2) CPU frequency / power

  • Whether your system uses Intel P-State or schedutil after the update.

  • Impact on idle power draw, temperatures, and latency/throughput under load.

  • Any regressions versus your previous governor settings.

Hardware details (CPU model, platform, NICs) and before/after observations are super helpful.

3) General checks

  • Upgrade path from your current Core Update.

  • Restoring >2 GiB backups via the web UI.

  • WireGuard: importing configs with Windows line endings.

  • Anything else you rely on day-to-day (add-ons, reporting, IPS, etc.).

How to get it

Switch to the Testing channel and update to Core Update 197. As always, take a backup before you start.

Please post results and issues in this thread so we can keep feedback in one place. Constructive, reproducible reports with logs make fixes much faster for everyone.

Thanks for helping us shake this one down!

Cheers,
A G

4 Likes
2

Hello everyone,

This is very very important! We have made so many changes to OpenVPN and we have tested it very well, too. However, with so many different deployments out there, we would really appreciate if all of you could help us to verify that there are no regressions here. There should not be, instead you are getting a lot of new features and protection!

5 Likes
3

Looks good so far, I have only tested Net2Net connections on this Testing however – connecting a 197 client to multiple 196 and 194 systems. But everything seems to work and the OpenVPN UI is much nicer now, too.

Running 197 virtualized under KVM btw.

1 Like
7

IPFire 2.29 (x86_64) - Core-Update 197 Development Build: master/87e1047a

obraz

After the upgrade, the selection disappeared.

When you select and click Save Advanced Settings - the setting does not save.

8

It does actually save it into the /var/ipfire/ovpn/settings file, it just doesn’t save the settings on the advanced page, which it should do.

It also doesn’t update the TLS-Authentification-Key which stays at what looks to be a SHA2-512 and is what is embedded in the .ovpn file.

The SHA2-512 was changed to be the default value but it should get changed on the TLS-Authentification-Key entry to the one that was selected.

If you leave the TLS enabled checkbox unchecked and save then the settings file has it as disabled and the .ovpn file ends up without any TLS cert entry as it should do so that works. It is just if it is enabled then SHA2-512 is always selected irrespective of hash has been selected.

Can you please raise a bug for this issue.
https://www.ipfire.org/docs/devel/bugzilla

9
1 Like
10

Interestingly, the issue with the TLS hash not being used as selected was already present in CU196. In that version changing the value was saved but the TLS-Authentification-Key was always the same also. Never changed. Not sure how long that has been like that.

Would just mean that whatever hash you selected it would always make the TLS key the same value (SHA2-512 I believe).

However if the cipher selected is AES-GCM then that has an inbuilt hash anyway so any hash selected will be ignored anyway by the client.

However, if you used an AES-CBC cipher then the .ovpn file would have the selected TLS hash defined but if that was not SHA2-512 then the ta.key and the TLS hash type would not match in the client. This has been like this since at least CU196 but probably much longer.
I will test out what happens if the above situation occurs with CU196.

EDIT:
I have confirmed that the ta.key is always a 2048 bit key irrespective of which TLS hash is selected in CU196 and also back in CU189.

I will additionally provide my input into the bug report.

EDIT:
I have realised that I have been mixing things up.

The ta.key is used to create the hmac using the appropriate hash that is define in the DAUTH setting.
So the ta.key is created once and never changes. Then the tls-auth entry being enabled causes the client to create the hmac using the selected hash and the ta.key at the server allows it to decrypt that and confirm the hmac.

So the only issue is that the settings are saved into the settings file but not shown in the advanced settings wui page.
Simpler issue.
Sorry for the noise from myself.

2 Likes
11

Isn’t there a installation media to test the whole thing?

12

Could you explain what you mean.

There is the installation iso for CU197 Testing that can be used for a fresh install instead of an upgrade but I am not sure if that is what you are meaning.

13

Yes, but where.

14

x86_64
https://nightly.ipfire.org/master/latest/x86_64/

aarch64
https://nightly.ipfire.org/master/latest/aarch64/

2 Likes
15

Thanks. Can you please put that links in your further announcements?

16

Those links will always be the same as when the Testing version is released it is in the master branch.

So you can just create bookmarks for those url’s.

17

And you can put those in your announcements :wink: .

18

openVPN no longer works after upgrade 197 on my IPFire test (It works on 196)

Here’s my configuration 196

Capture d'écran 2025-08-11 214126
Capture d'écran 2025-08-11 214126517×480 26.2 KB

I get this message upon reboot

ipfire-2025-08-11-21-45-27
ipfire-2025-08-11-21-45-271280×800 11 KB

Here’s the connection log from my Android phone (OpenVPN for Android 0.7.61)

2025-08-11 21:52:37 AUTH: Received control message: AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)
2025-08-11 21:52:37 TCP/UDP: Closing socket
2025-08-11 21:52:37 SIGTERM[soft,auth-failure] received, process exiting
2025-08-11 21:52:37 MANAGEMENT: >STATE:1754941957,EXITING,auth-failure,
2025-08-11 21:52:37 Unscheduling VPN keep alive

20

Do you get this every time you reboot?

It looks like during stopping the openvpn road warrior server is successfully stops the openvpn-rw daemon but then the next part of the initscript is flushing all the firewall rules and the xtables.lock is still in place from some previous step but I can’t figure out from what.

Do you have a lot of firewall rules in your setup. By a lot I mean like 100 or more?

In all my tests of updating from CU196 to CU197, first when it was still in unstable, with many many updates and then with the Testing release where I have run 7 system updates, I have never seen that message about the xtables.lock file.

I am not sure what other application could be holding the xtables lock.

Can you confirm that you have squid, the web proxy, disabled. If enabled then the first app that is shutdown is squid, followed by grub-btrfsd, then fcron then the openvpn-rw which shuts down the openvpn authenticator followed by the openvpn road warrior server.

So no squid being shown should indicate squid is disabled.
grub-btrfsd is not running so it can’t be holding the xtables lock and the fcron initscript doesn’t call anything to do with the firewall.

If you are able to reproduce this every reboot then I would raise a bug on it. Then someone more knowledgeable can help you track down what the issue is.

This means that none of the default set of AES-GCM 256 bit, AES-GCM 128 bit and ChaCha20-Poly1305 ciphers matched with any ciphers that your client was able to negotiate.

I am also using the same version of OpenVPN for Android and mine connected with no problems. My original cipher I had defined was AES-GCM 256 bit.

It looks like you had selected AES-CBC 256 bit.

Go into the advanced settings section and try adding the AES-CBC 256 bit entry in the ciphers section. You can also try adding the AES-CBC 256 bit entry in the Fallback Cipher entry.
Alternatively you could change the cipher on the client from AES-CBC 256 bit to AES-GCM 256 bit.

I will try and find some time over the next few days/week to set up a CU196 system with AES-CBC 256 bit on the server and the android client and the see what happens with an update to CU197.

21

This is just a migration test.

No, I only get this message upon first shutdown after the update

I no longer get it after that.

My firewall only has about fifty rules.

Squid is enabled.

For OpenVPN, AES-CBC (256 bit) was the default value on IPFire when I created it.
I don’t have a phone to test another configuration at the moment.
If I need to change my OpenVPN configuration in 197, I’ll switch to Wireguard instead.

Thank you for your investigation.

22

So this is finally gone after the first reboot?

23

Yes, the message only occurred during the first shutdown after the upgrade, without any further incident.

24

KVM, UEFI, RAID: still not working

{C6769C48-5657-4E67-8751-00DB8458C5BB}
{C6769C48-5657-4E67-8751-00DB8458C5BB}1598×1001 27.2 KB