Hello, Community!
We are happy to announce that the VyOS 1.4.0-epa1 image is now available to customers and contributors (and everyone can build it from the sagitta branch of vyos-build, of course)! If you are new to VyOS, the "EPA" part means "early production access" — that's the final stage when the release is already used in production by a subset of users and on our proper infrastructure. We declare it as a new Long Term Support release. This release has been in development since early 2022 and offers a large number of new features, plus some redesigns and removals.
OpenVPN with pre-shared keys had served us as a lightweight, easy to configure alternative to full-grown VPN setups that required 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.
For that reason, 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.
It boils down to a single new command: set interfaces openvpn vtunX tls peer-fingerprint. Conveniently, there is a way to generate certificates and view their fingerprints right through the VyOS CLI — we'll get to that later in the post!
We will start with features that are no longer in their original form since they are a very important upgrade consideration.
The most visible removed feature is the old clustering mechanism. There are multiple reasons for that decision. First, Heartbeat, the basis for that feature, is unmaintained now. Its successor, Corosync, is a cool project but not a drop-in replacement.
Second, the main promise of the cluster feature in Vyatta days was that it would allow redundancy of multiple types of resources. In practice, the only resource type it supported was IPv4 address. The bugginess of the underlying implementation limited further development.
As the Keepalived project kept evolving and as we exposed more features in our VRRP CLI, the old cluster became a bad alternative to VRRP: less functional, less stable, and less potential for further development.
Since VRRP now implements everything that Heartbeat-based cluster CLI could do, we removed the cluster and automatically convert all cluster setups to VRRP using the migration script mechanism.
If you are using the cluster, when your system first boots into 1.4.0, it should automatically come back as a VRRP setup without any intervention from your side. You only need to ensure that nothing in your network interferes with VRRP packets.
Some features still offer the same functionality and many improvements, but their CLI is now very different from older versions. One of them if the firewall configuration subsystem.
Ever since the first days of VyOS, firewalls have been a complicated subject for us. Before the fork, the original authors of the Vyatta CLI decided to mimic the access list CLI of Cisco IOS — maybe because many of them worked at Cisco before, maybe because they thought it would be a familiar CLI for network admins who grew up with Cisco IOS and products that took inspiration from it.
The main principle of that firewall CLI was that users define rulesets and assign them to network interfaces in particular directions (in, out, or local).
There were multiple issues with that approach. First, the limitation that a firewall rule could not apply to multiple network interfaces was completely artificial — Linux firewalls never had that limitation ever since the earliest days. The usual practice for firewall configuration on bare Linux was always to make rules centered on services and traffic directions so that they could apply to any network card layout.
Second, it made exposing more functionality of the Linux firewall (currently, NFTables) a lot more difficult. For example, transparent firewalls don't fit that paradigm at all.
To unblock the path forward, we had to eliminate the interface-based CLI and redesign it completely. That was a daunting task that required a lot of coding and testing, but finally, we were there.
At the basic level, the biggest change is that there are now default rulesets for every direction, protocol, and NFTables level, and it's possible to call custom rulesets from it if required. Here is an example of a very simple firewall config for forwarded IPv4 traffic:
vyos@vyos# show firewall
ipv4 {
forward {
filter {
default-action drop
rule 5 {
action accept
state established
state related
}
rule 10 {
action jump
destination {
address 192.0.2.0/24
}
jump-target WAN-In
}
}
}
name WAN-In {
rule 10 {
action accept
description HTTP
destination {
port 80,443
}
protocol tcp
}
}
}In addition to IPv4 and IPv6 L3 filter targets, there's also a transparent firewall at set firewall bridge.
There's also support for adding addresses to dynamic groups with a set timeout:
set firewall ipv4 forward filter rule 20 action 'drop'
set firewall ipv4 forward filter rule 20 add-address-to-group source-address address-group 'Blocklist'
set firewall ipv4 forward filter rule 20 add-address-to-group source-address timeout '60s'
set firewall ipv4 forward filter rule 20 recent count '100'
set firewall ipv4 forward filter rule 20 recent time 'minute'
set firewall ipv4 forward filter rule 20 state 'new'Last but not least, there are many more matching options in rules, and more to come: more options and more NFTables targets.
Also, as we said earlier in development updates, we initially removed the zone-based firewall CLI. We added a migration script to convert it to a normal firewall configuration. Now, everything that could only be done with zones can be done without them since firewall rulesets can apply to all interfaces simultaneously.
However, we received feedback from many users that equivalent non-zone-based firewall configurations were often much larger and harder to reason about, and that they liked the zone-based firewall mental model, so we realized our mistake and fully restored that CLI — if you like zone-based firewall, you can keep using it.
VyOS 1.3.x already supported NAT66 (also known as Network Prefix Translation), under set nat nptv6. In 1.4.x, that feature is placed under set nat66 source for consistency with nat64:
set nat66 source rule 1 outbound-interface 'eth0'
set nat66 source rule 1 source prefix 'fc01::/64'
set nat66 source rule 1 translation address 'fc00::/64'There are also more rule options compared to the 1.3.x version, such as exclude, disable, and log — like in firewall rules,
In older VyOS versions, cryptographic materials such as certificates and encryption keys were stored either in files in /config or inside the configuration subtree that used it. Storing data out of the VyOS config made it harder to migrate configs to a different machine, and it was also quite difficult to reuse the same CA in multiple VPN protocols, for example.
Now, in 1.4 there's a general PKI mechanism that allows the user to generate or import keys and certificates and store them in the config.
For example, this is how you can generate a self-signed cert to use with site-to-site OpenVPN:
vyos@vyos# run generate pki certificate self-signed install openvpn-local
Enter private key type: [rsa, dsa, ec] (Default: rsa) ec
Enter private key bits: (Default: 256)
Enter country code: (Default: GB)
Enter state: (Default: Some-State)
Enter locality: (Default: Some-City)
Enter organization name: (Default: VyOS)
Enter common name: (Default: vyos.io)
Do you want to configure Subject Alternative Names? [y/N]
Enter how many days certificate will be valid: (Default: 365)
Enter certificate type: (client, server) (Default: server)
Note: If you plan to use the generated key on this router, do not encrypt the private key.
Do you want to encrypt the private key with a passphrase? [y/N]
2 value(s) installed. Use "compare" to see the pending changes, and "commit" to apply.
[edit]
vyos@vyos# compare
[pki]
+ certificate openvpn-local {
+ certificate "MIICJTCCAcugAwIBAgIUMXLfRNJ5iOjk/..."
+ private {
+ key "MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgtOeEb0dMb5P/2Exi09WWvk6Cvz0oOBoDuP68ZimS2LShRANCAASp7D0vE3SKSAWAzr/lw9Eq9Q89r247AJR6ec/GT26AIcVA1bsongV1YaWvRwzTPC/yi5pkzV/PcT/WU7JQIyMW"
+ }
+ }Old configs that use the old approach are automatically migrated, so you don't need to take any action to start using it.
And, of course, there are multiple completely new features. Listing all new commands in a single post would be difficult, but many big new features are worth mentioning.
VyOS already supported PIM (Protocol-Independent Multicast) for IPv4, and now it supports it for IPv6 too.
For the simplest case:
set protocols pim6 interface eth0
set protocols pim6 interface eth1LVS (Linux Virtual Server) is a very well-established load-balancing technology that wasn't available in VyOS until 1.4.0. Now it is, and this is how you can set up a simple load balancer for HTTPS servers, for example:
vyos@vyos# show high-availability virtual-server
virtual-server Web {
address 192.168.56.107
algorithm least-connection
forward-method nat
port 443
protocol tcp
real-server 10.0.0.1 {
health-check {
script /config/healthcheck.sh
}
port 443
}
real-server 10.0.0.2 {
health-check {
script /config/healthcheck.sh
}
port 443
}
}One of the most frequently requested improvements to the NAT CLI was the ability to use firewall groups in NAT rules. Finally, that ability is there.
This is how you could use one rule to apply a translation to three different ports and two outside interfaces:
vyos@vyos# show firewall group
interface-group WAN {
interface eth1
interface eth2
}
port-group Services {
port 80
port 443
port 8443
}
[edit]
vyos@vyos# show nat
destination {
rule 10 {
destination {
group {
port-group Services
}
}
inbound-interface {
group WAN
}
protocol tcp
translation {
address 10.1.0.4
}
}
}Now that major cloud platforms are starting to charge for all use of IPv4 addresses, it seems like the ultimate end of IPv4 is getting closer, and the mechanism for communication with legacy networks will finally see some use. One of those mechanisms is NAT64, which allows IPv6-only hosts to communicate with legacy IPv4 networks — now there's a CLI for it in VyOS.
vyos@vyos# show nat64
source {
rule 10 {
source {
prefix 2001:db8:1::/96
}
translation {
pool 10 {
address 10.0.0.0/24
port 1-65535
}
}
}
}Babel is a modern distance-vector routing protocol that supports both IPv4 and IPv6. Thanks to its support in FRR, there's now a CLI for configuring it in VyOS.
vyos@vyos# show protocols babel
interface eth0 {
type wired
}
redistribute {
ipv4 {
connected
}
ipv6 {
connected
}
}Segment Routing is a way to define the forwarding path for packets — quite a bit like "source routing done right." It can be used with existing MPLS data-planes, and segment identifiers (SIDs) are mapped to MPLS labels.
Segment routing support in VyOS is still experimental and has known limitations, but we encourage everyone to test it and report all negative or positive findings.
Here is a configuration example for IS-IS:
set interfaces loopback lo address '192.168.255.255/32'
set interfaces ethernet eth1 address '192.0.2.1/24'
set protocols isis interface eth1
set protocols isis interface lo
set protocols isis net '49.0001.1921.6825.5255.00'
set protocols isis segment-routing global-block high-label-value '599'
set protocols isis segment-routing global-block low-label-value '550'
set protocols isis segment-routing prefix 192.168.255.255/32 index value '1'
set protocols isis segment-routing prefix 192.168.255.255/32 index explicit-null
set protocols mpls interface 'eth1'You can find more details and examples in documentation.
For a long while, our response to questions about monitoring agents was that it's very difficult where to draw a line. SNMP is a standardized protocol, while everything else is implementation-defined. Our concern was that if we added an agent for one system, we'd have to come up with some arbitrary reasons not to integrate more.
However, the number of popular monitoring systems remains very small. Zabbix is still one of the most popular, and we were still getting requests to add it to VyOS. So, in 1.4, you no longer need to install Zabbix agent packages by hand and can use the built-in CLI instead:
vyos@vyos# show service monitoring
zabbix-agent {
host-name gw.example.net
limits {
buffer-size 200
}
listen-address 203.0.113.1
port 10050
server 192.0.2.10
server-active 192.0.2.10 {
}
}Config sync has been another very frequently requested feature. Bi-directional synchronization is an intractable problem due to possible edit conflicts between routers that cannot be resolved automatically. However, a primary replica synchronization is a realistic goal.
Now in 1.4, there's an initial implementation for you to test. It uses the HTTPS API (so don't forget to configure it on the replica router!) and so far supports a limited selection of configuration sections to replicate: firewall, nat, and nat66. When its implementation matures, we'll add more sections and cover the entire config in the later version.
vyos@vyos# show service config-sync
mode load
secondary {
address 192.156.56.101
key qwerty
}
section firewallSSTP may not be the most widely used VPN protocol, but it doesn't harm to have either. We already had SSTP server functionality, but now it's also possible to use VyOS as a client.
vyos@vyos# show pki
ca example.com {
certificate MIICETCCAbegAwIBAgIUcfJb7qKqJLoVeMyes...
}
[edit]
vyos@vyos# show interfaces sstpc
sstpc sstpc0 {
authentication {
password letmein
username jrandomhacker
}
server vpn.example.com
ssl {
ca-certificate example.com
}
}If there's demand, we can also use the experience we gained from implementing it to add other client VPN interfaces.
VyOS has always supported network-to-network IPsec connections and L2TP/IPsec, but pure IKEv2-based remote access ("road warrior") IPsec VPN was not there — now it is. Here is a configuration example:
vyos@vyos# show vpn ipsec
esp-group RemoteUsers {
proposal 1 {
encryption aes256
hash sha256
}
}
ike-group RemoteUsers {
key-exchange ikev2
proposal 1 {
encryption aes256
hash sha256
}
}
remote-access {
connection RemoteUsers {
authentication {
local-users {
username jrandomhacker {
password letmein
}
}
x509 {
ca-certificate example.com
certificate vpn.example.com
}
}
esp-group RemoteUsers
ike-group RemoteUsers
local-address 192.168.56.107
pool dhcp
pool RemoteUserPool
}
pool RemoteUserPool {
prefix 10.20.30.0/24
}
}If no issues are found, our next image will be 1.4.0 GA (we still can do more EPAs if we discover significant issues)
We plan to support 1.4.x at least until 2026, and possibly longer if there is demand for it.
Stay tuned for updates!
Last but not least, I'd like to say thanks to everyone who made this release possible! In particular: Ana de la Hera Jaime, Andrii Andrieev, Andrii Apostoliuk, Andrii Moshenskyi, Bohdan Kolesnykov, Yu-Chiang (Date) Huang, Dmitriy Eschenko, Olena Maznitsyna, Erkin Batu Altunbaş, Fernando Maidana, Holly Cooper, Jaime Botella, Joe Nguyen, John Estabrook, Kim Hagen, Maryna Andriutsa, Michael Korobeinikov, Nicolas Fort, Oleg Gorobets, Robert Göhler, Santiago Blanquet, Srividya A, Taras Pudiak, Valentyn Sebalo, Viacheslav Hletenko, Volodymyr Huti, Yaroslav Korotash, Yevhen Bondarenko, Yuriy Andamasov, Christian Breunig, Simon Arthur, Shah Imrul Huq, and everyone else who contributed to it and helped us!