Hello, Community! VyOS 1.4.2 release images and the corresponding source tarball are now available for download to customers and holders of contributor subscriptions.
This release includes a fix for a security issue that made console server users vulnerable to MitM attacks, over forty bug fixes, a few improvements in BRAS functionality, performance optimizations that can improve BGP convergence time by as much as 5-10 minutes in some scenarios, and other improvements. Additionally, FastNetMon is now deprecated and is scheduled to be removed in the future 1.5 release, and we are also finally phasing out legacy GnuPG signatures in favor of minisign. Read on for details!
If you have a virtual machine that was deployed from a generic ISO or an update ISO (proxmox-update, openstack-update, vmware-update flavors — anything with "update" in it) using install image rather than from a platform-specific template, do not attempt to upgrade it to the new proxmox/openstack/vmware/etc. flavor.
Redeploy that instance using the supported deployment procedure — from a platform-specific flavor (e.g., OVA for VMware, the qcow2 image for Proxmox or OpenStack). If you attempt to upgrade them to the new unified flavors that assume that cloud-init had already run on the instance, it will corrupt your config.
Update ISOs were never meant for deployment — only for upgrades with add system image. It was technically possible to use them as installation ISOs on platforms that allow booting a machine from an arbitrary ISO and connecting to its console to run install image. It was a mistake on our side not to mark them as update-only and prevent installation from them right away. Starting from 1.4.2, such non-matching upgrades will be prevented automatically so you will not need to worry about flavor compatibility anymore.
Morgan Jones from Viasat discovered and reported a security issue that made console server users vulnerable to SSH MitM attacks. This problem does not affect the system SSH server (configured with set service ssh) — only console server connections over SSH.
A vulnerable configuration looks like this:
vyos@vyos# show service
console-server {
device ttyS1 {
speed 115200
ssh {
port 3000
}
}
}
}
The issue was that:
That would allow an attacker who had access to the same image as the target and the ability to intercept and modify packets between VyOS and SSH clients to decrypt or or break into the session. It generally would not allow an attacker to decrypt the traffic of past sessions, unless such sessions were established without PFS (which is very unlikely).
We now added the safeguard ourselves as a live-build hook, and made the configuration script generate keys if they don't exist. Current rolling release images, 1.4.2, and the upcoming 1.5-stream-2025-Q2 intentionally do not include host key migration on image update — to ensure that all updated systems start with freshly generated keys and never reuse the old, compromised ones. We will add Dropbear host key migration on update in subsequent releases.
The RADIUS client library that VyOS uses is still vulnerable to the attack discovered in 2024 and nicknamed "Blast-RADIUS". That vulnerabilty allows an attacker to trick a client into accepting a login without knowing the correct password. The reason we do not have a fix yet is that we use a fork of the original version by FreeRADIUS rather than the upstream library and those forks have diverged substantially. The reason we do not use the upstream library is that it simply does not support the behavior that people expect from network devices: it requires an already existing local account and is limited to verifying passwords. That defeats the purpose of RADIUS for network operators who expect to be able to login to any device without having to create local users.
It will take us some time to recreate and validate the fix. Meanwhile, the risk from that vulnerability is very low in practice because to execute it, the attacker needs to be able to intercept and modify network traffic between VyOS and a RADIUS server, which is located in a private management network in all cases we have seen. If they can do that, your network is already compromised (in fact, they are already logged in to your router). The attack is also computationally expensive: FreeRADIUS team estimates the cost of computing a collision fast enough to forge a response before client timeout to be around $1000 per packet. For the record, Cumulus Linux also does not have a fix in their latest source code yet. We plan to include that fix in 1.4.3 release.
redistribute table for BGPWe discovered that set protocols bgp address-family <family> redistribute table <num> was not implemented correctly and had no effect (T7161).
We also had a request to add metric and route-map options to that command (T7163). The original design would not allow doing that without a configuration syntax change — we had to convert a leaf node to a tag node to allow additional options
The change is very minor: the question is whether a pair of braces after the option is present in the config or not, the command syntax in the CLI would not change.
Normally we do not introduce any syntax changes and migration scripts in point releases, no matter how minor the changes are. However, since the option was broken and thus there couldn't be any functional configs with it, we decided to address both the bug and the related feature request at once.
Now redistribute table works correctly and there are two new subcommands:
set protocols bgp address-family <ipv4-unicast|ipv6-unicast> redistribute table <num> metric <value>
set protocols bgp address-family <ipv4-unicast|ipv6-unicast> redistribute table <num> route-map <name>For a long time, uploading large tech-support archive was an annoying problem because the support portal has a file size limitations, so files larger than 2GB had to be transferred through some other means.
Now there is a new operational mode command: generate tech-support archive upload user <name> ticket <number>. It generates and uploads an archive directly to our server over SFTP, without the inconvenience and security risks or using a third-party file sharing service. You can get the credentials for it from our support team, if you have a subscription.
We hope it makes life simpler for our support customers!
Historically, add system image <URL> would not attempt to check if the new image was appropriate for the system. Our old approach was to produce special images for virtual platforms and clouds where deploying from an ISO is either inconvenient or impossible, but to upgrade them, one would use a generic ISO image. That meant that people had to think carefully about their upgrade. For example, "If you use a VMware VM, you can deploy it from an OVA, but then you need to use a generic ISO to upgrade it because it includes open-vm-tools. But for Azure instances, you need an Azure upgrade ISO". And with certain platforms, upgrading to a wrong flavor could break the whole system or at least some functionality.
In some cases it could even create a security problem, when a machine installed from an image without cloud-init was upgraded to an ISO that has it, and cloud-init could reset the vyos user password to default, if it was running in an environment where actual configuration data was not available.
Now the new build flavor system allows us to produce and, most importantly, maintain as many flavors as we want with no additional effort. And data storage is a lot cheaper now than it was when we started VyOS back in 2013, of course. So, now the upgrade decision is very simple: for every supported platform, there are both platform-specific images and ISO images for upgrades with add system image or manual installation, if anyone wants it. The "generic ISO" flavor is only for off-the-shelf hardware and VMs that we do not have any special support for.
That finally allowed us to add a safeguard to add system image — now it refuses to upgrade if the proposed ISO's flavor is not the same as that of the running system. For hypothetical cases when a non-matching upgrade is necessary, there is a way to circumvent that (by executing the upgrade script with a specific option by hand, outside of the VyOS CLI), but unintentional non-matching upgrade is now a thing of the past.
service ids ddos-protection) is now deprecated and will be removed in VyOS 1.5VyOS has included FastNetMon for quite a while. However, the integration is rather shallow, and there is no real path to improving that functionality using the open-source version of FastNetMon.
We know some people find even that limited integration useful, so we plan to convert it to an addon at some point (once the CLI addon mechanism is available). However, we will phase it out as a built-in feature. Now it is marked as deprecated in 1.4. Soon it will be removed from rolling release images, and eventually removed in the upcoming 1.5 LTS release as well.
We added support for minisign signatures as an alternative to GnuPG all the way back in 2020, in 1.2.5 release. There is a lot to love about that tool: the main advantage is that its elliptic curve-based keys are tiny and can be passed as command line arguments, without having to import them into a system keyring. For our release key, that's:
minisign -P RWTR1ty93Oyontk6caB9WqmiQC4fgeyd/ejgRxCRGd2MQej7nqebHneP -m /path/to/image.iso
VyOS 1.4.2 still comes with GnuPG signatures, but when we release 1.4.3, it will only be signed with minisign, and we will remove support for verifying GnuPG keys from the add system image command as well.