Arne Fitzenreiter

IPFire 2.19 - Core Update 111 in testing tree updated
by Arne Fitzenreiter, June 11

The first build of core111 has a gzip related bug so gunzip and zcat are not working. (This affects also the logviewer which cannot display older/compressed logs)

If zcat prints this:

zcat: compressed data not written to a terminal. Use -f to force compression.

You need to install the update again:

echo 110 > /opt/pakfire/db/core/mine
pakfire upgrade

Michael Tremer

IPFire 2.19 - Core Update 111 is available for testing
by Michael Tremer, June 1

For the start of the second half of the year, we have a brand new Core Update available for everyone who wants to help testing. It comes with various packages from all areas and some new features.

WPA Enterprise Authentication in Client Mode

The firewall can now authenticate itself with a wireless network that uses Extensible Authentication Protocol (EAP). These are commonly used in enterprises and require a username and password in order to connect to the network.

IPFire supports PEAP and TTLS which are the two most common ones. They can be found in the configured on the “WiFi Client” page which only shows up when the RED interface is a wireless device. This page also shows the status and protocols used to establish the connection.

The index page also shows various information about the status, bandwidth and quality of the connection to a wireless network. That also works for wireless networks that use WPA/WPA2-PSK or WEP.

QoS Multi-Queueing

The Quality of Service is now using all CPU cores to balance traffic. Before, only one processor core was used which caused a slower connection on systems with weaker processors like the Intel Atom series, etc. but fast Ethernet adapters. This has now been changed so that one processor is no longer a bottle neck any more.

New crypto defaults

In many parts of IPFire cryptographic algorithms play a huge role. However, they age. Hence we changed the defaults on new systems and for new VPN connections to something that is newer and considered to be more robust.



Various markers have been added to highlight that certain algorithms (e.g. MD5 and SHA1) are considered broken or cryptographically weak.



New Add-ons

Updated Add-ons

The samba addon has been patched for a security vulnerability (CVE-2017-7494) which allowed a remote code executing on writable shares.

As always, we would like to ask all users to participate in testing which will highly improve the quality of this update.

Please report any bugs to our bug tracker and provide any feedback on our development mailing list.

Arne Fitzenreiter

samba 3.6.25-65 in testing tree
by Arne Fitzenreiter, May 30

samba 3.6.25-65 has uploaded to testing trees. Please test and report to IPFire Mailinglist.

This contains an updated patchset from Red Hat to fix SambaCRY and some other issues.

Michael Tremer

Is AES-NI a requirement for everyone?
by Michael Tremer, May 2

Yesterday, I read that pfSense won’t support systems that do not have AES-NI from version 2.5 onwards any more. They state, that systems with AES-NI perform better and that this is available in many Intel processors from 2008 and AMD processors from 2010.

I am a little bit surprised by this post when it scrolled along my Twitter timeline and so far I cannot make any sense out of it. Here is why:

AES-NI does not mean performance

In some earlier and related posts on the planet, I have been trying to illustrate this point – so I will keep it short here.

We have come across a number of systems that have AES-NI, but they are overall not faster than a system that does not have these instructions. Our wiki even has a short table with some of these examples. AES throughput rather depends on clock speed of the processor and that can make up for missing AES-NI.

Performance isn’t everything

I run many IPFire installations that are out somewhere in the field and running on rather compact and efficient hardware. They work in an IoT scenario and transfer only a few kilobytes up to maybe a megabyte of traffic a day. That data is going through a VPN, but it does not matter at all if the system has AES-NI to encrypt it or not. It is effectively as fast either way.

However, if VPN performance is an issue, because you are running IPFire in a datacenter and need to have a VPN connection that can transfer up to 10G, then you will need that extra power. But this is not a scenario that everyone who is using IPFire has.

~14% of all IPFire systems actually have AES-NI

As of today and according to fireinfo (which is probably not representative, but a the best source that we have), only about 14% of all known IPFire systems have AES-NI. That’s not a lot. It does not always come with all Intel or AMD processors and it is not necessary. It appears that the majority of IPFire users doesn’t need AES-NI.


For the security of a VPN or where ever AES is used, it does not matter if AES-NI is used or if AES is performed in software (assuming that no implementation has any implementation problems).


So in conclusion, I do not have any technical reasons left over that I could consider. Those I listed above to not justify to me in any way that AES-NI is a must and that people need to have hardware that has it. Some of them even proof the opposite.

And although I also have been complaining a lot about that we have to support a lot of old and outdated hardware – and by that I mean decades old – this seems to be the only reason left: To incentivise people to buy new hardware which is quite conveniently only a click away.

And again, we do that, too. Having some kind of standard hardware makes things easier. However, that does not always make sense for everyone and therefore we leave that decision to you and work on making IPFire run on as many platforms as we possibly can.

And to make that crystal clear: Systems without AES-NI will be supported just as well as those that do have AES-NI.

Hottest posts 2017 2016 2015 2014 2013 2012 2011