VyOS 1.4.0 GA release
Hello, Community!
The VyOS 1.4.0 release has finally reached general availability. Its configuration syntax and API are frozen for any changes now— we can add new commands, but existing commands and functions will stay the same until it reaches EOL to make it friendly to automation tools. Let us review what is new in this release!
Its development started in late 2021 and took over two years to complete — not least because we had to rework entire subsystems and eliminate a lot of the remaining legacy code to unlock the path to long-awaited improvements.
The only legacy component from the pre-fork times is the WAN load-balancing daemon. There are no legacy (non-XML) command definitions anymore and no legacy scripts that would not follow the modern structure with separate verify, update, and apply stages. That makes the system much easier to maintain, extend, and contribute to. But it also unlocks the path to implementing commit dry-run and parallelized commits — not in 1.4, but in future releases for sure.
This release is named Sagitta after a small constellation of the northern hemisphere, and its name means an arrow in Latin — you can see it in the new boot splash. That constellation is not located near the far more famous Sagittarius and is not related to it in any way.
Subscribers can get the images from the downloads portal. If you are contributing to VyOS and want LTS release images for personal use, remember that we are happy to share them through contributor subscriptions.
We hope that upgrades will be smooth for all users, but it is a big release with many changes in the CLI syntax and behavior, so please read the upgrade considerations section carefully!
Upgrade considerations
Image size
VyOS 1.4.0 ISO image is about 460 megabytes large. This is about 100 MB larger than 1.3.x images that are about 360 MB in size. We do not expect this to be a problem even for very small devices.
Removed features
Cluster
The old clustering feature (set cluster
) was removed because the underlying implementation (heartbeat) was unmaintained.
The good news is that our VRRP implementation can already do everything that the old cluster could, including more. So, we made a migration script that converts old cluster configs to functionally equivalent VRRP configs.
The only possible issue is that if you are running an HA pair with the old cluster, upgrading one node to 1.4 can lead to a "split brain" scenario — the backup node will think that the active one has failed because it will not receive the Heartbeat cluster keepalive packets already and will not listen for VRRP keepalives yet.
The simplest way to avoid that is to delete the cluster config from the backup node before upgrading the active one. If you do not save the config before upgrading, cluster config in /config/config.boot.default
will be converted once you reboot after upgrading.
Deprecated features
Site-to-site OpenVPN with pre-shared keys
OpenVPN with pre-shared keys has served as a lightweight, easy-to-configure alternative to full-grown VPN setups with a certificate chain. However, that approach is flawed because pre-shared keys do not provide long-term security: TLS uses key exchange mechanisms to derive session keys and rotate them to limit the time attackers have to brute-force a key, but a pre-shared key stays the same and if attackers manage to brute-force or extract it, they will have access to all encrypted traffic — past, present, and future.
Therefore, the OpenVPN team decided to deprecate support for pre-shared keys. We will support them throughout the 1.4 LTS release lifecycle, but we cannot guarantee that we can do it in 1.5, so we encourage everyone to move to a secure but still simple alternative: self-signed certificates with peer fingerprint verification. A good thing is that now you can easily generate certificates and view their fingeprints right from the VyOS CLI, and this leads us to the next part...
CLI changes
PKI
Historically, VyOS stored cryptographic material such as certificates and private keys in files and only referenced file paths in the config. That made moving configs between systems much harder since configs stored in the commit archive would not be enough to re-deploy a system — you would also need to copy all referenced files.
Starting from 1.4.0, all cryptographic material required for VyOS features to work is stored right in the config file under the new pki
subtree.
All old configs are automatically converted to the new system, so you do not need to adjust your configs by hand — only get used to the new commands for new setups (took me a while, I have to admit).
What is even better is that there are now commands for generating PKI data, such as run generate pki ca
that can either save generated data to files or install it in the config, so you do not even need external tools like EasyRSA to maintain a small-scale PKI anymore.
Check out the PKI docs for details!
Firewall
The firewall subsystem was completely rebuilt using nftables, the new default in Linux, instead of legacy iptables. The road to nftables was rather bumpy, and we made a few implementation and design mistakes along the way.
Now, firewall rulesets are no longer interface-bound — you can match interfaces and interface groups in rules.
vyos@vyos# show firewall
group {
interface-group LAN {
interface eth0
}
interface-group WAN {
interface eth1
interface eth2
}
}
ipv4 {
forward {
filter {
rule 1 {
action jump
inbound-interface {
group WAN
}
jump-target WAN-IN
outbound-interface {
group LAN
}
}
}
}
name WAN-IN {
rule 10 {
action accept
destination {
port ssh
}
protocol tcp
}
}
}
The biggest mistake we made in the early 1.4 builds was the removal of the zone-based firewall. The reason was that the new syntax allowed doing everything that was previously impossible with the "normal" firewall because its rulesets had to be assigned to individual network interfaces.
However, we received a lot of feedback from users and found that many people liked the mental model of zones and that, in many cases, zone-less configs generated by our migration scripts were much larger, more difficult to follow (and slower to commit) than zone-based originals.
So, we reimplemented a zone-based firewall on top of the new nftables infrastructure — the only change is that it is now under firewall zone
rather than the old zone-policy
subtree. Everything else is more or less the same (and old configs are automatically migrated, as usual).
set firewall zone WAN from LAN firewall name WAN-LAN
New features
Rollback without reboot
One of the long-standing problems in VyOS CLI was that rollback to a previous configuration revision required a reboot. That was caused by a bunch of unfortunate design decisions from the pre-fork times that made it impossible to generate a correct diff between the running config and a config file — there was no parser that would fully understand the configuration file format and there was no API for retrieving values from the running config in a way that could distinguish manually set values from defaults. Now that's no longer a problem, and finally non-disruptive rollback is here.
So far it is under a different command: rollback-soft
. The old rollback
command is still there and works just like before. In future releases we will remove it and make rollback-soft
the default.
The new soft rollback also works differently from the old VyOS rollback and JunOS. It does not silently apply changes, instead it generates and applies a diff to the current configuration session so that you can review the changes and decide whether to commit them or not. The command notifies about that behavior to avoid confusion.
vyos@vyos# set system host-name totally-not-vyos
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# rollback-soft 1
Rollback diff has been applied.
Use "compare" to review the changes or "commit" to apply them.
[edit]
vyos@vyos# compare
[system]
- host-name "totally-not-vyos"
+ host-name "vyos"
The primary motivation is to make finding bugs in the rollback diff generation algorithm easier, if there are still any. However, we may keep this behavior indefinitely as an extra safeguard to prevent situations like "oops, I reverted to a completely wrong revision". Let us know what you think!
Routing
There are two new routing protocols in this release. One of them is Babel — a modern distance-vector protocol. The other addition is PIM6 — Protocol-Independent Multicast for IPv6.
Another addition is failover routes — static routes only installed in the actual routing table if the configured next hop passes an availability check, such as an ARP probe or an ICMP ping.
Finally, there is now support for segment routing!
NAT
There is now NAT64 in addition to the usual NAT and NAT66.
And there is finally the option to use firewall groups in NATs, including the new interface groups:
set nat destination rule 10 inbound-interface group WAN
VPN
One new feature is the remote access IKEv2 server (aka IKEv2 road warrior scenario). Now you can connect many desktop OSes and mobile devices to VyOS without the overhead of L2TP.
While VyOS is mainly used as a VPN server, it can now also be an SSTP client. We may use this implementation as a blueprint to add more VPN client features in the future.
Services
There is a built-in Zabbix agent in addition to SNMPv2/v3 and Telegraf. The simplest configuration is just set service monitoring zabbix-agent server zabbix.example.com
.
Another completely new service is an HTTP load balancer backed by HAProxy.
Finally, the long-awaited config synchronization feature is now supported. Synchronization uses the new HTTP API and is unidirectional to avoid unsolvable problems when reconciling diverging configs. We believe that a primary-replica setup is good for all practical purposes, and we plan to keep extending the synchronization mechanism to new config subtrees.
Plans
This release is based on Debian 12 (Bookworm). That Debian version was released in June 2023 and has four years of mainstream support ahead — and the help of the Freexian extended LTS project that we are sponsoring will make it even longer. We plan to support this release for at least three years, possibly longer if there is demand for it.
Comments