VyOS - Blog

VyOS Stream 2025.11 is available for download

daniil@sentrium.io (Daniil Baturin) — Mon, 17 Nov 2025 11:24:27 GMT

Hello, Сommunity!

VyOS Stream 2025.11 and its corresponding source tarball are now available for download. You can find them at the end of this post. This is the third VyOS Stream release on the way to the upcoming 1.5/Circinus LTS release and includes many of its features for you to test — most notably, a VPP-based accelerated dataplane.

VyOS Stream 1.5-2025-Q2 is available for download

daniil@sentrium.io (Daniil Baturin) — Fri, 11 Jul 2025 18:55:23 GMT

Hello, Community!

VyOS Stream 1.5-2025-Q2 and its corresponding source tarball are now available for download. This is the second VyOS Stream release on the way to the upcoming VyOS 1.5 LTS, and it includes multiple bug fixes and improvements, including the new implementation of WAN load balancing, a general mechanism for allowing conntrack-unfriendly protocols in transparent bridge firewalls, a fix for CVE-2025-30095 (active MitM in console server SSH connections) that was already delivered in VyOS 1.4.2, and more.

VyOS Project June 2025 Update

daniil@sentrium.io (Daniil Baturin) — Mon, 30 Jun 2025 17:23:51 GMT

Hello, Community!

This month's update looks small but there are quite a few big things happening. Expect a few release posts in the coming weeks! But apart from that, there are big ongoing developments inside the rolling release. First, we are ironing out the remaining issues in the VPP-based accelerated dataplane and we welcome everyone to test them.

In other areas, we are making steady progress at replacing the old configuration backend. Currently the focus is on the commit algorithm, that will make commits much faster and enable long-awaited features such as commit dry run (T7427). The other big things is the operational mode command system rework that will allow us to reintroduce operator level users and improve operational command documentation. Read on for details!

VyOS Project May 2025 Update

daniil@sentrium.io (Daniil Baturin) — Thu, 29 May 2025 10:00:08 GMT

Hello, Community!

Quite a lot of things have happened since the last update we posted in April. In particular, we added the last bit of functionality that we considered a hard requirement for the VPP-based accelerated dataplane: support for VPP firewall. This marks the point when we consider the minimal viable product complete and we plan to ship it in a VyOS Stream release later this year, likely in Q3 — although you don't have to wait for it to play around with it, since it's already in the rolling release.

We are also making a very good progress towards replacing the legacy config backend — that work is still in the development phase and has no visible effects, and will take a while longer to complete, but it's underway.

When it comes to bugs, there are more than twenty recent fixes, including a fix for the nasty bug that led to routing protocol configuration loss if a protocol daemon crashed. Another important fix contributed by a community member makes VMware VMs suspend and resume correctly. Last but not least, the login prompt is no longer displayed in a bold font — that one took more time to track down than anyone hoped, and turned out to be caused by a truncated Systemd service name (ANSI control codes do not reset themselves on word boundaries, you know...).

There are multiple improvements in the base system as well. There's a new set ystem option reboot-on-upgrade-failure command that makes the system automatically reboot into the previous image if the configuration fails to load after upgrade. We hope it will help multiple people avoid unplanned trips to remove places — of course there should be out-of-band management everywhere for this case, but we all know that the real world is not perfect.

Other recently added features include support for IPv6 address in the datasets for firewall remote groups, BPDU guard and root guard supports for bridges, a new option to limit BRAS services (IPoE, PPPoE, and friends) to a specific number of CPU cores to avoid system overload, and more — read on for details!

VyOS Project April 2025 Update

daniil@sentrium.io (Daniil Baturin) — Wed, 30 Apr 2025 10:30:19 GMT

Hello, Community!

The April update is here — just at the end of April. We've been busy working on the VPP-based accelerated dataplane — you can watch that work in the repository and play with it in rolling release images. However, there are more features and bug fixes, and we are happy to see more active community contributors — there are quite a few community PRs that we merged lately, including DDNS update support for Kea, auto ignore prefixes for SLAAC, and more — read on for details!

VyOS Project March 2025 Update

daniil@sentrium.io (Daniil Baturin) — Thu, 27 Mar 2025 14:10:08 GMT

Hello, Community! It's spring in the northern hemisphere, and here's the March update. A lot of our effort is currently going into the development of the accelerated dataplane based on VPP: We added a prototype of IPsec, and we are actively working on support for NAT. But there are many other updates, including a fix for a vulnerability in service console-server, support for loading firewall groups from a URL, an option to set a custom container registry, and more. Read on for details!

VyOS Project November 2024 Update

daniil@sentrium.io (Daniil Baturin) — Fri, 29 Nov 2024 14:06:15 GMT

Hello, Community!

The November update is here. This post is short, but not all we've done lately: many internal changes in the configuration system will soon significantly improve commit speeds and open up a path to even more significant improvements. The 1.4.1 release is around the corner, together with the first VyOS Stream image — all built by the new CI system that produces tarballs with the corresponding source code for every image. But now, let's focus on the changes we made in the rolling release in October.

VyOS Project July 2022 Update

daniil@sentrium.io (Daniil Baturin) — Tue, 30 Aug 2022 05:59:08 GMT

Hello, Community!

It is time for a new update! The most important news this time includes FRR upgrade to the latest stable version 8.3, RADIUS QoS attribute support improvements, a default log option for a zone-based firewall, and more. Read on for details!

VyOS Project June 2022 Update

daniil@sentrium.io (Daniil Baturin) — Fri, 29 Jul 2022 14:13:05 GMT

Hello, community!

It's been a while since our last update, so it is time for the progress update for June. Our schedule was definitely disrupted, but we never stopped working on improving VyOS, and we are getting back to posting development updated every month. Thank you for your patience!

In June we added a few new options for firewall, brought back the event handler — a feature we all missed, and thanks to the VyOS community, found and fixed some bugs. Read on for details!

Firewall groups today and tomorrow

daniil@sentrium.io (Daniil Baturin) — Fri, 16 Mar 2018 13:36:23 GMT

Substantial work has been done by Marian Tudosoiu to bring IPv6 firewall groups to the current implementation of firewall configuration scripts even before we give it a complete rewrite. It's already merged into the current branch and is expected to be included in the 1.2.0-rc1 release. Now it's probably a good time to make a post about using firewall groups for those who haven't used them yet.

Of course there's still a lot of work to be done, such as integrating groups into NAT, which likely does require a complete rewrite to be feasible.

The concept is simple enough: instead of creating multiple rules that only differ in one address or port number, you create a group with all those addresses and ports, and reference it in a rule.

VyOS has three group types: address groups, network groups, and port groups. In 1.1.8 they can only be used with IPv4 firewall rulesets, including "policy route" rules.

Let's create some groups:

set firewall group port-group ManagementPorts port 22
set firewall group port-group ManagementPorts port 23
set firewall group port-group ManagementPorts port 443

set firewall group address-group Servers address 10.10.0.10
set firewall group address-group Servers address 10.10.0.15
set firewall group address-group Servers address 10.10.0.20

set firewall group network-group TrustedNets network 192.168.5.0/24
set firewall group network-group TrustedNets network 172.18.19.128/25
set firewall group network-group TrustedNets network 10.20.30.144/32

Now we can create a ruleset that uses them. Let's make a rule that references nothing but groups:

set firewall name DMZ-In rule 10 action accept

set firewall name DMZ-In rule 10 protocol tcp

set firewall name DMZ-In rule 10 source group network-group TrustedNets

set firewall name DMZ-In rule 10 destination group port-group ManagementPorts

set firewall name DMZ-In rule 10 destination group address-group Servers

An important part is that you can modify groups on the fly without updating any rules.

As you can see, groups is a simple concept that can be learnt in minutes. Once they are in IPv6 and NAT, their use will be very similar.

Using the "policy route" and packet marking for custom QoS matches

daniil@sentrium.io (Daniil Baturin) — Fri, 02 Mar 2018 03:14:44 GMT

There is only that much you can do in a QoS rules to describe the traffic you want it to match. There's DCP, source/destination, and protocol, and that's enough to cover most of the use cases. Most, but not all. Fortunately, they can also match packet marks and that's what enables creating custom matches.

Packet marks are numeric values set by Netfilter rules that are local to the router and can be used as match criteria in other Netfilter rules and many other components of the Linux kernel (ip, tc, and so on).

Suppose you have a few phones in the office and you want to prioritize their VoIP traffic. You could create a QoS match for each of them, but it's quite some config duplication, which will only get worse when you add more phones. If you find a way to group those addresses in one match, wouldn't it be nice? Sadly, there's no such option in QoS. Firewall can use address groups though, so we can make the QoS rule match a packet mark (e.g. 100) and set that mark to traffic from the phones.

# show traffic-policy

 priority-queue VoIP {

     class 7 {

         match SIP {

             mark 100

         }

         queue-type drop-tail

     }

     default {

         queue-type fair-queue

     }

 }

Now the confusing bit. Where do we set the mark? Around Vyatta 6.5, an unfortunate design decision was made: "firewall modify" was moved under overly narrow and not so obvious "policy route". Sadly we are stuck with it for the time being because it's not so easy to automatically convert the syntax for upgrades. But, its odd name notwithstanding, it still does the job.

Let's create an address group and a "policy route" instance that sets the mark 100:

# show firewall group

 address-group Phones {

     address 10.4.5.10

     address 10.4.5.11

     address 10.4.5.12

 }

[edit]

# show policy route

 route VoIP {

     rule 10 {

         set {

             mark 100

         }

         source {

             group {

                 address-group Phones

             }

         }

     }

 }

Now we need to assign the QoS ruleset to our WAN and the "policy route" instance to our LAN interface:

set interfaces ethernet eth0 policy route VoIP

set interfaces ethernet eth1 traffic-policy out VoIP

You can as well take advantage of "policy route" ruleset options for time-based filtering or matching related connections. Besides, you can use it to set DSCP values in case your QoS setup is on a different router:

set policy route Foo rule 10 set dscp 46