VyOS 1.3.0 (Equuleus) is now GA, and images are available to our customers and contributors.
After three years in development and an extended-release candidate/early production access period that lasted almost a year, it's finally time to call it the new LTS release.
Many thanks to everyone who made it possible:
We will stop making public nightly builds of the Equuleus branch, but everyone is free to build LTS images from source.
Remember!
If you contributed to the project, whether by coding, testing, or writing documentation, then you are likely eligible for a contributor subscription that grants you access to pre-built images. If you don't have a contributor subscription yet, you can apply by filling this form.
We worked hard to ensure that VyOS 1.3.0 is stable and production-ready, and we proved it by running it on our own production routers for many months, and other early adopters who ran RC and EPA releases confirm that.
However, it's still a big release with many changes. There's always a chance of unexpected interaction between features, unexpected effects of changes in the underlying open-source networking software, or simply bugs that our tests failed to trigger.
We advise everyone to try the upgrade on a lab VM with your production configs first, to ensure that they load and appear to function correctly. If you run into any issues, please contact us and report them!
Upgrading directly from VyOS versions older than 1.2.0 is no longer officially supported. In-place upgrade can still be done sequentially: to VyOS 1.1.8 (if required), then to 1.2.x, and finally to 1.3.0.
However, configuration files from any older VyOS versions can still be loaded directly.
VyOS 1.3.0 no longer supports loading configuration files from Vyatta Core older than 6.5 (released in 2012). Vyatta Core versions going back to 6.0 can be upgraded in-place by updating them to VyOS 1.1.8 first and following the same procedure as for updating an old VyOS version.
Certain incompatibilities exist between 1.2.x and 1.3.0, caused by changes in the underlying software.
OpenVPN versions found in older VyOS releases would not check the nextUpdate field of CRL (Certificate Revocation List) files, so there was no concept of an "expired CRL" in practice, even though there is such a concept in x.509.
However, starting from version 2.4, OpenVPN started actually checking that field, so CRLs can expire. To make things worse, the default nextUpdate time in the popular easy-rsa toolkit is 30 days, so if you are using easy-rsa and haven't revoked any certificates lately, there's a good chance that your CRL is already expired.
To fix that issue, you need to re-generate your CRL. You can also increase the expiration interval in your openssl.cnf, e.g. to default_crl_days=3650 (arguably, a never-expiring CRL is much less problematic than a never-expiring server certificate).
OpenVPN used the Blowfish cipher as its default for a long time because it's fast, freely-licensed and not encumbered by any patents. However, as a cipher with 64-bit key, it's vulnerable to the Sweet32 attack and is no longer considered secure.
In VyOS, we never disable anything right away unless it makes routers vulnerable to a remote attack that can be executed from any host. Cracking Blowfish requires sniffing hundreds of gigabytes of encrypted traffic, so for most VPN users, it's a concern for sure, but not an immediate concern. Which is why we didn't disable Blowfish in VyOS 1.2.x
Still, in 1.3.0, it's time to deprecate it. Blowfish is now disabled by default, but can be re-enabled with set interfaces openvpn vtunX encryption cipher bf128 .
Many old OpenVPN client config files may have the cipher hardcoded, so you should review your user's configs before upgrading, or re-enable the Blowfish cipher right after upgrading and gradually replace user configs.
This release fixes whole 53 issues from the previous 1.3.0-epa3 preview release, but we have no illusions about it being completely free of bugs. There are still issues we are planning to fix in maintenance releases.
Most of those issues existed for a long time. We do not consider those issues insignificant, far from it—we assure you that we'll fix them in future releases in the nearest months.
Recently a community member discovered that VRRP health-check scripts do not work with sync-groups anymore, while it worked in 1.2.x (T4081). The root cause is an incompatible change in keepalived, our VRRP backend.
In older versions, health check scripts could be attached to individual VRRP groups and failure of any of those scripts would trigger sync group failure. In new versions, health check scripts are supposed to be attached to sync-groups instead.
If you are using both VRRP sync groups and health check scripts, you should postpone the upgrade and let us know. We are interested in opinions regarding the ways this issue should be handled. The really tricky part is what to do with setups that have independent health-checks attached to several VRRP groups participating in a single sync group. If you are affected by this issue, please contact us.
The big features first introduced in 1.3.0 are:
The list may look short, but remember that we backported features from the development branch to 1.2.x whenever possible, so this list is limited to features unique to 1.3.0 that could not be backported because it was too risky or because new features rely on reworked internals of the 1.3.0 branch.
Since VyOS 1.2.0, our releases are named after constellations sorted by area in square degrees from the smallest to the largest. VyOS 1.2.x was named Crux after the Southern Cross, and the 88th release of VyOS will be named Hydra, then we'll run out of constellations. With a new LTS release every three years it will take us 264 years, so we have plenty of time to choose a new naming scheme.
This release is named Equuleus, after a small constellation in the northern sky. Equuleus means "little horse" in Latin, which is already reflected in the boot splash.
Lots of things! We assume that more people using VyOS 1.3.0 will uncover more edge cases in our rewritten code, so we are prepared to listen to all bug reports and make maintenance releases to fix them.
We are also working on the new build system that will make it easier to create and maintain custom image flavors and will serve as base for Autonomus Build Environment or ABE for customers who require build and serve VyOS in air gapped environments (for example ships including space ones)
Team making progress towards reproducible release builds. And there's a high-level API coming that will serve as a foundation for a new web GUI and a stable protocol for external management tools—we'll post an update when it's more complete and there is something to show.
1.2.9 release is coming next to provide the current LTS release users with some more bug fixes and some small features before placing the 1.2.x branch in a "extended maintenance" mode where it will only receive fixes for serious bugs and exploitable security vulnerabilities. VyOS 1.2.x will be supported until the mid of 2022, with a possibility for extended support after that point.
And, of course, the 1.4/Sagitta release is already under development. Soon we will start making monthly snapshots of that branch to allow enthusiasts to try out the new code and its new features, so stay tuned for updates.