In this update cycle, IPFire introduced one of the biggest upgrades OpenVPN has seen in years.
Cipher negotiation, cleaner defaults, and a simpler configuration experience will make your VPN connections more secure, more future-proof, and easier to manage.
Since OpenVPN has been around for some time, supports all mainstream operating systems out there, and has its roots in a simple TLS tunnel that can pass around packets, a lot has changed since then. Operating systems have become more complex, and demands as well. In the era of working from home, the people who will quite likely use OpenVPN on a daily basis has massively increased. How to cope with this and keeping hundreds of millions of workers and companies safe?
From IPsec to WireGuard: A Short History of VPN Protocols
Historically IPsec had a bad reputation. It was the only VPN technology around - and is actually part of the IP standard itself - but implementations have been lacking behind. They were complicated to use, VPNs were not stable and very quickly it was evident that some problems lie in the design of the protocol itself. Whilst the designers of IPsec went back to the drawing board to improve the protocol, some others were using other existing technology to build VPNs easily. CIPE was an early thing that used static encryption and wrapped packets into UDP. At least spiritually, OpenVPN has become a successor of CIPE by using some of those ideas, but rebasing everything on TLS.
When we say TLS, it was not all that simple. When a browser is opening a connection to some website, it will negotiate with the website which versions of the TLS protocol and which ciphers are supported. Both, the server and the client, might have some minimum requirements configured, but generally the server choses the best out of what the client has to offer. That way, browsing should always be as safe as possible, but also very compatible across various client softwares and even will support some legacy software. This, however, was not at all what was happening in the VPN world.
Why Cipher Negotiation Matters
To handle the negotiation between peers, IPsec has invented a whole protocol which is called the Internet Key Exchange protocol - or IKE for short. Despite negotiating keys, it will also negotiate ciphers, hashes and more settings that should be used. The actual data is then being transported over a selection of other protocols, most commonly Encapsulating Security Payload (ESP). This all is great when it all comes to talking to all sorts of clients on the other side, but at the same time is bringing in all the complexity that was so frustrating at the time.
WireGuard for example is going the complete opposite way. There is no negotiation or even manual configuration about what cipher to use. It is instead hardcoded into the standard and can never ever change. That way, the protocol becomes very simple and all of the negotiation part is eliminated. On the other hand, you will be stuck with exactly those ciphers. Once it breaks, WireGuard will be broken too.
The Old Way: Static Ciphers and Painful Upgrades
OpenVPN has pursued a more "in the middle of the road" approach. In the past, the cipher could be configured, but it was not negotiated. That means that the server and the client had to have the exact same configuration for the connection to work, but there was freedom in which cipher to use. If it would become cryptographically weak, it could simply be replaced with something more modern and stronger.
Or could it?
In theory yes, but in practice there was a problem: When the server changed its settings, all clients had to change them, too. At the same time. We have a couple of IPFire users with many hundreds of OpenVPN clients out there. Insurance companies with people on the road, trucking companies that send their drivers across the entire US, companies that have security cameras connected using OpenVPN. Changing everything over night? Impossible! So they got stuck with whatever good or bad choices they have made in the past.
When OpenVPN was introduced to IPFire, the default cipher was Blowfish. A solid cipher back then developed by Bruce Schneier, but of course over time it has become outdated. Although OpenVPN and IPFire supports their direct successor Twofish, it has never really caught on. Migrating would be too painful and the train was generally going towards AES as there was more CPU power available to run complex block ciphers like that.
So once again, there was no good path to migrate any OpenVPN clients and if you were running a setup with a lot of OpenVPN clients you might have been stuck on Blowfish for forever. That is absolutely unacceptable from a security point of view right now. But what can we do?
The Big Change in IPFire: Automatic Cipher Negotiation
With this release, OpenVPN will finally be able to perform some cipher negotiation which in essence works very similar to IKE. From now on, a client configuration generated with IPFire will not contain any cryptographic information any more. It has actually been stripped down to only hold the most basic information which is where to reach the server, what type of VPN it is setting up and of course the key material. Once it connects to the server, the server will evaluate the capabilities of the client and choose the best path forward. This unlocks that the server can work with various clients using different configurations which is the first ingredient we need when we want to migrate.
Cleaner Configuration and Smarter Defaults
From IPFire 2.29 - Core Update 197, we have first of all decluttered the OpenVPN configuration page. Gone are all those complicated crypto checkboxes and have been moved to the "Advanced Settings" section. Have a look if you want to, but there is no reason to actually reconfigure anything any more unless you know exactly what you are doing. I like to bring you a simple and intuitive web UI (I know it could be prettier) that has great defaults that simply work.
What has actually changed? What used to be the cipher selection has now become the fallback cipher. If clients are using an older version of OpenVPN (< 2.4), they will continue to use this way of encryption. All other clients will from now on perform cipher negotiation which can be configured in the slightly bigger box. That way, we can keep old clients working (for now) and we will be able to migrate new clients to modern ciphers at the same time. On new installations, the fallback cipher configuration will be empty which will completely disable the older way to connect as it will soon be removed anyways.
From then on, all you clients can be gradually updated and can be flexible in which version of the OpenVPN client they are using. There are a couple of bottom lines that we would expect, but those are all in line with general security best practices: Use the most recent version if possible, otherwise use a version that is at least in support. At time of writing this, the only version that is currently supported upstream is OpenVPN 2.6. All previous versions will no longer receive any security fixes.
Keeping Older Clients Connected (For Now)
Since OpenVPN has been a big problem for us in the past, we have now made huge changes which hopefully allow us more flexibility and fewer breaking changes in the future. The static configuration used to be very problematic when any changes were required are now hopefully a relic from the past. OpenVPN 2.7 is around the corner and we are looking to upgrade IPFire as soon as possible to take advantages of the new release. But for now, we will still even support a few clients from the past:
- Clients that don't support cipher negotiation - OpenVPN <= 2.3 These should no longer be around as support for them has ended many years ago. If you are running a client like this, you should urgently update as they won't be supported any more by future versions of IPFire.
- If you have manually disabled cipher negotiation in your client, you won't be able to upgrade to OpenVPN 2.6 or later. Since IPFire now supports this feature, you can remove that switch.
- In the future, we will completely remove support for the fallback cipher option. With OpenVPN 2.7, we will already have to say goodbye to Blowfish, Cast and RC2 as they have been removed from this OpenVPN release.
We believe that (unless you have made your own changes) virtually nobody will fall into this category. So the advice is: Ensure you have a recent version of OpenVPN on all clients all you won't have to worry about anything now and in the future.*
What’s Next
This is only the first step. In the next post, we’ll explore how these improvements allow us to reclaim wasted IP address space and simplify OpenVPN’s internal networking. Stay tuned for more ways IPFire is making VPNs faster, leaner, and easier to manage.