The first update of the year will be an enormous one. We have been working hard in the lab to update the underlying operating system to harden and improve IPFire and we have added WPA3 client support and made DNS faster and more resilient against broken Internet connections.

This is probably the release with the largest number of package updates. This is necessary for us to keep the system modern and adopt any fixes from upstream projects. Thank you to everyone who has contributed by sending in patches.

If you want to help us out, please send us a donation.

DNS Resolution Improvements

The DNS proxy working inside IPFire will now reuse any TLS and TCP connections for DNS resolution making it substantially faster. Before, a TCP or TLS connection had to be opened and closed after a response was received causing a lot of overhead.

Please consider if your setup can run DNS-over-TLS to protect your privcacy.

If you had a brief outage of your Internet connection, or if any or all of the upstream name servers did not respond, it could become possible that the DNS proxy no longer retried accessing them. This was due to some DoS protection being overly ambitious which has been changed to constantly try to reach any servers that are down.

WPA3 Client Support

The previous Core Update added WPA3 support for access points. This is now being complimented by adding it for the client side, too.

If you are running your RED interface as a client to another wireless, it can now use WPA3 to authenticate to the network and to encrypt packets. WPA2 has also been improved by optionally using SHA256 over SHA1 if the access point supports it.


There is a number of various changes in this release:

  • Various command injections and privilege escalations where reported by Albert Schwarzkopf in the security layer between the web user-interface and the operating system. With those, an authenticated unprivileged user could gain root access to the operating system.
  • DDNS: The UI has been improved for providers that support "token authentication"
  • SSH sometimes failed to end itself when the system was shut down which caused an unnecessary delay
  • IPsec: XFRM policy lookup has been disabled for VTI interfaces
  • Keyboard support on virtualised systems on Microsoft Hyper-V was sometimes not working and has now been fixed.
  • Various cosmetic fixes for the web user interface and various code cleanup has been conducted by Matthias and Leo.
  • Updated packages: acl 2.2.53, acpid 2.0.32, automake 1.16.3, arping 2.21, bind 9.11.26, ccache 3.7.12, curl 7.75, dbus 1.12.20, dhcpcd 9.3.4, dma 0.13, fcron 3.2.1, findutils 4.8.0, fuse 3.10.1, hyperscan 5.4.0, iproute2 5.10.0, ipset 7.10, iptables 1.8.7, iw 5.9, less 563, libassuan 2.5.4, libgcrypt 1.9.1, libgpg-error 1.41, libhtp 0.5.36, libloc 0.9.5, libseccomp 2.5.1, logrotate 3.18.0, logwatch 7.5.5, lzip 1.22, kmod 28, knot 3.0.5, newt 0.52.21, PAM 1.5.1, pptp 1.10.0, sed 4.8, sqlite 3.34.0, texinfo 6.7, tzdata 2021a, procps 3.3.16, sudo 1.9.5p1, unbound 1.13.0, wget 1.21


  • Updated packages: bacula 9.6.7, bird 2.0.7, c-ares 1.17.1, cifs-utils 6.12, clamav 0.103.1, cups-filters 1.28.7, ddrescue 1.25, dehydrated 0.7.0, elfutils 0.182, fireperf 0.1.0, firmware-update 20210107, flashrom 1.2, hostapd 2021-01-18, hplip 3.20.11, htop 3.0.5, iperf 2.0.14a, iperf3 3.9, kerberos 1.18.3, lvm2 2.02.187, lynis 3.0.3, minicom 2.8, monit 5.27.1, nano 5.5, p7zip 17.03, postfix 3.5.8, samba 4.13.4, screen 4.8.0, shairport-sync 3.3.7, sshfs 3.7.1, strace 5.10, stunnel 5.57, tor, tshark 3.4.2, QEMU 5.2.0, wpa_supplicant 2021-01-18

I hope that everyone had a good start into the new year. The last one probably has been tough for most of us in many different ways. It has been for the IPFire Project, too.

But we have tried to make the best we can out of it, and for this year, we have come up with an important decision that I would like to announce today: The development team has decided that we have to "cut costs" and we have decided to end support for the 32 bit x86 architecture by December 31st 2021.

Spring Cleaning Has Come Early

Usually we have a little spring cleaning every year, but this year it has to be something bigger. IPFire has its roots way in the past and therefore we used to carry some technical features that are not relevant any more.

Most often this is about hardware. We used to support ISA network cards and ISDN dial-up at some point. Over time, this hardware has aged, services that required them were shut down.

Now, we are getting rid of support for i586. In our point of view, it is no longer fit for purpose for a number of reasons and the user base has been declining over many years. Therefore it is no longer a good investment of development time since not many people are benefitting from it.

On this blog, I have talked about this topic multiple times and I have repeatedly said that we, the whole IPFire development team, are going to do our best to keep support for 32 bit architectures alive for as long as we can. But we had to spend more and more hours for fixes that only affected 32 bit architectures. They were many different bugs, but it all boils down to: There are not enough testers out there any more.

We unfortunately found many serious issues after the release and it caused that a few systems had to be re-installed because IPFire was no longer able to boot. This was an urgent matter because we did not know what was going on. After a number of people of the development team have dropped whatever they were working on immediately, we found that it was an issue in glibc, the standard C library which simply was not tested on a native i586 processor any more.

This was a quite unsatisfactory event for many, and we had many releases delayed because of outstanding issues with those architectures that were time-consuming to resolve.

Currently, only 7% of all IPFire systems are not capable of running the 64 bit version. We have taken the decision to give everyone who is still using IPFire on those machines one year to upgrade to new hardware. After December 31st 2021, we will no longer support the i586 architecture.

Besides freeing up development time, the 64 bit version is much superior to its 32 bit counterparts for a couple of reasons:

  • It is a much more modern architecture and processors have received many new features that cannot be used by 32 bit code. Code runs faster, there is extra acceleration like SSE and AVX for maths and pattern matching which substantially speed up the IPS and other programs.
  • The Linux kernel's hardening for 32 bit isn't great. It has already been a second-class architecture for a while and many fixes for Intel's security issues have not been ported back in full. The Linux kernel does not have a maintainer for the 32 bit branch of the ARM architecture in years. For best security, you will need new hardware.
  • Modern hardware will also be more power efficient and quiet.

Many major distributions have already dropped support for i686 a long time ago. Microsoft has announced in 2020 that it will discontinue Windows for 32 bit. Although those changes are even more inevitable because of system requirements being too high for 32 bit hardware, IPFire in theory still runs on older hardware.

In fact, we have a background of repurposing old hardware. But since modern hardware is a lot cheaper and there are great, modern and very affordable appliances out there, we would like to - over time - increase our system requirements, too.

Systems with 256MB of memory are incredibly hard to support when everything eats more and more memory.

Those reasons do to some extend apply to the ARM architecture as well, but the development team has decided that we are still going to continue supporting this one for the time being as not enough alternative hardware for the 64 bit architecture is available, yet.

Take Your Network To A New Level

If you have been running IPFire an older piece of hardware and you would like to upgrade, the development team would like to recommend the IPFire Mini Appliance which you can purchase here:

It is the best option for a small and energy-efficient appliance which is perfectly supported by IPFire.

I feel that this is a pledge that needs repeating since many projects have recently turned their backs at Open Source software. Here is a quick ready why this is very dangerous to the future of the internet.

I am seriously concerned about the future of the Open Source eco system. Times are tough. The world is battling a pandemic and many companies are in trouble. Some have already shut down, others are close to that and that is a very bad thing in its own right.

Low confidence in business causes that people might be more likely to be made redundant and obviously having a little bit of money on the side would help you sleeping better in the night. But if that money would come from software that you have been developing as a hobby or slightly more than that, I can only tell you: Do not be greedy.

It is sad to see some projects going closed source and leaving loyal users just out there without a home. What now? Maybe your software should have not been free in the first place if the goal is to earn money with it. It is as simple as that.

Not taking money for something makes a product so much more accessible: We know for a fact that IPFire is being used in so many places where a commercial firewall solution would have been too expensive. One option would have been to not use anything at all, but instead IPFire was available and could be used for free.

I do not have a problem with commercial software

...because I do not believe in it. We have seen many projects that have been coming and going and that have changed their shape over time, but I do not think that many of them were successful.

Starting from Bitkeeper, a source code management solution used by the kernel which revoked the license what made Linus start Git - the most often used SCM right now. RedHat has just announced that there will be no more CentOS 8 and has broken a promise without any warning and is now offering discounted licenses for RHEL. I am sure you have all used software that used to be free and that become a commercial product at some point. The list is very long and I am sure we all have fallen victim to such a license change.

Today, pfSense has been added to it, although the project was regarded closed by many people for years. Nevertheless this one makes me particularly sad, since the choice of freely available firewall solutions like IPFire is becoming smaller and smaller.

There is nothing wrong with choosing to release your software under closed terms. Developers can freely decide what license they want to use - just as I do with my own software.

But I am very clearly in the Open Source camp - and let's face it: the Internet is built on this - because it has so many advantages:

  • It can be used for free
  • It can be studied and so many could learn about good software design
  • It is a great thing where many can participate in and it helps building vibrant communities

But most importantly for me:

If you are doing security, and you won't give me the source code, you are doing it wrong

How can I trust you if you are not willing to prove it?

IPFire is Open Source and is regularly reviewed by researchers who send us bug reports and - sometimes even - report vulnerabilities. That allows us to make IPFire better and if you still have any doubt you can hire someone who has the required expertise and have them run you through every single line of code.

Every line of code that is going into IPFire is being reviewed by many people and experts of various areas can join in and help to make it function the best way possible.

We have an open and reproducible build process. You can trust us that you are running the code that you have read and you can verify it by compiling IPFire again on your own computer.

Please help us out

Of course this requires a lot of time. For some people this has become their job, for others it is a really big side job. And of course we need a lot of resources to keep our servers running.

To keep us going, and to give us a little bit extra so that we can push IPFire further and do that even faster, I would to ask you today to donate.

Our software and everything else is free - but it isn't free to us. So we need your donation.