VyOS - Blog

VyOS Project May 2026 Update

daniil@sentrium.io (Daniil Baturin) — Fri, 29 May 2026 10:45:00 GMT

Hello, Community!

The May development update is here. Despite the fact that we had to deal with a downpour of vulnerabilities such as Copy Fail, Dirty Frag, and others (they are all fixed in rolling and in emergency LTS release updates available to subscription holders now!), the VyOS team and community members still added quite a lot of new features and bug fixes this month.

They include a fix for the long-standing, very annoying bug that led to needless OpenVPN server restarts on config changes that only affected user settings that go to the client config dir, multiple new options for DHCPv4 and DHCPv6 servers, initial support for traffic engineering in segment routing, and more.

VyOS 1.5.0 GA release

daniil@sentrium.io (Daniil Baturin) — Tue, 31 Mar 2026 00:30:00 GMT

Hello, Community!

VyOS 1.5.0 LTS release is now finalized and its CLI is frozen for any non-compatible changes. Right now subscribers can already download the generic ISO and other on-premises flavors for x86-64 systems. 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.

Its development started in 2024 and followed the usual two-year LTS release cycle. In those two years we introduced multiple big features including a long-awaited accelerated dataplane and a huge amount of bug fixes.

Download the full release notes

VyOS Project September 2024 Update

daniil@sentrium.io (Daniil Baturin) — Sun, 22 Sep 2024 21:42:55 GMT

Hello, Community!

Summer is over now, and many people are returning to their routines. Check out what we've done in the last month of the summer: that includes a few small config syntax changes, multiple improvements in OpenVPN, an API endpoint for importing PKI objects, and a whole bunch of bug fixes!

What's coming for OpenVPN in VyOS 1.4?

daniil@sentrium.io (Daniil Baturin) — Tue, 26 Sep 2023 13:00:00 GMT

Hello, Community!

OpenVPN is one of the oldest open-source VPN protocols and implementations. It took the world by storm in the early 2000s because it was a huge improvement over VPN solutions of the time: PPTP that used a patent-encumbered cipher with questionable security; IPsec or L2TP/IPsec, which was hard to set up and very unfriendly to NATed and poorly configured networks; and a variety of proprietary SSL VPNs. OpenVPN was trivial to set up on the client — give it a single config file, and you are done, and it was open-source and available for all popular OSes.

VyOS Project September 2023 Update

e.altunbas@vyos.io (Erkin Batu Altunbas) — Thu, 14 Sep 2023 18:43:26 GMT

Hello, community!

We're back with an end-of-summer update. We've been quite busy cleaning up legacy code, fixing bugs, and adding remaining features planned for the future 1.4.0 (Sagitta) LTS release that we hope to finish by 2024. Soon, we'll create a sagitta branch in our git repositories to stabilize the codebase that will become the new 1.4.0 LTS release. Rolling release development will continue in the current branch, and the future 1.5 LTS release will be "Circinus". Meanwhile, the minor release 1.3.4 of the Equuleus branch is in its final stages, and we'll soon build and release its images. Here's what's happened in August.

CVE-2022-0778: remote DoS in OpenSSL, VyOS 1.3.0 is affected

daniil@sentrium.io (Daniil Baturin) — Wed, 16 Mar 2022 20:22:41 GMT

Hello Community!

Yesterday the OpenSSL team disclosed a remote DoS vulnerability in OpenSSL versions 1.0.2, 1.1.1, and 3.0. You can find a complete description here in their CVE-202200778 report. In short, any remote attacker can cause an infinite loop in OpenSSL by attempting to establish a TLS connection with a specially crafted malformed certificate, and cause a denial of service.

Take a third option: site to site OpenVPN

daniil@sentrium.io (Daniil Baturin) — Fri, 30 Mar 2018 10:38:22 GMT

I've written a long series of post about setting up IPsec VPNs between NATed machines. As you've already seen, with some creative configuration it's possible, but is it always worth the sacrifice? Sometimes performance requirements, or lack of support for anything else on the other side make it necessary, but if the other side is also a VyOS, or another open source system, there's an alternative.

While OpenVPN is usually associated with road warrior VPN setups, it is not limited to it. It does have a site to site option and it's very quick and easy to setup. For some strange reason, that option is neglected by just about everyone who otherwise supports OpenVPN: in OpenWRT it's possible to setup through custom config options, while in Mikrotik RouterOS it's not possible to setup at all. In VyOS we have an explicit option for it. OPNsense also supports site to site OpenVPN out of the box (I thought it doesn't, but the authors corrected me).

The advantages are that it takes very few commands to get a tunnel to work, and that it will work in any network where you can forward a single port, even is both sides are behind double NAT. The downside is performance: squeezing even 100mbit/s of encrypted traffic out of it can be impossible, typical iperf figures are 10-20 mbit/s. For many use cases that performance is more than enough, though if you plan to use the tunnel for storage replication or another high-traffic job, that option is definitely not for you and you'll have to resort to IPsec.

Setting up site to site OpenVPN

Generating a key

OpenVPN in site to site mode supports either static pre-shared keys or x.509. For a quick tunnel setup between your own routers, the format option is a lot easier and arguably not less secure. Unlike most IPsec implementations, OpenVPN stores pre-shared keys in files, and uses keys of considerable length (default is 2038. It takes just one command to generate a suitable key:

run generate openvpn key /config/auth/mysite.key

Then you can copy the file to the remote side via SCP or something else. That command is a wrapper for "openvpn --genkey --secret" in case you want to generate a key outside VyOS. It's a good idea to store the keys in /config/auth directory that was specifically meant for authentication data, since /config will be migrated to the new image when you upgrade your system — if you put them in /etc, they will be inaccessible from the upgraded image.

Setting up the tunnel

It's quite straightforward.

Local (listening) side:

set interfaces openvpn vtun10 mode site-to-site

set interfaces openvpn vtun10 description 'My remote site'

set interfaces openvpn vtun10 local-host 203.0.113.50 # Listen address

set interfaces openvpn vtun10 local-address 192.168.34.1 # Tunnel address

set interfaces openvpn vtun10 local-port 8000 # Port to listen on

set interfaces openvpn vtun10 protocol udp # Can be TCP but TCP is slower

set interfaces openvpn vtun10 remote-address 192.168.34.2 # Tunnel peer address

set interfaces openvpn vtun10 shared-secret-key-file /config/auth/mysite.key # The file you generated

Remote (connecting) side:

set interfaces openvpn vtun10 mode site-to-site

set interfaces openvpn vtun10 remote-host 203.0.113.50 # Remote router external address

set interfaces openvpn vtun10 local-address 192.168.34.2 # Tunnel address, don't forget to local/remote addresses for the remote side!

set interfaces openvpn vtun10 remote-port 8000 # Port to connect on

set interfaces openvpn vtun10 protocol udp # Can be TCP but TCP is slower

set interfaces openvpn vtun10 remote-address 192.168.34.1

set interfaces openvpn vtun10 shared-secret-key-file /config/auth/mysite.key

As you can see, with less than 10 commands on each side, you can get a tunnel working.

What about x.509?

It is doable, though I'm not sure if it's really worth the trouble for site to site tunnels.

This is how it's done. Local (listening) side:

set interfaces openvpn vtun10 tls role passive

set interfaces openvpn vtun10 tls dh-file /config/auth/dh2048.pem

set interfaces openvpn vtun10 tls ca-cert-file /config/auth/ca.crt

set interfaces openvpn vtun10 tls cert-file /config/auth/local.crt

set interfaces openvpn vtun10 tls key-file /config/auth/local.key

Remote (connecting) side:

set interfaces openvpn vtun10 tls role active

set interfaces openvpn vtun10 tls ca-cert-file /config/auth/ca.crt

set interfaces openvpn vtun10 tls cert-file /config/auth/remote.crt

set interfaces openvpn vtun10 tls key-file /config/auth/remote.key

Routing

Since OpenVPN tunnels look like normal network interfaces, you can setup routing right away as if they were physical links. You can also use push-route commands through custom options (as in, openvpn-option "push ..."). Note that OpenVPN in site to site mode doesn't install any routes by default so you need to take care of it yourself.

Keeping OpenVPN config and certs/keys in one file

daniil@sentrium.io (Daniil Baturin) — Fri, 20 Jun 2014 04:27:00 GMT

OpenVPN client setup requires multiple files apart from the config: CA, client certificate, and client key, in case of certificate authentication. With login/password authentication it’s not just one file either, you still need a CA.