Hello, Community!
Customers and holders of contributor subscriptions can now download VyOS 1.4.4 release images and the corresponding source tarball. This release adds TLS support for syslog, support for AWS gateway load balancer tunnel handler (on AWS only), an option to match BGP prefix origin validation extended communities in route maps, and more. It also fixes over fifty bugs. Additionally, there's now a proper validation to prevent manually assigned multicast addresses, which may break some old malformed configs, so pay attention to it. Last but not least, there's a deprecation warning for SSH DSA keys that will stop working in VyOS releases after 1.5 due to changes in OpenSSH, so make sure to update your user accounts to more secure algorithm keys while you still have the time.
This is unlikely to affect anyone but we still need to mention it. While we were working on a fix for the issue where VyOS mistakenly disallowed all-zero host part IPv6 addresses (T7973), we coincidentally found something that VyOS mistakenly did not prevent from happening — manually-assigned multicast addresses.
Assigning a multicast address to a network interface by hand doesn't do anything useful. Multicast groups must be joined and left using IGMP messages, and a process needs to be handling multicast traffic. But Linux and iproute2 generally allow users to create any configurations whether they make any sense or not, and we didn't have a validator to disallow that in VyOS.
Now attempts to assign multicast addresses by hand will correctly fail. However, that also means that existing configs with such addresses will fail to load now. If you suspect you may have a manually assigned multicast address in your config, take a moment to check and remove it.
VyOS has supported SSH DSA (ssh-dss) keys from its inception, like most OSes with SSH servers. We re-enabled their support when OpenSSH maintainers declared them deprecated and disabled them in the default configuration, because we believe that the risk that people would be locked out of their systems is unacceptable if we can avoid it.
It's usually a good idea to disable insecure algorithms once implementations of better algorithms are widespread. If someone has an outdated client, they can have difficulties connecting but they still can get into the system once they upgrade the client or find a different machine. Keys are a different story — it's possible for people to have only one account on the system, with password authentication disabled completely. If all users on such a system had ssh-dss keys, the only way back would be to use the password reset function, which requires physical or out-of-band access and a reboot.
That's why we kept ssh-dss support on as long as possible. However, OpenSSH 10.x has removed support for them completely, and Debian Trixie has that version, so once we move past Debian Bookworm, all users of ssh-dss keys will be locked out of their systems.
VyOS 1.4/Sagitta will support them until its EOL, and VyOS 1.5/Circinus is also based on Debian Bookworm so it's not an immediate concern. Still, everyone who still has users with ssh-dss keys needs to start phasing them out. To facilitate that, we added a prominent deprecation warning that VyOS displays every time on login if there are any users with ssh-dss keys.
Integration with Salt (service salt-minion) is now deprecated and is set to be removed in future VyOS versions — interest in that feature from the community and customers has been consistently low so we expect that it will not affect many people. However, we added a deprecation warning to give users time to either migrate to something else or let us know that they still want to use it. There is no set schedule for its removal yet but it's likely that the upcoming VyOS 1.5 will be the last release to support it
If you use Salt and want to keep using VyOS with it, let us know.
We found that our SSH server CLI still allows users to enter the cipher name rijndael-cbc@lysator.liu.se that is no longer supported in recent OpenSSH versions and breaks the server config (T8098). We have never seen that name used in the wild and never received any bug reports, so we assume it's not an issue for any real person. However, we will include a migration script for that in subsequent releases.
set policy route-map <name> rule <N> match rpki-extcommunity <valid|invalid|notfound> (T1124).
set service aws glb script on-create '/config/scripts/glb-create.sh'
set service aws glb script on-destroy '/config/scripts/glb-destroy.sh'
set service aws glb status format 'simple'
set service aws glb status port '8282'
set service aws glb threads tunnel '4'
set service aws glb threads tunnel-affinity '1-2'
set service aws glb threads udp '4'
set service aws glb threads udp-affinity '0-3'
run show interfaces kernel (T7268).set vpn ipsec ike-group <name> dead-peer-detection timeout (T7504).set interfaces dummy dumN mac <MAC> (T7686).show interfaces kernel statistics command (T7742).system login to config-sync (T7905).source-address is not configured on the system (T8024).set vpn ipsec remote-access connection <name> authentication always-send-cert (T8027).Fixed KeyError: 'reverse-proxy' when updating ACME chain (T8102).