VyOS - Blog

VyOS 1.4.2 release

daniil@sentrium.io (Daniil Baturin) — Thu, 03 Apr 2025 16:28:13 GMT

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!

VyOS Project December 2024 Update

daniil@sentrium.io (Daniil Baturin) — Mon, 30 Dec 2024 15:56:27 GMT

Hello, Community!

The December update is here! The biggest highlight of this month is the 1.4.1 release but there was lots of work in the rolling release as well, both from the maintainers team and from our contributor community. One of the biggest news in the rolling release is that we are ready to update FRR — our routing protocol stack — to the latest 10.2 release. That will allow us to get rid of the legacy OpenNHRP daemon that we use for DMVPN and use FRR's built-in NHRP implementation, among other things.

Apart from that, there are many more bug fixes and improvements made in November and December, especially in QoS, IPoE server, and other areas — read on for details!

VyOS 1.4.1 release

daniil@sentrium.io (Daniil Baturin) — Fri, 20 Dec 2024 16:55:59 GMT

Hello, Community!

VyOS 1.4.1 release is now available to customers and community members with contributor subscriptions. Its source code is available as a tarball upon request to everyone who legitimately received a binary image for us. Fixes for CVE-2023-32728 (Zabbix agent SMART plugin RCE) and CVE-2024-6387 (regreSSHion) that were already available as hotfixes are integrated in the image, and there is a fix for a potential DoS in the HTTP API caused by a vulnerability in the python-multipart library (CVE-2024-53981). This release also includes multiple bug fixes and a few improvements, including support for Base64-encoded IPsec secrets, VXLAN VNI to VLAN range mappings, reject routes, and more — read on for details!

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