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.

Before we talk about what is new, I would like to as you for your support for our project. IPFire is a small team of people from a range of backgrounds sharing one goal: make the Internet a safer place for everyone. Like many of our open source friends, we’ve taken a hit this year and would like to ask for your continued support. Please follow the link below where your donation can help fund our continued development: https://www.ipfire.org/donate.

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.

Misc.

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, OpenSSL 1.1.1j, 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

Add-Ons

  • 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 0.4.4.7, tshark 3.4.2, QEMU 5.2.0, wpa_supplicant 2021-01-18

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.

Misc.

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, OpenSSL 1.1.1j, 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

Add-Ons

  • 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 0.4.4.7, 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.