In general - connections (N2N , RW) created before the upgrade to 197 stopped working.
Another problem with RoadWarrior connection -
Warning: route gateway is not reachable on any active network adapters
OpenVPN pushes Dynamic Client Subnet route instead of static subnet set for RW client. (Static IP address pools)?
Edit
A bug has been reported.
I figured out what the issue is with your connection. By default the OpenVPN for Android app expects to see the ciphers
AES-256-GCM
AES-128-GCM
CHACHA20-POLY1305
This list is the default set of ciphers for OpenVPN, which the app uses.
So when I tried to make a connection using the same settings as you had on your main screen, ie with the cipher AES-256-CBC selected then the OpenVPN for Android refused to make a connection because it didn’t get offered a cipher in its default list.
You must have then edited the profile in the app by going to the tab labelled AUTHENTICATION/ENCRYPTION and in the encryption section there is an option labelled Encryption ciphers which would have been marked as Not set. This means that the OpenVPN for Android app will only accept one of its default ciphers.
I suspect you then added into that option AES-256-CBC but without also specifying the above default ciphers so that AES-256-CBC will then be the only cipher that OpenVPN for Android will accept.
You should enter into that option the following
AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
This will then keep the openvpn default ciphers and add your AES-256-CBC cipher into the client allowed list.
Then when you connect with the CU197 it will then do negotiation and find that it has three ciphers that overlap and will choose the strongest of those three.
If you need to go back to accessing your CU196 system then the entry for AES-256-CBC will allow that old version to work.
EDIT:
I just took the IPFire CU196 using the AES-256-CBC cipher with the OpenVPN for Android app with the 4 ciphers shown above entered into it. This allowed the AES-256-CBC cipher to be accepted and I got a working connection.
I then updated to CU17 and cipher negotiation occurred between the android app and the CU197 IPFire system and AES-256-GCM was selected and gave me a working connection. So I have been able to verify that my suggestion of adding the 4 ciphers into your android app worked.
I would suggest that once you are fully running with released CU197 that you should clear all the ciphers from the Encryption section on the android app. That way the app will always use the latest default ciphers from OpenVPN, which will also be the case with IPFire. That way in the future negotiation will always successfully find a common cipher that is the strongest available.
Indeed, I do have AES-256-CBC in the Encryption → Encryption ciphers section.
By modifying it with the values you gave me
AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
I was able to connect to the CU197 version after the upgrade.
Does this mean I need to modify all my OpenVPN clients to migrate to CU197?
That depends on the clients and what their default set of ciphers was and whether you added AES-256-CBC to their default list or replaced the default list with AES-256-CBC.
If you modified all your clients to only use AES-256-CBC, then yes you will need to modify them all.
The better option would be to go into the CU197 Advanced settings page and select AES-256-CBC in the fallback-cipher section. This should then allow your clients to continue to use AES-256-CBC and you can then modify the settings in your clients as and when you can make the time one by one. When all clients have been adjusted to use the latest defaults, AES-256-GCM etc listed above, then at that point you can change the fallback cipher section back to disabled, because everything will be working with cipher negotiation of the defaults.
Thank you.
That’s good to know; it took me a while to get OpenVPN working properly with this configuration.
I was able to get my Android tablet working by modifying Advanced Settings like this.
Note: These settings don’t appear when I return to the Advanced Settings page.
Edit : It also works on both IPFire versions this way with my windows laptop (OpenVPN GUI v11.51.00)
But as I mentioned earlier, I think I’ll migrate to Wireguard 
.
I also noticed that when migrating /var/ipfire/opvpn/server.conf CU197, the parameter
data-ciphers-fallback AES-256-CBC
was replaced by
cipher AES-256-CBC
The change suggested above restores data-ciphers-fallback AES-256-CBC.
Couldn’t this also be the source of the problem?
Edit : it’s the opposite
cipher AES-256-CBC
was replaced by
data-ciphers-fallback AES-256-CBC
Sorry
Didn’t I ask to reorganize the forum before? Creating a subforum ”Testing” or whatever, put the core testing announcements in there on top of it and just have regular infos as before + testing topics of users linked in there. The testing topics are seperate in this subforum. Also the topics must always contain the core number in its title.
Atm it’s like always mixing up different things in a single thread. That’s not handy.
I use these testing threads to identify if there is a simple fix needed, that I will go away and submit as a patch, or the problem looks to be real or has been confirmed by myself or other users, in which case I will suggest they raise a bug.
I will never come back to these threads to go back through them to figure out what might have been missed.
Confirmed issues in the Testing phase should be raised as bug reports.
This is not what I’ve been talking about.
With the removal of cpufrequtils, will there be a way to go back to different CPU governor if the new one isnt suitable?
Previously I had a lot of issues with the default governor (can’t remember what that is) and my AMD RX-427BB.
According to the IPfire CPU frequency graphs, it wouldn’t use anything above 1.8GHz, basically the CPU frequency graph was locked at it.
I had to install cpufrequtils to change to ‘ondemand’ to get full use of the 3.2GHz clock. Basically doubled my internet download speed from about 200Mbps throughput to almost 400Mbps.
Yes, you can configure the governor manually in /etc/sysconfig/cpupower by setting something like this:
GOVERNOR=ondemand
In your case (assuming that the CPU won’t support schedutil), you should already fall back to “ondemand”. However, I did not have an AMD system available for testing and we are still awaiting feedback from people with other hardware.
So I would recommend to install the test update and let us know. That way we have a change to apply any fixes before the release.
I performed the update on the 8/10. Everything seems to be working well. I did see a change in the CPU frequency. I am using a Dell OptiPlex 990 with an Intel i7. I have been using it for a couple of months. If you need more info let me know.
Danny
How much energy are you saving now?
Energy is not something I keep track of. I’m not sure how to find out.
Update to 197 on my AMD RX427BB seems to have gone ok, I’ve lost the ondemand governor, but schedutil seems to be working largely the same.
[root@ipfire ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil
[root@ipfire ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
userspace powersave performance schedutil
[root@ipfire ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2700000 2500000 2200000 1800000 1400000
Ran a connection speedtest and got the same speed as pre-update ~ 850mbps
CPU frequency seems to be less volatile after the update. Looks like it boosted around boot, but not again since - however as above I’ve not noticed any performance difference.
Edit: used sysbench addon to generate some load on one core, and it hit 3.2GHz, so looks to be ok.
With CU 197, on my N100 firewall, the governor has shifted from performance to powersave.
What changed your mind?
Indeed, since switching the governor to powersave
cpupower frequency-set -g powersave
The frequency graph has stabilized.
Hello,
I noticed the same - after CU197 the CPU Frequency graph shows almost no variation of CPU frequency.
This behavior was also on CU194 - see my post here Core Update 194 CPUs back to 192 levels - Community - IPFire Community
Question: what should the graph display: a big variation, or a flat (like) evolution?
Here are my fresh uograded cu197 settings for /sys/devices/system/cpu[0-9]/cpufreq
===== CPU Model Information =====
Intel(R) N100
----------------------------------
===== cpu0 Configuration =====
Vendor ID: GenuineIntel
Model Name: Intel(R) N100
CPU MHz: 1300.005
File: affected_cpus
0
----------------------------------
File: base_frequency
800000
----------------------------------
File: cpuinfo_max_freq
3400000
----------------------------------
File: cpuinfo_min_freq
700000
----------------------------------
File: cpuinfo_transition_latency
0
----------------------------------
File: energy_performance_available_preferences
default performance balance_performance balance_power power
----------------------------------
File: energy_performance_preference
balance_performance
----------------------------------
File: related_cpus
0
----------------------------------
File: scaling_available_governors
performance powersave
----------------------------------
File: scaling_cur_freq
3091894
----------------------------------
File: scaling_driver
intel_pstate
----------------------------------
File: scaling_governor
powersave
----------------------------------
File: scaling_max_freq
3400000
----------------------------------
File: scaling_min_freq
700000
----------------------------------
File: scaling_setspeed
<unsupported>
----------------------------------
===== cpu1 Configuration =====
Vendor ID: GenuineIntel
Model Name: Intel(R) N100
CPU MHz: 1600.019
File: affected_cpus
1
----------------------------------
File: base_frequency
800000
----------------------------------
File: cpuinfo_max_freq
3400000
----------------------------------
File: cpuinfo_min_freq
700000
----------------------------------
File: cpuinfo_transition_latency
0
----------------------------------
File: energy_performance_available_preferences
default performance balance_performance balance_power power
----------------------------------
File: energy_performance_preference
balance_performance
----------------------------------
File: related_cpus
1
----------------------------------
File: scaling_available_governors
performance powersave
----------------------------------
File: scaling_cur_freq
3069204
----------------------------------
File: scaling_driver
intel_pstate
----------------------------------
File: scaling_governor
powersave
----------------------------------
File: scaling_max_freq
3400000
----------------------------------
File: scaling_min_freq
700000
----------------------------------
File: scaling_setspeed
<unsupported>
----------------------------------
===== cpu2 Configuration =====
Vendor ID: GenuineIntel
Model Name: Intel(R) N100
CPU MHz: 1599.971
File: affected_cpus
2
----------------------------------
File: base_frequency
800000
----------------------------------
File: cpuinfo_max_freq
3400000
----------------------------------
File: cpuinfo_min_freq
700000
----------------------------------
File: cpuinfo_transition_latency
0
----------------------------------
File: energy_performance_available_preferences
default performance balance_performance balance_power power
----------------------------------
File: energy_performance_preference
balance_performance
----------------------------------
File: related_cpus
2
----------------------------------
File: scaling_available_governors
performance powersave
----------------------------------
File: scaling_cur_freq
2985542
----------------------------------
File: scaling_driver
intel_pstate
----------------------------------
File: scaling_governor
powersave
----------------------------------
File: scaling_max_freq
3400000
----------------------------------
File: scaling_min_freq
700000
----------------------------------
File: scaling_setspeed
<unsupported>
----------------------------------
===== cpu3 Configuration =====
Vendor ID: GenuineIntel
Model Name: Intel(R) N100
CPU MHz: 1599.981
File: affected_cpus
3
----------------------------------
File: base_frequency
800000
----------------------------------
File: cpuinfo_max_freq
3400000
----------------------------------
File: cpuinfo_min_freq
700000
----------------------------------
File: cpuinfo_transition_latency
0
----------------------------------
File: energy_performance_available_preferences
default performance balance_performance balance_power power
----------------------------------
File: energy_performance_preference
balance_performance
----------------------------------
File: related_cpus
3
----------------------------------
File: scaling_available_governors
performance powersave
----------------------------------
File: scaling_cur_freq
2908281
----------------------------------
File: scaling_driver
intel_pstate
----------------------------------
File: scaling_governor
powersave
----------------------------------
File: scaling_max_freq
3400000
----------------------------------
File: scaling_min_freq
700000
----------------------------------
File: scaling_setspeed
<unsupported>
----------------------------------