Michael Tremer

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

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

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

AES-NI does not mean performance

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

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

Performance isn’t everything

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

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

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

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


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


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

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

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

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

Michael Tremer

Feature Spotlight: On-Demand IPsec VPNs
by Michael Tremer, May 1

Although this is not really rocket science, I find this feature exciting. VPNs that switch on when you need them and switch off when they are idle. It is as simple as that. The IPsec stack inside IPFire is under constant development and improvement. With almost every single update, we introduced some minor new feature or added ciphers, integrity algorithms or simply just fixed bugs.

Today, I would like to highlight this one feature though: On-Demand VPNs

It works in that way, that strongSwan, the software that is negotiating IPsec connections is installing a trigger in the kernel. When ever a packet is sent from a client on the local network to a destination on the other side of the VPN, it will hit that trigger which then causes strongSwan to try to establish the connection.

strongSwan is doing all sorts of protocol negotiations, but as soon as a VPN connection is established, the kernel is doing the heavy lifting; i.e. encrypting and decryption as well as routing packets. It is really fast doing that and given the right hardware, IPFire is able to route 10G VPN connections with solid encryption of course!

During the establishment of a VPN connection, the client will continue trying the other end of VPN. Some retransmissions might happen if opening up the VPN takes a little bit longer. But as soon as it is up, the connection is ready for use as usual.

Has no packet been transferred over the VPN for 15 minutes, the connection will automatically be shut down. That means that the system can save some resources since it does not constantly need to re-negotiate the IPsec Security Association and send keep-alive packets. On some weaker systems that will save some resources.

IPsec is however quite lightweight so that this is not really a problem to keep up a tunnel. But it adds up quickly if you have a number of them. That is one of the main motivations to build this in the first place. Some other reasons are that strongSwan tries a little bit harder to establish the tunnel if there is traffic (because of the triggers) which helps to keep up flaky connections, too.

How to?

To enable all this goodness, there is not much to do. Just go to the “Advanced Settings” section of your IPsec net-to-net connection and select “On-Demand” as “Start Action”. That is all there is to do. The other (and default) option is too keep up the connection at all times.

The status will be shown on the web user interface as “ON-DEMAND” when the connection is idle. If it is up, it will show as “CONNECTED” as it did before.

Michael Tremer

IPFire 2.19 - Core Update 110 is available for testing
by Michael Tremer, April 5

Hello Community,

it is once again time to give the next Core Update a good test before it is rolled out to everyone. We included some exciting features in this one as well as updates of many system packages and many bug and security fixes.

On-Demand IPsec VPNs

IPFire used to keep IPsec VPNs up all the time. This wastes resources if a connection is not used very often for example for a daily backup only.

Core Update 110 allows to configure IPsec VPNs in an On-Demand mode which will establish the connection as soon as it is needed and will close it after 15 minutes of inactivity to save resources.

This is especially handy for people who have a large number of IPsec net-to-net connections on either weak hardware or connections that are not required all the time like maintenance or backup connections, etc.

Performance Enhancements for DNS

unbound, the DNS resolver working inside IPFire, has been tuned to allow more concurrent queries and assigned more memory to keep a larger DNS cache.

Especially in large networks or when a burst of DNS queries needs to be handled, there is a notable increase of performance.


Updated Packages

apcupsd 3.14.14, bind 9.11.0-P3, cairo 1.14.8, conntrack-tools 1.4.4, fontconfig 2.12.1, freetype 2.7.1, lm_sensors 3.4.0, nettle 3.3, ntp 4.2.8p10, openssh 7.4p1 – for PCI compliance, pixman 0.34.0, squid 3.5.25, unbound 1.6.1, wget 1.19.1


avahi 0.6.32, cups 2.2.2 & cups-filter, ffmpeg 3.2.4, ghostscript 9.20, mc 4.8.19, motion 4.0.1, mpd 0.20.6, tcpdump 4.9.0

New Packages

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

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

Michael Tremer

IPFire 2.19 - Core Update 109 is available for testing
by Michael Tremer, February 4

The next Core Update with number 109 has been released for testing. It comes with a number of package updates which include security fixes and bug fixes all across the place.

DNS Fixes

The DNS proxy which is working inside IPFire has been updated to unbound 1.6.0 which brings various bug fixes. Therefore, QNAME minimisation and hardening below NX domains have been re-activated.

At start time, IPFire now also checks if a router in front of IPFire drops DNS responses which are longer than a certain threshold (some Cisco devices do this to “harden” DNS). If this is detected, the EDNS buffer size if reduced which makes unbound fall back to TCP for larger responses. This might slow down DNS slightly, but keeps it working after all in those misconfigured environments.



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

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

Hottest posts 2017 2016 2015 2014 2013 2012 2011