Today, we are releasing IPFire 2.25- Core Update 155 which comes with various security fixes to mitigate NAT Slipstreaming attacks and important fixes in the OpenSSL library which allowed that attackers could have crashed services that use TLS on the firewall.

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:

We recommend installing this update as soon as possible and reboot the system.

Mitigating NAT Slipstreaming

Peter has recently announced our measures against NAT Slipstreaming. Through feedback from the community, we have seen that most people are not affected by these changes.

We are going to disable and remove support for all Application Layer Gateways. This includes SIP, FTP, H.323, IRC, PPTP and TFTP. They will be automatically disabled on systems that install this update and will no longer be available.

This change might require some attention if you are using any software that relies on the ALG. This is most likely the case for VoIP solutions that use SIP. From feedback during the testing period of this update, we can confirm that only a very small fraction of users is affected.

Spanning Tree Protocol support in Zone Configuration

The zone configuration allows configuring Spanning Tree Protocol (STP) for bridges. Since it is possible add multiple interfaces to the same bridge, it becomes a danger that loops are being created on the network. STP avoids those by disabling bridge ports when a loop is being detected.

Zone Configuration with STP

OpenSSL Security Vulnerabilities

The OpenSSL team released version 1.1.1k which fixes two rather severe security issues:

  • CVE-2021-3449: TLS servers could have been crashed with a maliciously crafted renegotiation message. In IPFire this could be used to deny service of the web user interface or some add-ons like haproxy
  • CVE-2021-3450: Enabling strict certificate checking caused the opposite effect that some certificates were evaluated as valid when they were actually not

We are also shipping fixes from an earlier OpenSSL release (1.1.1j) which were of lower severity: CVE-2021-23841, CVE-2021-23839 & CVE-2021-23840


  • The wireless client configuration is now processing priorities correctly. Before, wireless networks were prioritised in the opposite order
  • The QoS graphs will now have consistent colours in the downstream and upstream direction
  • The Update Accelerator "Passive Mode" option has been clarified
  • New packages: PCRE2, which is an improved version of PCRE, implementing Perl-compatible Regular Expressions
  • Updated packages: attr 2.4.48, autoconf 2.71, bind 9.11.28, freetype 2.10.4, iproute2 5.11.0, ipset 7.11, lcms2 2.12, libgcrypt 1.9.2, libhtp 0.5.37, libffi 3.3, libxcrypt 4.4.17 which replaces libcrypt which came bundled with glibc, lz4 1.9.3, lzo 2.10, mpage 2.5.7, net-tools 2.10, nettle 3.7.1, openssh 8.5p1, Python 3.8.7, qpdf 10.3.0, rust 1.50, sqlite3 3.34.1, squid 4.14, suricata 5.0.6, sysvinit 2.98, tar 1.34, tcl 8.6.11, unbound 1.13.1, wget 1.21.1
  • IPFire can experimentally be compiled for RISC-V for 64bit
  • Various older versions of operating system libraries have been removed. They were needed to keep older programs compatible without need of recompiling them. Those were: Berkeley DB, GMP, libjpeg, PCRE, readline
  • On i586, SSE2-optimised versions of performance-critical libraries have been dropped. This affects GMP and OpenSSL, which might result in lower VPN throughput with OpenVPN on affected systems. Support for this will be removed with the next release of glibc.
  • The unattended installer started in regular mode on serial consoles
  • Roberto Peña has contributed Spanish translation for the Captive Portal


  • Updated packages: elfutils 0.183, hplip 3.21.2, fireperf 0.2.0, krb5 1.19.1, mc 4.8.26, monit 5.27.2, nano 5.6, nagios_nrpe 4.0.3, nagios-plugins 2.3.3, stunnel 5.58, tor, tshark 3.4.3

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:

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, 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


  • 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

Launching IPFire on Exoscale

by Michael Tremer, November 9

Today, we are launching IPFire on Exoscale, the GDPR-compatible European Cloud Provider based in Switzerland.


For the two years that IPFire is available on Amazon EC2, we have often received feedback from various customers about their data privacy concerns. GDPR and the generally higher data protection regulation in Europe is making it difficult for many people to find the right cloud provider that complies with those laws.

We are proud to offer an option for those customers.

With data centers in Germany, Switzerland, Austria, and Bulgaria, Exoscale is promising that your data won’t “travel halfway around the world”. Privacy has been built into the cloud from the first moment.

With competitive pricing and a user interface that is very easy to use, they are a brilliant alternative to the big, well-known cloud providers.

IPFire in the Cloud, just like you are used to it

IPFire in the cloud enables your business to grow above and beyond. It is the same firewall appliance that you know from your on-premise data center, just in the cloud - and therefore more versatile and flexible.

You can host your infrastructure of web servers, mail servers, and have it protected by a powerful firewall while accessing them easily through a secure VPN connection.

Your cloud infrastructure will grow with you to whatever size you need it to. Whether your website is becoming more popular, or your company is opening more branch offices that need to be securely connected to your central servers. Just upgrade your cloud instance and you have added more CPU power and memory to handle whatever challenges you face.

From a small prototype environment to a 10 Gigabit router. IPFire grows with you.

See some more examples on the detailed product page.

Try out IPFire on Exoscale for free today.

Today, we have updated IPFire on AWS to IPFire 2.25 - Core Update 146 - the latest official release of IPFire.

Since IPFire is available on AWS, we are gaining more and more users who are securing their cloud infrastructure behind an easy to configure, yet fast and secure firewall.

This update brings a new kernel as well as many other exciting changes.


The most important change for the cloud is that on AWS, IPFire will now default to a MTU of 9001 bytes for all internal interfaces. The RED interface will remain on 1500 bytes, since this is the Internet defaults to that size and we prefer IPFire performing any fragmentation and reassembly of packets over Amazon’s network stack.

This allows more network throughput with less overhead.

Try it out today for free!

There is a detailed installation guide available which helps you setting up your cloud correctly for IPFire.

How to update?

For all customers that are already running on the latest image, there is nothing to do here but to make sure that you have all updates installed on your instance.

Click here to go to IPFire on AWS

IPFire 2.25 - Core Update 142 released

by Michael Tremer, March 18, 2020, Updated March 19, 2020

This is the official release announcement for IPFire 2.25 - Core Update 142. This update comes with many features that massively improve the security and hardening of the IPFire operating system. We have also removed some more components of the systems that are no longer needed to shrink the size of the operating system on disk.

We have a huge backlog of changes that are ready for testing in a wider audience. Hopefully we will be able to deliver those to you in a swift series of Core Updates. Please help us testing, or if you prefer, send us a donation so that we can keep working on these things.

Kernel Hardening

This update brings a new kernel which is based on Linux 4.14.173.

For the first time, we have enabled kernel module signing which cryptographically prevents foreign modules from being loaded into the IPFire kernel. An attacker who is trying to load and install a rootkit will have no chance to activate it on the system any more.

This is a huge improvement to the system when attackers have gained control of it through any other security vulnerabilities.

Support for Marvel's Kirkwood ARM architecture has been removed in this release, since it is unmaintained upstream and there are no users in Fireinfo using this any more.

Suricata 5 - Our Intrusion Prevention System

suricata, the Intrusion Prevention System working inside of IPFire has been updated to version 5.0.2.

This release fixes a number of bugs in our IPS, increases performance and brings three new protocol parsers for RDP, SNMP and SIP. The protocol detection engine has been extended to provide better accuracy.

This release also introduces using Rust, which has recently been added to IPFire. Protocol parsers written in Rust can - by design of the language - not have any stack buffer overflows or other memory corruption problems like some C programs do. Therefore, this release makes it easier for the maintainers to extend the IPS at the same time as making it more robust and secure.

Making Testing Easier

This release introduces a new configuration option for Pakfire. Users can now choose between the stable, and two testing branches to easier install unreleased builds.

We hope that this helping you to help us testing IPFire better and therefore be able to give us more valuable feedback on releases.


  • pppd, the Point-to-Point protocol daemon which is used for DSL and LTE connections has a severe vulnerability which allowed Remote Code execution on the client and server side. It has also been updated to version 2.4.8 which fixes some more bugs.
  • Password for proxy users were limited to eight characters due to an old hash algorithm being used. This has now been upgraded and passwords of unlimited length can be used.
  • The squid web proxy has been updated to version 4.10 which closes a number of security vulnerabilities
  • ddns, our suite for dynamic DNS updates, has been updated to version 013. This release ports the software to Python 3 since support for Python 2 is deprecated now.
  • Wireless Access Point devices are now properly added to a network bridge at boot time
  • Some smaller aesthetic fixes for the new DNS Configuration page



  • clamav has been updated 0.102.2 which closes a number of security vulnerabilities
  • dehydrated has been fixed to properly conduct a backup and restore when it is being updated
  • guardian has received fixes for its HTTP log parser
  • haproxy has been updated to 2.1.3 and support for Lua has been enabled
  • libpciaccess has been updated to 0.16. This library is used to pass PCI devices through to a virtual machine.
  • The qemu package has been stripped from any firmware blobs for architectures that cannot be used on IPFire in order to save disk space on the root partition.
  • Further package updates: dnsdist 1.4.0, mc 4.8.24, tmux 3.0a, tor, vdr 2.4.1, vdradmin 3.6.10, w_scan 20170107

Cleaned-up Packages

We have removed a number of packages that have been abandoned by the people who maintain them. We believe that it is better to not offer them instead of exposing your systems to any security risks:

  • arm a CLI monitoring tool for tor
  • batctl, to configure B.A.T.M.A.N., which unfortunately was never finished in IPFire
  • cyrus-imapd - An IMAP/POP daemon
  • multicat & bitstream: Two tools to capture and decode multimedia streams over a network. Has been submitted to IPFire but was sadly never updated by the maintainer.
  • check_mk_agent - A monitoring tool
  • DirectFB - Graphics drivers
  • ez-ipupdate - A tool for dynamic DNS updates, which is unused, because we have ddns
  • icecast, icecastgenerator & streamripper - A media relay for radio streams
  • setserial - A tool to manage serial connections on console
  • rtpproxy - A relay for RTP streams

We currently have very limited development resources and would prefer investing those on things where more people benefit from. Please donate to support us!

Today, we have updated IPFire on AWS to IPFire 2.25 - Core Update 141 - the latest official release of IPFire.

Since IPFire is available on AWS, we are gaining more and more users who are securing their cloud infrastructure behind an easy to configure, yet fast and secure firewall.

This update adds the rewritten DNS stack and brings many bug fixes to the cloud.


Managing DNS servers in IPFire has been re-imagined in this release of IPFire. Before, there were many places where DNS was configured which varied for each system depending on how it connected to the Internet.

For the cloud, we have added some changes that might be relevant for you:

For new installations, we won’t use Amazon’s DNS servers any more since they do not support DNSSEC. By default, the system runs in recursor mode which means that IPFire will contact authoritative DNS servers directly.

For that, Security Groups need to allow IPFire connecting UDP/53 and TCP/53 for any IP address on the Internet.

Systems that are upgraded will automatically carry the previous configuration over. We recommend reviewing those settings and ask you to consider to configure DNS-over-TLS.

Try it out today for free!

There is a detailed installation guide available which helps you setting up your cloud correctly for IPFire.

How to update?

For all customers that are already running on the latest image, there is nothing to do here but to make sure that you have all updates installed on your instance.

Click here to go to IPFire on AWS

Enhancements to our DNS Resolver

by Michael Tremer, February 12, 2020

Today, we have taken some important changes on our DNS Resolver into production. Having released support for DNS-over-TLS in 2018, we have now added TCP Fast Open and TLSv1.3.

Lightning Wire Labs is managing a DNS Resolver to provide an alternative to the large corporation who are trying to get the global DNS system under their control and use it for marketing purposes.

To not fall behind the technical development, we have now enabled some new features on our resolver to make it ready for the new DNS changes that are going to land with IPFire 2.25 - Core Update 141 very soon.


We are supporting DNS-over-TLS, for almost two years now, but with only few users. This is not surprising since IPFire did not DNS-over-TLS in the past, but this will now change.

We support TLSv1.3 and require at least TLSv1.2. ChaCha20-Poly1305, AES-GCM, Curve25519, and smaller ECSDA certificates are of course not missing either.

TCP Fast Open

For users who have an ISP that is filtering UDP queries or breaks DNSSEC in one way or the other, we are supporting TCP of course.

Since TCP requires a full 3-way handshake before any data can be sent, there is a small performance impact. To combat that, we now support TCP Fast Open which allows to send the DNS query with the first packet, even before the TCP connection is fully open.

This way, queries over TCP are just as fast as those over UDP.

How to use it?

The server is available at 2001:678:b28::54 and

If you are using TLS, enter or as TLS hostname.

It is time for the first release of the year, IPFire 2.23 - Core Update 139. It is packed with improvements, software updates, and many many bug fixes.

Improved Booting & Reconnecting

Dialup scripts have been cleaned up to avoid any unnecessary delays after the system has been handed a DHCP lease from the Internet Service Provider. This allows the system to reconnect quicker after loss of the Internet connection and booting up and connecting to the Internet is quicker, too.

Improvements to the Intrusion Prevention System

Various smaller bug fixes have been applied in this Core Update which makes our IPS a little bit better with every release. To take advantage of deeper analysis of DNS packets, the IPS is now informed about which DNS servers are being used by the system.


IPFire is configured as securely as possible. At the same time we focus on performance, too. For connections to the web user interface, we do not allow using CBC any more. This cipher mode is begin to crack and the more robust GCM is available.

Whenever an SSL/TLS connection is being established to the firewall, we used to prefer ChaCha20/Poly1305 as a cipher. Since AESNI is becoming and more and more popular even on smaller hardware, it makes sense to prefer AES. A vast majority of client systems support this as well which will allow to communicate faster with IPFire systems and save battery power.


  • The microcode for Intel processors has been updated again to mitigate vulnerabilities from the last Core Update
  • PC Engines APU LEDs are now controlled using the ACPI subsystem which is made possible using the latest BIOS version
  • Captive Portal: Expired clients are now automatically removed
  • Dynamic DNS: Support for has been fixed in ddns 12
  • Updated packages: Python 2.7.17, bash 5.0, bind 9.11.13, cpio 2.13, libarchive 3.4.0, logwatch 7.5.2, lz4 1.9.2, openvpn 2.4.8, openssh 8.1p1, readline 8.0 (and compat version 6.3), squid 4.9, unbound 1.9.5


  • clamav has been updated to 0.102.1 which include various security fixes
  • libvirt has been updated to version 5.6.0 for various bug fixes or feature enhancements and support for LVM has been enabled.
  • qemu has been updated to 4.1.0
  • Various others: nano 4.6, postfix 3.4.8, spectre-meltdown-checker 0.42

Today, we have updated IPFire on AWS to IPFire 2.23 - Core Update 138 - the latest official release of IPFire.

This update includes security fixes for vulnerabilities in Intel processors as well as the new and improved Quality of Service.


We are very happy that from week to week, we are gaining more customers for IPFire in the cloud - where you now can manage your network just as you do it in your own data centre.

In contrast to Amazon’s own features, IPFire is easier to manage, performs just as well, but brings you even more features like standard IPsec VPNs, OpenVPN for on-the-road connectivity to the cloud, Intrusion Prevention for your cloud servers, detailed logging and reporting and many more features.

Try it out today for free!

There is a detailed installation guide available which helps you setting up your cloud correctly for IPFire.

How to update?

For all customers that are already running on the latest image, there is nothing to do here but to make sure that you have all updates installed on your instance.

Click here to go to IPFire on AWS

Today, we have updated IPFire on AWS to IPFire 2.23 - Core Update 136 - the latest official release of IPFire.

This update includes security fixes for OpenSSL and the Linux kernel, an updated Perl, and of course many other fixes throughout the whole system.


We are very happy that from week to week, we are gaining more customers for IPFire in the cloud - where you now can manage your network just as you do it in your own data center.

In contrast to Amazon’s own features, IPFire is easier to manage, performs just as well, but brings you even more features like standard IPsec VPNs, OpenVPN for on-the-road connectivity to the cloud, Intrusion Prevention for your cloud servers, detailed logging and reporting and many more features.

Try it out today for free!

There is a detailed installation guide available which helps you setting up your cloud correctly for IPFire.

How to update?

For all customers that are already running on the latest image, there is nothing to do here but to make sure that you have all updates installed on your instance.

Click here to go to IPFire on AWS

Job Opportunity for a Junior Developer (m/f/x)

by Michael Tremer, September 23, 2019, Updated September 28, 2019

We, Lightning Wire Labs, are offering an opportunity ideal for a student to become a Junior Developer.

As the leading organisation in the IPFire Project, we are growing our team to allow us to move it forward quicker as well as advancing other internal projects.

Are you a frequent contributor to Open Source projects, but want to develop your skills further?

Join our growing team to help us to achieve our ambitious goals and learn at the same time.

Required skills:

  • Fluent in Python, Shell Scripts, Git, HTML, CSS, JS
  • Good Linux and Networking Skills
  • Good communication skills with other staff and the community. English is mandatory, German is optional.

The focus will be working on the IPFire Project. Development of new features as well as fixing bugs and supporting the community will be essential parts. You will develop our internal applications and software stack as well.

This job offers great flexibility in terms of work hours and will be remote with occasional visits to our main office.

Please send your application including your CV to

This is the official release announcement for IPFire 2.23 - Core Update 134. This update ships security fixes in the Linux kernel for the "SACK Panic" attack as well as some other smaller fixes.

SACK Panic (CVE-2019-11477 & CVE-2019-11478)

The Linux kernel was vulnerable for two DoS attacks against its TCP stack. The first one made it possible for a remote attacker to panic the kernel and a second one could trick the system into transmitting very small packets so that a data transfer would have used the whole bandwidth but filled mainly with packet overhead.

The IPFire kernel is now based on Linux 4.14.129, which fixes this vulnerability and fixes various other bugs.

The microcode for some Intel processors has also been updated and includes fixes for some vulnerabilities of the Spectre/Meltdown class for some Intel Xeon processors.


  • Package updates: bind 9.11.8, unbound 1.9.2, vim 8.1
  • The French translation has been updated by Stéphane Pautrel and translates various strings as well as improving some others
  • We now prefer other cipher modes over CBC when IPFire itself opens a TLS connection. CBC is now considered to be substantially weaker than GCM.
  • Email addresses entered in the web UI can now contain underscores.
  • The Captive Portal now comes up properly after IPFire is being rebooted.

The next version of IPFire is ready: IPFire 2.23 - Core Update 132. This update contains various security fixes and improvements to secure systems that are vulnerable to recently-published problems in Intel processors.

Intel Vulnerabilities: RIDL, Fallout & ZombieLoad

Two new types of vulnerabilities have been found in Intel processors. They cannot be fixed unless the hardware is changed, but can be somewhat mitigated through some changes in the Linux kernel (4.14.120) and an update microcode (version 20190514). Both is shipped in this release.

Additionally, to mitigate this bug which cannot be fixed at all, SMT is disabled by default on all affected processors which has significant performance impacts.

Please note, that Intel unfortunately is not releasing microcode for all processors any more and so you might still be vulnerable.

To apply the fixes, please reboot your system.

There is a new GUI which will show you for which attacks your hardware is vulnerable and if mitigations are in place:

VLAN Configuration

Florian Bührle has contributed a UI to configure VLAN interfaces for zones. This way, it can be done graphically and the system needs to be rebooted to apply the changes.

The GUI also allows to set up a zone in bridge mode which is helpful for advanced users who need some custom configuration.


This update also contains a number of various bug fixes:

  • The new IPS now starts on systems with more than 16 CPU cores
  • For improved security of the web UI, the web service now prefers ciphers in GCM mode over CBC. This is because CBC seems to be weakened by new attack vectors.
  • OpenVPN has received some changes to the UI and improvements of its security.
  • Alexander Koch sent in some changes around the wpad.dat handling: It is now possible to define a list of exceptions to this file on the web UI and all VPN networks are included by default.
  • Captive Portal: A stored cross-site scripting vulnerability has been fixed in the argument handling of the title; an uploaded logo file can now be deleted
  • The same type of stored cross-site scripting attack was resolved in the static routing UI
  • Log entries for Suricata now properly show up in the system log section
  • Updated packages (all from Matthias Fischer): bind 9.11.6-P1, dhcpcd 7.2.2, knot 2.8.1, libedit 20190324-3.1


Wireless AP

The wireless AP add-on has received some new features:

  • For hardware that supports it, Automatic Channel Selection can be enabled, which scans the environment and automatically selects the best channel for the wireless access point. When it is activated, 80 MHz channel bandwidth will be enabled for 802.11ac networks doubling throughput.
  • DFS is supported (on hardware that supports it, too) which is needed to use higher channels in the 5 GHz spectrum
  • Management Frame Protection can optionally be enabled to encrypt messages between the station and the access point. This prevents a rogue attacker to deauthenticate stations from the wireless LAN or other denial-of-service attacks.


  • igmpproxy 0.2.1, tor, zabbix_agentd 4.2.1
  • Qemu is now being hardened with libseccomp which is a "syscall firewall". It limits what actions a virtual machine can perform and is enabled by default

Finally, we are releasing another big release of IPFire. In IPFire 2.23 - Core Update 131, we are rolling out our new Intrusion Prevention System. On top of that, this update also contains a number of other bug fixes and enhancements.

Thank you very much to everyone who has contributed to this release. If you want to contribute, too, and if you want to support our team to have more new features in IPFire, please donate today!

A New Intrusion Prevention System

We are finally shipping our recently announced IPS - making all of your networks more secure by deeply inspecting packets and trying to identify threats.

This new system has many advantages over the old one in terms of performance, security and it simply put - more modern. We would like to thank the team at Suricata on which it is based for their hard work and for creating such an important tool that is now working inside of IPFire.

We have put together some documentation on how to set up the IPS, what rulesets are supported and what hardware resources you will need.

Migration from the older Intrusion Detection System

Your settings will automatically be converted if you are using the existing IDS and replicated with the new IPS. However, you will need to select the ruleset and rules that you want to use again, since those cannot be migrated. Please note that the automatic migration will enable the new IPS, but in monitoring mode only. This is that we won't break any existing configurations. Please disable the monitoring mode if you want the IPS to filter packets, too.

If you restore an old backup, the IDS settings won't be converted.

The guardian add-on is no longer required any more for the IDS to work but still provides means against SSH brute-force attacks and brute-force attacks against the IPFire Web UI.

OS Updates

This release rebases the IPFire kernel on 4.14.113 which brings various bug and security fixes. We have disabled some debugging functionality that we no longer need which will give all IPFire systems a small performance boost.

Updated packages: gnutls, lua 5.3.5, nettle 3.4.1, ntp 4.2.8p13, rrdtool 1.7.1, unbound 1.9.1. The wireless regulatory database has also been updated.


  • SSH Agent Forwarding: This can now be enabled on the IPFire SSH service which allows administrators to connect to the firewall and use SSH Agent authentication when using the IPFire as a bastion host and connecting onwards to an internal server.
  • When multiple hosts are created to overwrite the local DNS zone, a PTR record was automatically created too. Sometimes hosts might have multiple names which makes it desirable to not create a PTR record for an alias which can now be done with an additional checkbox.
  • A bug in the firewall UI has been fixed which caused that the rule configuration page could not be rendered when the GeoIP database has not been downloaded, yet. This was an issue when a system was configured, but never connected to the internet before.
  • On systems with a vast number of DHCP leases, the script that imports them into the DNS system has been optimised to make sure that they are imported faster and that at no time a half-written file is available on disk which lead unbound to crash under certain circumstances.
  • Some minor UI issues on the IPsec VPN pages have been fixed: On editing existing connections, the MTU field is now filled with the default;
  • We are no longer trying to search for any temperature sensors on AWS. This caused a large number of error messages in the system log.


  • Package updates: borgbackup 1.1.9, dnsdist 1.3.3, freeradius 4.0.18, nginx 1.15.9, postfix 3.4.5, zabbix_agentd 4.2.0
  • tor has received an extra firewall chain for custom rules to control outgoing traffic (TOR_OUTPUT). This allows to create rules for traffic that originates from the local tor relay. The service is also running as an own user now.
  • Wireless Access Point: It is now possible to enable client isolation so that wireless clients won't be able to communicate with each other through the access point.

New Packages

  • flashrom - A tool to update firmware

Just a couple of days after the release of IPFire 2.21 - Core Update 130, the next release is available. This is an emergency update with various bug fixes and a large number of security fixes.


IPFire 2.21 - Core Update 130 contains security updates for the following packages:

  • Apache 2.4.39: The Apache Web Server, which runs the IPFire Web User Interface, was vulnerable for various privilege escalations (CVE-2019-0211), access control bypasses (CVE-2019-0215, CVE-2019-0217), DoS attacks (CVE-2019-0197), buffer overflow (CVE-2019-0196) and a URL normalisation inconsistency (CVE-2019-0220). They are all regarded to be of "low" severity.
  • wget 1.20.3: wget has had multiple vulnerabilities that allowed an attacker to execute arbitrary code (CVE-2019-5953).
  • clamav 0.101.2: ClamAV, the virus scanner, has had multiple vulnerabilities that allowed DoS and a buffer overflow in a bundled third-party library.

Although some of these vulnerabilities are only of low severity, we recommend to install this update as soon as possible!

IPsec Regression

The last update introduced a regression in the IPsec stack that caused that the firewall could no longer access any hosts on the remote side when the tunnel was run in tunnel mode without any VTI/GRE interfaces. This update fixes that.

IPFire 2.21 - Core Update 129 released

by Michael Tremer, April 8, 2019, Updated April 8, 2019

This is the official release announcement for IPFire 2.21 - Core Update 129 - an update that introduces routed IPsec VPNs and comes with various other changes that update the core system and fix several bugs.

IPsec Reloaded

IPsec has been massively extended. Although IPsec in IPFire is already quite versatile and delivered high performance, some features for experts were required and are now available through the web UI:

  • Routed VPNs with GRE & VTI
  • Transport Mode for net-to-net tunnels
  • IPsec connections can now originate from any public IP address of the IPFire installation. This can be selected on a per-connection basis.

The code has also been cleaned up the UI has been made a little bit tidier to accommodate for the new settings.

Smaller changes include:

  • The "On-Demand" mode is finally the default setting. Tunnels will shut down when they are not used and they will be established again when they are required.


  • DHCP: A crash has been fixed when filenames containing a slash have been entered for PXE boot.
  • DHCP: Editing static leases has been fixed
  • Domains in the "DNS Forwarding" section can now be disabled for DNSSEC validation. This is a dangerous change, but has been requested by many users.
  • Updated packages: bind 9.11.6, groff 1.22.4, ipset 7.1, iptables 1.8.2, less 530, libgcrypt 1.8.4, openssl 1.1.1b, openvpn 2.4.7, squid 4.6, tar 1.32, unbound 1.9.0, wpa_supplicant 2.7
  • New commands: kdig 2.8.0
  • The build system has been optimised to reduce build time of the whole distribution to around 4-5 hours on a fast machine.


  • Alexander Koch has contributed zabbix_agentd which is the agent that is installed on the monitored machine. With this, IPFire can now be integrated into an environment that is monitored by Zabbix.
  • On that note, the SNMP daemon has also been updated to version 5.8 for people who use the SNMP protocol for monitoring.
  • tor has been updated to and some minor bugs have been fixed in the web user interface
  • The spectre-meltdown-checker script is available as an add-on which allows IPFire users to test their hardware for vulnerabilities
  • Other updates: amavisd 2.11.1, hostapd 2.7, postfix 3.4.3

Thank you very much to everyone who contributed to this Core Update. Please support our project and donate today so that we can keep up our work!

This is the official release announcement for IPFire 2.21 - Core Update 128; another maintenance update with a brand new kernel, introducing TLS 1.3 throughout the whole system and of course a whole package of bug fixes and other improvements.

Thanks to everyone who has contributed to this Core Update with either sending in patches, testing, reporting bugs and many many other things. I am quite happy to see the team grow! Thank you very much as well to all of you who have supported our Donations Challenge so far. We have received a lot of nice words and support from you, but we are not there, yet! Please support our project and donate!

Kernel Update

The Linux kernel, the core of the IPFire operating system, has been updated to the latest release of the 4.14 branch. We have added some extra patches to improve hardware support and fix some security vulnerabilities. LEDs of PCengines' APU boards are now supported on newer versions of the mainboard and on those boards, the serial console is always enabled. On x86-based systems, we now support up to 64 processors.

OpenSSL 1.1.1 & TLS 1.3

We have also updated the main TLS/SSL library to OpenSSL in version 1.1.1. This adds support for TLS 1.3 and of course brings various other improvements with it. On browsers that support it, the IPFire web user interface is now available over TLS 1.3 and any outgoing SSL connection from the firewall supports it, too. We ensure that those connections only use secure and performant ciphers to make connections as fast as they can be.

We have also updated the list of trusted Certificate Authorities (CAs).

We have removed any previous versions of OpenSSL from the system which will soon be end-of-life. If you have anything custom that you have compiled yourself on your system, please be aware of that and note that you might potentially rebuild your custom software.

Add-ons provided by the IPFire Project now support TLS 1.3 as well. If you are running a custom configuration for postfix or haproxy make sure that TLS 1.3 is not excluded from the supported TLS protocols.

Performance Tuning

The system is now configured to be able to route more packets. During some benchmarks and testing we have discovered that IPFire does not always use the full performance of the hardware underneath it. While most system probably won't benefit much from these improvements, some systems with very fast processor cores will see a 5-10% increase in bandwidth from and to the firewall as well as routed through it. That comes at the cost of very slight increase of power consumption, but we figured that that is a price worth paying not only provide you a secure firewall, but also a fast one.


  • A change of the firewall policy might potentially be backwards-incompatible, but we saw no other way to improve the security of the system: Previously, systems on the ORANGE network were always allowed to connect to the Internet on RED. This was carried over from the very beginning of IPFire when the firewall user interface was way more basic and rules to change this behaviour could not be configured at all. Now, it makes a lot more sense to not have this default which was also not well-known and allow users to create rules to either allow or deny traffic like this.
  • The kdig utility is now available on command line which supports DNS lookups via TLS
  • Updated packages: apache 2.4.38, apr 1.6.5, curl 7.64.0, dhcpcd 7.1.1, ghostscript 9.26, logrotate 3.15, openssl 7.9p1, postfix 3.3.2, strongswan 5.7.2, tzdata 2018i


  • powertop has been updated to version 2.10
  • tor has been updated to version
  • sendEmail has been fixed by Rob. The script had a wrong file ownership.

The first update of the year and it is packed with loads of new features, many many performance improvements as well as some security fixes. This is quite a long change log, but please read through it. It is worth it!

To support our project and keep us bringing these updates for you, please donate!

Squid 4.5 - Making the web proxy faster and more secure

We have finally updated to squid 4.5, the latest version of the web proxy working inside IPFire. It has various improvements in speed due to major parts being rewritten in C++.

We have as well changed some things on the user interface to make its configuration easier and to avoid any configuration mistakes.

One of the major changes is that we have removed a control that allowed to configure the number of child processes for each redirector (e.g. URL filter, Update Accelerator, etc.). This is now statically configured to the number of processors. Due to that, we only use as many processes as the system has memory for but allow to use maximum CPU power by being able to saturate all cores at the same time. That makes the URL filter and other redirectors faster and more efficient in their resource consumption. They will now also be launched at the start of the web proxy so that there is no wait any more for the first request being handled or when the proxy is under higher load.

We expect these improvements to make proxies that serve hundreds or even thousands of users at the same time to become faster by being more efficient.

We have dropped some features that no longer make sense in 2019: Those are the web browser check and download throttling by file extension. Since the web is migrating more and more towards HTTPS, those neither work for all the traffic, nor are they very reliable or commonly used.

We have also removed authentication against Microsoft Windows NT 4.0 domains. Those authentication protocols used back then are unsafe for years and nobody should be using those any more. Please consider this when updating to this release.

We have also mitigated a security issue in the proxy authentication against Microsoft Windows Active Directory domains. Due to squid's default configuration, an authenticated user was remembered by their IP address for up to one second. That means that with an authenticated browser, any other software coming from the same system was allowed for one second to send requests to the web proxy being properly authenticated. This could have been exploited by malware or other software running inside a virtual machine or similar services to get access to the internet without having valid credentials. This is now resolved and (re-)authorisation is always required.

New installations will now be recommended to set up a proxy with slightly more cache in memory and no cache on disk. Ultimately, this is something that should be considered for each installation individually, but is a better default than the previous values.

Furthermore, some minor usability improvements of the web proxy configuration page have been implemented.

DNS Forwarding

The DNS forwarding feature has been extended to make using it more flexible. It now accepts hostnames as well as IP addresses to forward requests to multiple servers that are found by resolving the hostname. It is also possible to add multiple servers as a comma-separated list so that multiple servers can be queries for one single domain. Before only one IP address was supported which rendered the domain unresolvable in case of that specific server becoming unreachable.

These changes allow to redirect requests to DNS blacklists for example directly to the right name servers and not worry about any changes of IP addresses at the provider. There is also load-balancing between multiple servers and the fastest server is being preferred so that DNS resolution for all domains is faster and more resilient, too.


  • Kernel modules that initialised framebuffer are no longer being loaded again. This cause some crashes on various hardware with processors from VIA and was a regression introduced by compression kernel modules with the last Core Update.
  • Creating certificates for IPsec and OpenVPN threw an error before which has now been fixed by ensuring that the internal certificate database is initialised correctly
  • We have enabled a Just-In-Time compiler for the Perl Regular Expressions engine. This will increase speed of various modules that use it like the Intrusion Detection system which might have significantly more throughput as well as speed of the URL filter and various other components on the system.
  • fireinfo now supports authentication against any upstream web proxies
  • Installing IPFire from ISO on i586-based systems failed because of a bug in the EFI code of the installer. This has now been fixed.
  • Installing IPFire on XFS filesystems is now also working again. Before, the installed system was not able to boot because GRUB did not support some modern file system features.
  • The description on which SSH port IPFire is listening has been fixed.
  • Connection Tracking support is now enabled by default for Linux Virtual Servers, i.e. layer-4 load-balancers.
  • GeoIP: Scripts have been updated to use a new format of the GeoIP database
  • Updated packages: bind 9.11.5-P1, ipvsadm 1.29, Python 2.7.15, snort 2.9.12, sqlite 3.26.0 which fixes a couple of security vulnerabilities, squid 4.5, tar 1.31 which fixes a couple of security vulnerabilities, unbound 1.8.3, wget 1.20.1


  • Updated packages: clamav 0.101.1, libvirt 4.10 which fixes some problems with stopping and resuming virtual machines, mc 4.8.22, transmission 2.94
  • The haproxy package now correctly handles its backup

IPFire 2.21 - Core Update 126 released

by Michael Tremer, December 28, 2018, Updated December 28, 2018

Finally, the next release of IPFire is available: IPFire 2.21 - Core Update 126 This update comes with a new kernel and security enhancements. This change log is rather short, but the changes are very important.

Thank you very much to all of you who have supported our Donations Challenge so far. We have received a lot of nice words and support from you, but we are not there, yet! Please support our project and donate!

Linux 4.14.86

The kernel has been updated to the latest version of the Linux 4.14.x branch which brings various improvements around stability, enhances performance and fixes some security vulnerabilities. This kernel also has major updates for the Spectre and Meltdown vulnerabilities that remove previously existent performance penalties in some use-cases.

The kernel's modules are now compressed with the XZ algorithm which will save some space on disk as the kernel is one of the largest components of IPFire.


  • openssl has been updated to 1.1.0j and 1.0.2q which fixes some minor security issues and has various bug fixes
  • The bind package has now changed to ship shared libraries which it did not before. Those allow that commands like dig and host use those shared libraries and are no longer statically linked. This makes the files a lot smaller.
  • Stéphane Pautrel has substantially improved the French translation of IPFire. Thank you very much for that!


  • Updated packages: bird 2.0.2, nano 3.2
  • New packages: shairport-sync

Thanks for the people who contributed to this Core Update. Please support us and donate!

The end of another year

by Michael Tremer, December 24, 2018, Updated December 25, 2018

It is the end of another year and I would like to take this opportunity to simply say thank you. It has been an eventful year and we have come a long way.

The Stats

We have brought you eight Core Updates with probably the largest changes that we have had in a while. A new kernel 4.14 that is running better than ever before; we have had a spring clean and remove loads of old add-ons and other packages to make space for new ones as well as getting rid of some older cryptography; we fought Meltdown and Spectre; we have launched IPFire on AWS and added support for EFI and 802.11ac WiFi; we have added loads of new features that make IPFire simply better.

We are all proud of our achievements and I would like to thank everyone who has contributed. Whether that is by submitting patches, reporting bugs, writing documentation and all the other things. You guys know who I am talking about.

Take a couple of days off and enjoy the holidays. Merry Christmas if you are celebrating. Hope to see you all again next year!


Of course we already have loads of plans for the next year. We have a bug tracker full of feature requests, error reports and ideas how to improve things. We also hope that we can finally move IPFire 3 over the line so that the project gains more traction - and a new Core Update is ready to be released, too!

We hope that our community keeps growing, more and more people keep installing IPFire and finally throw away their old gear. We have achieved a lot, but there is definitely loads to do, still.

Please Donate Today

Help us to achieve our goals! We are still running our donation challenge which unfortunately has not hit its goal, yet. Please consider to support our project and donate today. If you have already done so and set up a monthly donation, we thank you very very much for that.

Finally, the next release of IPFire is available: IPFire 2.21 - Core Update 125 This update comes with various security and bug fixes as well as cleanups and some new features.

Thank you very much to all of you who have supported our Donations Challenge so far. We have received a lot of nice words and support from you, but we are not there, yet! Please support our project and donate!

802.11ac WiFi

The IPFire Access Point add-on now supports 802.11ac WiFi if the chipset supports it. This allows better coverage and higher network throughputs. Although IPFire might not be the first choice as a wireless access point in larger environments, it is perfect to run a single office or apartment.

Additionally, a new switch allows to disable the so called neighbourhood scan where the access point will search for other wireless networks in the area. If those are found, 40 MHz channel bandwidth is disabled leading to slower throughput.


  • strongswan 5.7.1: This updated fixes various security vulnerabilities filed under CVE-2018-16151, CVE-2018-16152 and CVE-2018-17540. Several flaws in the implementation that parsed and verified RSA signatures in the gmp plugin may allow for Bleichenbacher-style low-exponent signature forgery in certificates and during IKE authentication.
  • The IO graphs now support NVMe disks
  • The SFTP subsystem is enabled again in the OpenSSH Server
  • Swap behaviour has been changed so that the kernel will make space for a large process when not enough physical memory is available. Before, sudden jumps in memory consumption where not possible and the process requesting that memory was terminated.
  • The backup scripts have been rewritten in Shell and now package all add-ons backups with the main backup. Now, it is no longer required to save any add-on configuration separately.
  • Updated packages: apache 2.4.35, bind 9.11.4-P2, coreutils 8.30, dhcpcd 7.0.8, e2fsprogs 1.44.4, eudev 3.2.6, glibc 2.28, gnutls 3.5.19, json-c 0.13.1, keyutils 1.5.11, kmod 25, LVM2 2.02.181, ntfs-3g 2017.3.23, reiserfsprogs 3.6.27, sqlite, squid 3.5.28, tzdata 2018g, xfsprogs 4.18.0

New Add-Ons

  • dehydrated - A lightweight client to retrieve certificates from Let's Encrypt written in bash
  • frr, an IP routing protocol suite and BGP and OSPF are supported on IPFire. Find out more on their website.
  • observium-agent - An xinet.d-based agent for Observium, a network monitoring platform

Updated Add-Ons

  • clamav has been updated to 0.100.2 and the virus database files have been moved to the /var partition. This makes more space available on the root partition.
  • nfs 2.3.3, haproxy 1.8.14, hostapd 2.6, libvirt 4.6.0, tor

Thanks for the people who contributed to this Core Update.

Please help us to support everyone’s work with your donation!

Donations Challenge

by Michael Tremer, November 18, 2018, Updated March 13, 2019

The IPFire Project is entirely independent and funded by donations which is quite a tough thing to do these days. It is hard to get donations when you don't have a budget for advertising and encourage people to do more. Unfortunately, donations are at a record low.

That is why we are starting a new challenge: 150 new long-standing donations by the end of the year. That will set up the project for a great year 2019 - and the future is all we are about!

Update from Wednesday, Mar 13 2019: So far, we have 19 monthly recurring donations :( We had hoped for more to be able to do more. Please donate today!

Update from Wednesday, Dec 12 2018: So far we have 17 monthly donations! Thank you for everyone who donated. We got an amazing number of smaller one-time donations which is amazing, too, but please consider setting up a monthly donation if you can!

Every donation matters

We appreciate everyone who contributed to the project in the past and we made very good use of every single penny ever donated to the project. That does not only go for financial contributions, but also all other contributions in form of code and time. But a long-term donation is better because it is not only a single event. It is an investment into the project and a commitment to support it and continuous improvement!

It does not matter if you give little or a lot, but it would be appreciated if everyone gives something. Help us to reach out to others and ask them to donate, too. The more people, the better and the more this becomes a community effort!

Instead of asking for a certain sum, we are just asking for a number of new people supporting us regularly. To help us out more, of course donating more helps more, so please try to give as much as you can.

We have a long way ahead of us and need your help

Through our new website and collaboration with Lightning Wire Labs, we are accepting monthly donations and we recommend to everyone to set up one instead of a one-time donation.

We have also improved on payment methods: We support credit card, SEPA Direct Debit and SEPA Bank Transfer to make it fast and easy for use as well as protect your privacy. Also, they do not collect any high fees which ensures that a maximum of the money is going to the project instead of the payment provider. We no longer support PayPal.

Become a donor today

Head over to our new donation page and help us creating change now! Select "Monthly", choose how much you would like to give and complete the form. Thank you!

Dear IPFire Community,

this is the official release announcement for IPFire 2.21 – Core Update 124. It brings new features and immensely improves security and performance of the whole system.

Thanks for the people who contributed to this Core Update. Please help us to support everyone’s work with your donation!

IPFire on Amazon Cloud

IPFire is now available on AWS EC2. This is sponsored by Lightning Wire Labs and provides a virtual cloud appliance that is set up within minutes and provides the full set of features of IPFire.

IPFire is ideal to securely connect your infrastructure to the cloud by using IPsec VPNs and provides throughput of multiple tens of gigabits per second! But IPFire can also be used as a small instance that protects your web, mail and other servers in the cloud with the IPFire Intrusion Detection and Prevention Systen, load balance web traffic and many things more.

Try it now!

Kernel Hardening

We have updated the Linux kernel to version 4.14.72 which comes with a large number of bug fixes, especially for network adapters. It has also been hardened against various attack vectors by enabling and testing built-in kernel security features that prohibit access to privileged memory by unprivileged users and similar mechanisms.

Due to this, the update requires a reboot after it has been installed.

OpenSSH Hardening

Peter has contributed a number of patches that improve security of the SSH daemon running inside IPFire. For those, who have SSH access enabled, it will now require latest ciphers and key exchange algorithms that make the key handshake and connection not only more secure, but also faster when transferring data.

For those admins who use the console: The SSH client has also been enabled to show a graphic representation of the SSH key presented by the server so that comparing those is easier and man-in-the-middle attacks can be spotted quickly and easily.

Unbound Hardening

The settings of the IPFire DNS proxy unbound have been hardened to avoid and DNS cache poisoning and use aggressive NSEC by default. The latter will reduce the load on DNS servers on the internet through more aggressive caching and will make DNS resolution of DNSSEC-enabled domains faster.


IPFire now supports booting in EFI mode on BIOSes that support it. Some newer hardware only supports EFI mode and booting IPFire on it was impossible before this update. EFI is only supported on x86_64.

Existing installations won’t be upgraded to use EFI. However, the flash image and systems installed with one of the installation images of this update are compatible to be booted in both, BIOS and EFI mode.

Although this change does not improve performance and potentially increases the attack vector on the whole firewall system because of software running underneath the IPFire operating system, we are bringing this change to you to support more hardware. It might be considered to disable EFI in the BIOS if your hardware allows for it.


  • CVE-2018-16232: Remote shell command injection in backup.cgi: It has been brought to our attention that it was possible for an authenticated attacker to inject shell commands through the backup.cgi script of the web user interface. Those commands would have been executed as a non-priviledged user. Thanks to Reginald Dodd to spot this vulnerability and informing us through responsible disclosure.
  • The hostname of the system was set incorrectly in the kernel before and is now being set correctly
  • Firewall: Creating rules with the same network as source and destination is now possible and renaming a network/host group is now correctly updating all firewall rules
  • Cryptography: ChaCha20-Poly1305 is now working on ARM, too
  • IPsec: The status of connections in waiting state is now shown correctly at all times; before, they always showed up as enabled although they were disabled.
  • pakfire: Some old and unused code has been cleaned out and the mirror health check has been removed, because a download will fail-over to another available mirror anyways
  • Intrusion Detection: Emerging Threats rules are now being downloaded over HTTPS rather than HTTP
  • Updated packages: bind 9.11.4-P1, iproute2 4.18.0, ntp 4.2.8p12, openssh 7.8p1, parted 3.2, pciutils 3.5.6, rng-tools 6.4, syslinux 6.04-pre1, unbound 1.8.0


  • Updated packages: nano 3.1, postfix 3.3.1

Launching IPFire on AWS

by Michael Tremer, October 6, 2018, Updated November 1, 2018

Today, we are launching IPFire on the Amazon Cloud, our first IPFire Appliance in the Cloud.

For everyone, who is already using IPFire in their own data centers, their offices or branches, figuring out AWS is now over. You can now run IPFire as you know it in the Cloud. Using all features as you are used to them and configure them easily through the IPFire web user interface.

Hosting infrastructure in the cloud is becoming more and more important for almost all businesses. It gives you flexibility to grow without a large financial commitment in the beginning and loads of technical features that are expensive to implement in your own data center.


Amazon is the market leader in the cloud business for years, offering a system that has by far the most advanced features. Anything is possible - given a generous budget. But with that large feature set, it is hard to configure this complex system and very often a simpler solution would have done the job.

IPFire is a lot easier to configure and offers powerful features for the cloud without requiring to be an expert on AWS:

In the Cloud, IPFire grows with you

IPFire runs on smallest hardware as well as on large rack-mounted appliances. It works the same in the cloud!

Starting with a small instance that costs only a few dollars a month to run, you can grow to a large instance that handles gigabits of traffic if you need to. On AWS, 10G and 25G interfaces are supported.

Use IPFire’s powerful set of features

IPFire comes with IPsec and OpenVPN on board making it perfect to securely connect your office, employees or IoT equipment to the cloud giving it access to all internal services you are hosting.

Firewall rules are quickly and easily configured and with the IPFire Intrusion Prevention System, you will find and block any malicious attackers.

See some more examples on the detailed product page.

IPFire is versatile

While setting up IPFire in the cloud, you can grow your business and infrastructre. When ever you decide to leave AWS, you can just backup your configuration and take it with you to the new place.

Whether that would be an on-premise appliance or another AWS region is entirely up to you. Migration is easy and done within minutes.

Try it out today

We have compiled comprehensive documenation on how to set up IPFire on AWS that doesn’t require you to be an expert at all. We also give you a free trial.

What are you waiting for? Try out IPFire on AWS today!

This is the release announcement for IPFire 2.21 – Core Update 123 – a house-keeping release with a large number of fixes and some fixes for security vulnerabilities.

Thanks for the people who contributed to this Core Update by submitting their patches and please help us to support everyone’s work with your donation!

This release ships a large number of microcode updates for various processors (linux-firmware 30.7.2018, intel-microcode 20180807). Most notable, vulnerabilities in Intel processors might have been fixed or mitigations applied. Microcodes are now also being loaded into the processor earlier to avoid any attacks on the system at boot time.

This update also comes with a large number of smaller changes that improve security and fix bugs:

  • OpenSSL has been updated to versions 1.1.0i and for legacy applications version 1.0.2p (CVE-2018-0732 and CVE-2018-0737)
  • IPsec
    • IPsec now supports ChaCha20/Poly1305 for encryption
    • It also allows to configure a connection to passively wait until a peer initiates it. This is helpful in some environments where one peer is behind NAT.
  • OpenVPN
    • Creating Diffie-Hellman keys with length of 1024 bits is no longer possible because they are considered insecure and not being supported by OpenVPN any more
    • There is better warnings about this and other cryptographic issues on the web user interface
  • Intrusion Detection
    • Links in the log files have been fixed to open the correct page with details about a certain attack
    • Downloads of rulesets properly validate any TLS certificates
  • The /proc filesystem has been hardened so that no kernel pointers are being exposed any more
  • nss-myhostname is now being used to dynamically determine the hostname of the IPFire system. Before /etc/hosts was changed which is no longer required.
  • collectd: The cpufreq plugin has been fixed
  • Generating a backup ISO file has been fixed
  • Updated packages: apache 2.4.34, conntrack-tools 1.4.5, coreutils 8.29, fireinfo, gnupg 1.4.23, iana-etc 2.30, iptables 1.6.2, libgcrypt 1.8.3, libnetfilter_conntrack 1.0.7, libstatgrab 0.91, multipath-tools 0.7.7, openvpn 2.4.6, postfix 3.2.6, rng-tools 6.3.1, smartmontools 6.6, squid 3.5.28, strongswan 5.6.3, tzdata 2018e, unbound 1.7.3


  • Support for owncloud has been removed from guardian (version 2.0.2)
  • Updates: clamav 0.100.1, fping 4.0, hplip 3.18.6, ipset 6.38, lynis 2.6.4, mtr 0.92, nginx 1.15.1, tmux 2.7, tor
  • avahi has been brought back in version 0.7 as it is required as a dependency by cups which has been fixed to automatically find any printers on the local network automatically
  • asterisk is now compiled with any optimisation for the build system which was accidentally enabled by the asterisk build system

Announcing IPFire Nano Box - Our First ARM-based Appliance

by Michael Tremer, May 30, 2018, Updated November 1, 2018

We are proud to announce our first ARM-based appliance: The IPFire Nano Box

This small and versatile system will be our latest addition to our professional IPFire Appliance line and will make IPFire ready to deployed on the Internet of Things as well as in smallest locations like a remote working office or in industrial plants.

Together with our hardware parter TX-Team, and with input from many customers, we have designed this new appliance. For the first time, we layouted and are manufacturing the whole baseboard from scratch for an optimal firewall product and also to be able to act as cost-efficient as possible.

The proud result is up to our highest standards in performance, easy handling, versatile deployment where ever our customers need it, maximum extensibility for many different tasks and of course security.

In the weeks to come, I would like to tell you the stories behind our new product and how it came to be. It has been a long journey and we have invested so much effort and thought into creating this for you and - to us - many of those are worth sharing.

Although this is the smallest of all products, in some ways, it is the greatest.

The IPFire Nano Box

The IPFire Nano Box provides connectivity wherever needed and wherever possible. It has two Fast Ethernet ports and an optional WiFi and LTE/3G module.

A quad-core ARM Cortex-A7 processor has enough power to run multiple secure IPsec or OpenVPN connections to your company’s headquarter or data center where connected IoT applications can send their data to. It can also be used in places where our IPFire Duo Box is too large and where only limited performance is needed. For example to provide connectivity via DSL or 4G and WiFi for a remote worker at home.

Wherever the IPFire Nano Box is deployed, it provides the full range of functionality that the IPFire Distribution has which is much more than what most 4G or DSL routers provide. And of course using one software everywhere makes many things a lot easier, too!

In the basic configuration, the power consumption is only 2 watts which will allow the IPFire Nano Box to be battery-powered over a long time as well.

It is wrapped in an industrial aluminium case in a small form-factor, passively cooled of course and IP50 proof. Surrounding temperatures between zero and 60°C are not a problem and its wide-band voltage input of 12-24V allow deploying the system even under difficult circumstances.

As soon as we have released the product, we will also release our designs, plans and mockups as Open Hardware for everyone to audit and review. With this, we will provide you with a 100% transparent system on which you can build other applications if you want to.

Register Your Interest

We have just completed the prototyping stage of this new hardware and mass-production is starting soon. Since we have already received huge interest about our product in the conversations with our customers over the phone, we are excited to keep you updated about the status.

If you would like to know more about the IPFire Nano Box, or register your interest, please get in touch with our sales team at

Meltdown/Spectre - The chaotic story

by Michael Tremer, January 12, 2018, Updated November 6, 2018

I am sure that it has been unmissable: Every modern processor has unfixable security flaws. The story has now been boiling for weeks and has finally made the main news one week ago.

To make this article shorter, I won’t go into details of the technical issue. That has been discussed in many places so far and everyone of you can search around a bit to find an explanation to your desired detail. The most important piece of information that you should know is that the CPUs are allowing applications to access parts of the memory that they should not and that allows an attacker to get important information from the victim’s computer.

Although it took decades to find out about this fundamental design issue, it is very easy to exploit and even a little piece of Javascript executed in a web browser has been reported to be sufficient to execute the attack.

The most important question for us is: Is IPFire affected? And the unfortunate answer is yes, most likely. This is a hardware bug and if IPFire is running on hardware that is vulnerable, it is affected. The even worse news is that there is probably not many systems that are not affected. The IPFire kernel has been patched and hardened against multiple attack vectors and there is a possibility that we are able to mitigate at least some exploitation of this attack through grsecurity. However, this is not 100% confirmed, yet.

Another argument that probably weighs a bit more is that IPFire is never supposed to run untrusted code. The example with the javascript code in a browser might work on a desktop system, but the firewall does not do this. All code is reviewed and compiled by us, signed and verified before it is installed on every single IPFire system. As long as you haven’t installed any third-party software from any other source you should be safe. But any unknown and therefore unpatched remote code execution vulnerability in any of the many packages that IPFire is using would allow an attacker to execute an Meltdown/Spectre exploit. That means we cannot just lean back.

Talking about what we can do from a distribution point of view brings me to point that I have to raise first: I have never read so many speculations, false assumptions and comments that were just wrong about any vulnerability before. For me, new about this vulnerability are just breaking and so are the patches that are out there to mitigate the problem. Many things are just in the unknown until today. The biggest problem there seems to be the embargo that hasn’t been followed properly and one specific vendor who is following their own rules.

It is still officially unconfirmed if 32 bit architectures are affected as well. Logic tells us they are, but the Linux kernel maintainers who pride themselves in having delivered a good set of patches have only working on the 64 bit x86 version of it and not 32 bit. So all 32 bit systems remain unpatched.

The latest versions of the kernel (4.14 and 4.15-rc*) have received a patchset called KAISER which is supposed to mitigate the hardware bug. However, only an old version and parts of that patchset have been backported to older kernels. IPFire is always based on an older kernel that is on long-term support and well maintained just like many other distributions. Some have patched parts of the vulnerability but I think I can be certain that nobody fixes all of it. By that I certainly do not want to say that the kernel maintainers are doing a bad job. They are doing a great job, but of course their time is also limited and this is not a simple fix that requires a few lines like Heartbleed did. It requires major rework of some essential parts of the kernel and I am very grateful for them doing that work. My point is just that they are not done, yet and deploying half a fix is probably not a good idea. People have reported bugs in the other kernels that will probably never be fixed.

So what will IPFire do? Having said that we think that we might already mitigate some portion of that problem and that the distribution is not too easy to exploit, we are continuing to work on rebasing the distribution on 4.14 which is the latest long-term supported kernel. That will take some more time though since supporting ARM is a huge maintenance problem for us right now. It is holding up a release that is basically ready for beta. If a good patchset that is also compatible with grsecurity becomes available we will ship that with the current kernel, but I am not expecting that to happen in the near future.

That leaves me with saying that everyone who can should probably upgrade from 32 bit to 64 bit.

I cannot finish this article with having a rant about Intel and how they dealt with this issue. There are also some other groups who deserve some criticism and but clearly Intel did not handle this well and is still trying to play down the huge size of this problem. First of all it is the most severe hardware issue that has been around in probably all time. It is not only in a product that some people use, but probably every person who reads this article owns at least one Intel processor that has been produced in the last decade. Their power in the market is that huge that they have a monopoly.

Bugs happen. I do not want to point a finger at a certain person or group who did something wrong. Clearly they should have known better, but this has happened now, so we have to deal with it. But you should own your bugs. Take responsibility. Instead their PR department seems to have chosen a route to blame other vendors as well for a bug that only they had. Yes, ARM and yes, AMD is also affected by some problems that are also very severe, but there is one that only affects Intel processors. That is also the most severe one. They continue to put out benchmarks that only show a little performance impact but deliberately neglect older processors where the performance impact is a lot higher.

That is not a very good way to gain my trust. And not that I had the biggest trust in that company before, this did not help. So I am stuck in a world where I do not have many alternatives to what I can buy from the shelfs. Your products are inside every modern computer. Make yourself aware of that responsibility. That includes your CEO who apparently did not want to own that financial risk.

And the only reason why I care about this so much is, that secure software requires secure hardware. It does not matter how secure IPFire is, because when the hardware is compromised, the software is compromised, too.

Finally, we have made the move to host all of our services over TLS only. That means that any website or file that is being downloaded, any email that is being sent or received is being encrypted. Everything is secure now! Well… not really. This is a brief article about TLS considerations and some real-world issues with it.

Up until about two weeks ago, none of the IPFire web services had a certificate – with a few exceptions. If you went onto our main website, you would have just connected over HTTP and that is it. There was no TLS involved whatsoever. It didn’t need it really. At no time any personal data was being transferred. It was just our website which is publicly available for everyone.

For some web services like Bugzilla and some more we used our own CA. That allowed us to issue our own certificates with what ever settings we wanted and we could deploy them very easily. One main incentive was to avoid paying for a number of certificates at a public CA which wasn’t possible for such a number of certificates and being as underfunded as we are it was a wrong place to invest the money. I toyed around with DANE for a little bit, but since no web browser implements this, this is nothing better than a trial.

Let’s Encrypt everything!

But those days are gone now. Over the last weeks I abandoned the IPFire CA and replaced any existing certificates by certificates from Let’s Encrypt. It has been suggested many times by many users but I refused to do it because I do not really see the point of just encrypting everything for the sake of encryption. Encryption is from my point of view very useless in the case of our main website and mirror servers.

What convinced me now to do it is a completely different argument: Integrity. I do not want somebody else injecting some malicious Javascript code into our website. That is the only reason Let’s Encrypt makes sense. Encryption would technically work without a publicly signed certificate and of course in the case of the IPFire forums it is a necessity.

In addition to the sites that already had a certificate, I set up Let’s Encrypt for literally everything else, too. And since this only makes sense if everyone is using TLS, we now redirect every HTTP request to HTTPS first before having our web server replying to it. That means any website, any download is now going over HTTPS.

To enforce that, we use HTTP Strict Transport Security (or HSTS) which lets every browser remember, that “” is only available over HTTPS. The next time, you enter that domain into your address bar, the browser will remember to connect over HTTPS only.

Improving TLS performance

Additionally, we use OCSP Stapling, which will help to improve the speed of setting up the first TLS connection. The browser would contact the CA which is Let’s Encrypt in our case and check if the certificate that has been received from the web server is still valid or has been revoked. That takes some time since it is an extra TCP connection and the CA has to respond to a large number of these OCSP requests.

Instead, our web server does this for you and staples the OCSP response to the TLS handshake. It is signed and therefore the browser can trust it without having to contact the CA to verify.

On top of that, we cache TLS sessions to resume them faster.

Securing Encryption

We only allow the browsers to use TLS 1.2. Anything else is not possible since they are considered broken or cryptographically weak.

And finally, we reviewed the list of allowed ciphers and removed anything else but AES256 and AES128 in GCM mode or in CBC mode with SHA384 or SHA256. We introduced using ChaCha20 with Poly1305.

The key handshare is only possible using either the Elliptic Curve Diffie Hellman algorithm or ECDSA. None of which rely on a discrete logarithm.

Downsides of all of this

This is now all new and shiny with icing on top. Latest cryptography. Strongest ciphers. What could go wrong?

We will inevitably kick out a number of users here to enforce these new things. That is at least: Firefox 26 and older, Chrome 29 and older, IE 10 and older, Opera 16 and older, Safari 8 and older and Android 4 and older. Those devices and browser won’t be able to contact our web servers securely and more and since we insist using TLS only, they won’t be able to connect with us at all.

The idea is to try this out now. If you have issues connecting and it should work, please let us know. This will need to be a trade-off of what is good security and what people actually use. But I do have the intention to force you XP users out there to finally upgrade. It’s 2017.

Late spring cleaning in progress

All these things happened during our yearly security review and updating where we check if every part of our infrastructure is using the best possible security that is available to us.

Of course we also added Let’s Encrypt certificates to our other services like Mail and XMPP. But we are not fully done and will need to improve more when ever there is time to do so.