VyOS Networks Blog

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!

Upgrade warning: do not upgrade VMs deployed from ISO images to platform-specific flavors

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.

Security

Fixed Dropbear host key reuse problem that made console server users vulnerable to MitM attacks (T7217, CVE-2025-30095)

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:

1. VyOS uses Dropbear SSH server for its console server functionality.

2.  Debian's packaging for Dropbear generates host keys in the post-install script. The same behavior exists in the OpenSSH server packaging, but live-build (the Debian image build tool) has a safeguard against OpenSSH key reuse — a built-in hook that removes host keys from the image, to allow them to be regenerated anew after image deployment. However, it turned out that live-build has no equivalent safeguard for Dropbear, so every installation made from the same image would use the same host key.

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.

Statement on CVE-2024-3596 ("Blast-RADIUS")

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.

Migratable configuration changes

Fixes and improvements in redistribute table for BGP

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

New features and improvements

New command for uploading tech-support records

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!

Flavor compatibility check on upgrade

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.

Other new features and improvements

• Check architecture and flavor compatibility on upgrade attempts (T6389).
• Add an option to assign static IP address to IPoE server users (T6628).
• Add PPPoE server options to accept any service name and blank service name (T6685).
• IPoE-server add the ability to configure Lua scripts for username mapping (T6872).
• Add an option to start sessions with an unclassified packet to IPoE server (T6906).
• Add source-vrf source option to route maps (T7158).
• Add route-map and metric options to "redistribute table" in BGP (T7163).
• Add port option to GENEVE tunnels (T7171).
• Add a command to automatically upload tech-support report archives to a server (T7193).
• Containers add capability CAP_MKNOD (T7204).
• Add CLI to disable LDP establish hello packets (T7286).
• pki: race condition for acme requested certificates - CA auto import only on the second run (T7299).

Bug fixes

• Shaper QoS policy does not recognize 'lowdelay' DSCP value (T681).
• DHCP default route duplicated when moving interface between VRFs (T5103).
• Conntrack logging doesnt seem to be working (T5471).
• Raw output for system storage op mode causes exceptions on live CD (T6514).
• VyOS local system users TACACS+ authorization requests do not work correctly (T6613).
• Show log firewall not printing logs for default-actions for custom ruleset (T6636).
• Strings with spaces in "set interfaces * address" cause an ipaddrcheck argument error (T6739).
• Segmentation fault when checking incorrect IP ranges with ipaddrcheck (T6744).
• Incorrect flow isolation policy parameters generated for CAKE QoS policies (T6790).
• QoS policy priority-queue is broken by default (T6799).
• Unhandled exception when setting priority-queue QoS policy type to random-detect (T6800).
• The default route distance for PPPoE (210) in the migration script is incorrect and may break server availability (T6863).
• Support matching ethertype in QoS policies (T6874).
• Empty "ntp" CLI node causes a config migration error when upgrading from VyOS 1.3.x (T6911).
• Offload RPS fails on CPUs with more than 32 cores (T6917).
• PPPoE server does not allow listening on physical interfaces if VLANs are present in the configuration (T6936).
• bfd: fix invalid generated template when no multi-hop profile is defined (T6945).
• Missing cron file for geoip auto update (T6986).
• lsb_release reports the system to be debian (T6992).
• Use VyOS release-train in /etc/os-release codename over Debian release name (T7019).
• Incorrect versions of libnss-mapuser and libpam-radius-auth are included in the build, breaking RADIUS authentication (T7020).
• VRF name "up" is reserved and should not be used (T7024).
• Missing 'version' in manifest.json will cause a timeout of 'make test' (T7031).
• Disallow upgrades to non-matching flavors (T7034).
• RADIUS source-address option does not work with IPv6 (T7039).
• SSH Agent is not available for Git commit archive (T7048).
• 'set service webproxy domain-noncache <domain>' command does not work (T7057).
• Regression of T3240 in WIDE dhcp6c - Missing patch to support configuration of custom DUID (T7058).
• Upgrade may fail on instances with limited memory due to insufficient space in /tmp/ (T7102).
• DHCPv6 client is restarted on every change to the interface (T7135).
• Cannot set an agent-address in sFlow if VRF is used (T7136).
• "redistribute table" option in BGP does not work correctly (T7161).
• VXLAN interfaces disappear if the parent wireguard interface was changed (T7166).
• Fix sed pattern for change in OPAM install.sh (T7170).
• vyos-domain-resolver not picking up non-default configuration values (T7176).
• Firewall interface-group with a container interface fails validation on reboot (T7177).
• Unhandled exception in SNMP v3 configuration without engineid. (T7180).
• vyos-netplug-dhcp-client requires Config instead of ConfigTreeQuery (T7182).
• bond: error message interpreted as list when it's a string and thus loosing information (T7191).
• Bridge allows to specify the same member interface more than one time (T7192).
• lldp: disable individual interface has no effect if 'all' is defined (T7194).
• Remove unintended binary files from ipaddrcheck source tree and keep them from re-appearing (T7195).
• VXLAN needs to make remote and group options mutually exclusive (T7219).
• Unhandled template error in "generate ipsec profile ios-remote-access" (T7225).
• LDP Hello packets are generated to answer incoming Hello before forming neighbor adjacency (T7226).
• Proxmox grub console type should be tty0 by default (T7231).
• DHCPv6: add smoketest verifying that there is no invalid syntax or parsing error for wide-dhcpv6-client (T7248).
• Virtual-ethernet Interface vif mtu does not work (T7293).
• image upgrade will replace symlinks with a copy (T7294).
• ACME certificate updates fail due to missing timezone info (T7295).

Other resolved issues

• Use ipaddrcheck for validating IP address ranges (T6743).
• VyOS' FRR is not linked against PCRE2, reducing BGP convergence performance (T6854).
• Mark FastNetMon as deprecated (T6919).
• Add an option to specify bootloaders to the image build arguments (T6922).
• "monitor log" should have no output color at all (T6971).
• iproute2: disable colored output by default (T6979).
• Treat vyos-domain-resolver as a real service (T6983).
• Extend smoketesting platform to also validate /etc/release | lsb_release content (T6999).
• TACACS: extend smoketests with a live tac_plus server running as container (T7023).
• Source NAT smoke tests fail due to an incorrect interface name (T7033).
• RADIUS: extend smoketests with a live freeradius server running as container (T7038).
• Allow general binary includes in flavor files (T7109).
• Update ipaddrcheck versions and changelogs (T7199).

Deprecations

FastNetMon (service ids ddos-protection) is now deprecated and will be removed in VyOS 1.5

VyOS 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.

GnuPG signatures will be phased out in 1.4.3 release in favor of minisign

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.