VyOS Networks Blog

Hello, Community! The belated development update for December 2025 and January 2026 is finally here.

We are getting closer to the 1.5 release but there's also quite a bit of work towards the future. In particular, there's good progress towards replacing the old configuration command completion mechanism with a VyConf-based equivalent, which will allow us to get rid of legacy command definition files eventually.

More immediate improvements include certificate-based authentication for OpenConnect, new operational commands for VPP, support for configuring watchdog timers, and multiple bug fixes.

Configuration syntax changes

VyOS no longer supports filtering the import of connected and kernel routes into the RIB (T7664)

We have recently upgraded to FRR 10.5. It offers many features and fixes, and also removes support for assigning route maps for filtering the import of connected and kernel routes into the RIB (set system ip protocol <connected|kernel|table> route-map <name>).

We consider it unlikely that anyone ever found that functionality useful — in fact, interfering with the import of connected and kernel routes sounds like asking for trouble.

If you used that functionality and have a valid use case for it, let us know!

For the time being, those commands are removed because they are not present in FRR.

SSH ciphers option is now cipher (T8098)

We normally use singular nouns for multi-value nodes like address but the cipher option in SSH was an exception. Now it no longer is.

IPsec peer mode respond was renamed to trap (T7594)

Previously, IPsec connection mode names were initiate, respond, and none:

# set vpn ipsec site-to-site peer SomePeer connection-type <TAB>
Possible completions:
   initiate             Bring the connection up immediately
   respond              Wait for the peer to initiate the connection
   none                 Load the connection only

However, those names were misleading and led many people to create problematic configurations.

Internally, that corresponds to StrongSWAN start_action values: initiate to start, respond to trap, and none to none.

The real behavior of StrongSWAN modes is:

• start (initiate in the old VyOS terms) — initiate the IKE dialog with the peer immediately.
• none — wait for IKE traffic from the peer or for a user command, do nothing otherwise.
• trap (respond in the old VyOS terms) — respond to IKE or initiate the IKE dialog when matching traffic is detected.

The trap mode of StrongSWAN doesn't really fit the definition of respond, since respond implies the system will not do anything until the peer sends any IKE packets. Moreover, it's unnecessary in most cases and can create duplicate SAs or connection loops.

That situation is a bit tricky to rectify because there are two types of people: those who used respond because they knew how it behaves and specifically wanted that behavior, and those who were misled by the unfortunate name and assumed that was what they had to use if they wanted VyOS to passively wait for IKE packets.

The ultimate solution is still up for discussion and your input is welcome!

For now, however, we made the minimal change and renamed respond to trap to make it clearer what it does and to match the StrongSWAN terminology.

If trap is what you want, you don't need to do anything — the migration script will take care of it automatically. However, if you want your system to wait until IKE packets come from a peer, you may want to set the connection type to none instead.

New features and improvements

OpenConnect certificate-based authentication

OpenConnect server now supports certificate-based authentication.

An uncommon feature of OpenConnect, compared to other VPN servers, is that it allows you to choose the certificate field that you want to use for identifying users.

That's done using the user-identifier-field option that has two predefined values (cn and uid), but also allows you to specify any OID if you want to.

Example:

set vpn openconnect authentication mode certificate user-identifier-field cn
set vpn openconnect ssl ca-certificate SomeCA
set vpn openconnect ssl certificate SomeServerCert

Support for watchdog configuration (T7101)

VyOS now offers configuration commands for the Systemd watchdog service. Example:

set system watchdog module softdog
set system watchdog reboot-timeout 60
set system watchdog shutdown-timeout 60

Support for link parameters in traffic engineering (T8046)

set protocols traffic-engineering admin-group <name> bit-position <num>
set protocols traffic-engineering interface <intf> admin-group <name>
set protocols traffic-engineering interface <intf> max-bandwidth <num>
set protocols traffic-engineering interface <intf> max-reservable-bandwidth <num>

Other improvements

• VPP now automatically selects the correct NAT44 mode based on the configuration (T7972).
• The maximum value for  num-rx-desc was increased to 16384 (T7876).
• New bridge domain commands for VPP: show vpp bridge-domain [<num> [detail]] (T7203).
• New commands to show LACP information in VPP: show vpp lacp [details] (T7954).
• The output of run generate tech-support archive now includes NUMA topology information (T7134).
• The geoip country-code in firewall has a completion helper now (T8089).
• New local RIB option for BMP: set protocols bgp bmp target FIRST monitor <family> local-rib (T8133).
• Captive portal option for IPv6 RA: set service router-advert interface eth0 captive-portal <URL> (T8140).
• Config encryption setup without TPM now asks the user to confirm the passphrase to prevent typos (T8146).
• IS-IS traffic engineering export command: set protocols isis traffic-engineering export (T8046).
• OpenVPN now supports data-ciphers-fallback in site-to-site tunnels (T7633).
• Support for SSH FIDO2 multi-factor authentication options: set service ssh fido <pin-required|touch-required> (T7483).

Bug fixes

• VPP now checks driver compatibility whenever it's changed, not just when it's set for the first time (T8030).
• VPP no longer produces erroneously duplicated log messages (T8011).
• VPP no longer attempts to override the driver twice, which could lead to errors (T7819).
• VPP now correctly handles all values of buffers page-size (T8082).
• Fixed a bug that led to incorrect mapping of bonding interfaces in VPP IPFIX (T8143).
• Fixed a missing plugin load required for IPv4 DHCP in VPP (T8125).
• Fixed an unhandled exception when trying to run VPP IPFIX commands when VPP is not configured (T8170).
• Fixed a bug that led to incorrect MTU settings in VPP (T7098).
• Fixed an interface state corrupption issue on VPP commit errors (T8080).
• Inaccessible TACACS+ servers no longer make commands hang until server timeout (T8086).
• VyOS no longer incorrectly allows multicast addresses to be manually assigned to interfaces (T8054).
• OpenVPN migration script no longer duplicates certificates on migration from VyOS 1.3 configs to the new integrated PKI (T7738).
• Old-style syslog host:port syntax is always correctly migrated now (T8059).
• The reset connection command works correctly again (T7810).
• run renew dhcpv6 interface <name> now works in all cases when a DHCPv6 client is used on an interfaces, not only when address dhcpv6 is set (T8078).
• Fixed an issue with the 0-to-1 IS-IS migration script (T8094).
• The cipher name cipher rijndael-cbc@lysator.liu.se that is no longer supported by OpenSSH is now correctly migrated to aes256-cbc (T8098).
• VyOS now correctly disallows adding Ethernet interfaces that don't support MAC address changes as bonding members (T8084).
• VyOS no longer always deletes and re-adds bonding interface member in member list changes (T2416).
• Fixed a bug that made NAT66 to be out of sync with firewall groups created later (T8138).
• Config encryption password input is no longer displayed (T8145).
• VyOS no longer incorrectly sets the dynamic prefix assignment mode for transport mode IPsec tunnels (T8022).
• PPPoE interfaces now correctly send IPv6 router solicitation requests when they go up (T8153).
• Fixed an issue with incorrect IS-IS LSP timers (T8158).
• VyOS no longer erroneously allows deleting VRFs that are referenced in policy-based routing (T8169).