VyOS Platform Blog

VyOS 1.2.5 maintenance release

Written by Yuriy Andamasov | April 14, 2020 8:04:25 PM Z

VyOS 1.2.5 maintenance release is finally available. Subscribers can download it from the support portal, and everyone can build it from the Crux branch and cloud images currently under marketplace reviews. It’s a rather big release, with 46 resolved issues.

As always, we are very grateful to everyone who sent us patches, reported bugs and supported us financially. Without you, the continued development of VyOS wouldn’t be possible! Thank you!

This release took longer than expected for a few reasons. Big changeset, we wanted to test all more time to make sure all works as expected. We also wanted to backport as much from the development branch as we could. End of support for 1.2.x will not come sooner than 2021, but starting with 1.2.6, we’ll focus on bug fixes and security updates. Big improvements we are making in the future 1.3.x branch demands big internal changes, so we want to focus on stabilizing it and making a stable 1.3.0 release by the end of 2020.

Verifying release images

Historically, we’ve used GnuPG for image signing, like most other projects. GPG signature verification is built into the image upgrade process, so an upgrade is secure by default. However, for initial installation, GnuPG makes the process harder than it should be since you need to locate and import our release key first.

Starting from this release, we are signing images with minisign. For an introduction, you should read signify: Securing OpenBSD From Us To You. The cool thing about minisign is that its keys are small enough to specify as command line options, so there's no need for key import. Thanks to elliptic curve cryptography algorithms, they are no less secure despite much smaller size.

So apart from the usual .asc file there’s also a .minisgn file stored next to every image.

You can verify signatures using this command:

minisign -VP RWTR1ty93Oyontk6caB9WqmiQC4fgeyd/ejgRxCRGd2MQej7nqebHneP -m ./vyos-1.2.5-amd64.iso

Security

This release fixes a vulnerability in accel-ppp that allows a malicious user to crash the PPPoE process with a specially crafted discovery packet. We urge everyone who uses the PPPoE server in VyOS to upgrade.

There is no CVE number for this vulnerability and we are working with the upstream developers of accel-ppp to register and disclose it properly, so we cannot provide details or a proof of concept since it will put people using mainline accel-ppp at risk. Stay tuned for updates!

Syntax changes

Originally, we had a global enforce-first-as command in BGP: “set protocols bgp <ASN> enforce-first-as”. Starting from FRR 7.3, there is no global command anymore and no fallback to the old behavior. Thus, the new syntax is “set protocols bgp <ASN> neighbor <address> enforce-first-as”.

While it’s an improvement, it’s also an incompatible change, and we make a commitment to keeping behavior unchanged between point releases. Thus, if you’ve had the global “enforce-first-as” option set, a migration script will insert that option into each of your neighbors, so your config will work as before.

PPPoE improvements

Apart from fixed vulnerability in the PPPoE server, we’ve made a bunch of fixes in the PPPoE client. For example, the “default-route force” option now works correctly in the PPPoE client.

It will also keep trying to reconnect indefinitely rather than give up after 10 attempts, which is useful for unattended installations. 

VyOS will also detect and prevent creation of PPPoE interfaces with the same number under multiple ethernet interfaces (in the future we’ll move it out of ethernet into “set interfaces pppoe pppoeX”).

Scripting improvements

SNMP scripts is a little known feature, but it exists, and now it’s better than it was. We’ve fixed some issues with script file name checking, and an issue with script executable bit erroneously removed.

There are new features in VRRP as well. First, there's now set high-availability vrrp group MyGroup transition-script mode-force option. This option makes VyOS always run transition scripts when the VRRP process is restarted (e.g. with "run restart vrrp"). The default behaviour it to run scripts only if a state transition happens "for real", that is, when an interface goes down or health check script fails. From our experience, most people prefer the default behaviour, but now you can opt out of it.

There's also a new type of transition scripts called "stop". They are executed when the VRRP service is shutdown.

Full list of resolved issues

1020 OSPF Stops distributing default route after a while
1228 pppoe default-route force option not working (Rel 1.2.0-rc11)
1301 bgp peer-groups don't work when "no-ipv4-unicast" is enabled.
1341 Adding rate-limiter for pppoe server users
1376 Incorrect DHCP lease counting
1392 Large firewall rulesets cause the system to lose configuration and crash at startup
1416 2 dhcp server run in failover mode can't sync hostname with each other
1452 accel-pppoe - add vendor option to shaper
1490 BGP configuration (is lost|not applied) when updating 1.1.8 -> 1.2.1
1780 Adding ipsec ike closeaction
1803 Unbind NTP while it's not requested...
1821 "authentication mode radius" has no effect for PPPoE server
1827 Increase default gc_thresh
1828 Missing completion helper for "set system syslog host 192.0.2.1 facility all protocol"
1832 radvd adding feature DNSSL branch.example.com example.com to existing package
1837 PPPoE unrecognized option 'replacedefaultroute'
1851 wireguard - changing the pubkey on an existing peer seems to destroy the running config.
1858 l2tp: Delete depricated outside-nexthop and add gateway-address
1864 Lower IPSec DPD timeout lower limit from 10s -> 2s
1879 Extend Dynamic DNS XML definition value help strings and validators
1881 Execute permissions are removed from custom SNMP scripts at commit time
1884 Keeping VRRP transition-script native behaviour and adding stop-script
1891 Router announcements broken on boot
1900 Enable SNMP for VRRP.
1902 Add redistribute non main table in bgp
1909 Incorrect behaviour of static routes with overlapping networks
1913 "system ipv6 blacklist" command has no effect
1914 IPv6 multipath hash policy does not apply
1917 Update WireGuard to Debian release 0.0.20191219-1
1934 Change default hostname when deploy from OVA without params.
1935 NIC identification and usage problem in Hyper-V environments
1936 pppoe-server CLI control features
1964 SNMP Script-extensions allows names with spaces, but commit fails
1967 BGP parameter "enforce-first-as" does not work anymore
1970 Correct adding interfaces on boot
1971 Missing modules in initrd.img for PXE boot
1998 Update FRR to 7.3
2001 Error when router reboot
2032 Monitor bandwidth bits
2059 Set source-validation on bond vif don't work
2066 PPPoE interface can be created multiple times - last wins
2069 PPPoE-client does not works with service-name option
2077 ISO build from crux branch is failing
2079 Update Linux Kernel to v4.19.106
2087 Add maxfail 0 option to pppoe configuration.
2100 BGP route adverisement wih checks rib
2120 "reset vpn ipsec-peer" doesn't work with named peers
2197 Cant add vif-s interface into a bridge
2228 WireGuard does not allow ports < 1024 to be used
2252 HTTP API add system image can return '504 Gateway Time-out'
2272 Set system flow-accounting disable-imt has syntax error
2276 PPPoE server vulnerability

 

What’s next?

We will make a 1.2.6 release when we collect enough fixes and package updates to make. Debian Jessie support ends in July 2020, but it shouldn’t be a big concern for you. We build many important packages from source anyway, and we successfully maintained the Squeeze-based VyOS 1.1.x years past the official support for Squeeze ended. It’s not always easy, but we made a stability promise for LTS releases and we are going to keep it. As you may recall, we ourselves using VyOS so it’s important to us too.

Meanwhile, the 1.3 development branch is stabilizing, so we encourage everyone to test the rolling release in the lab and in non-critical production roles. It comes with many improvements including initial VRF. Every feedback helps, even if you just load your production config in a lab VM and see if it loads cleanly.

Our offer of free subscription for people who contribute to the code, testing, and documentation remains valid as well!

P.S.

If you use VyOS, please find a moment to review it on TrustPilot by clicking widget below

Yo can support us becoming our patron at Patreon

Become a Patron!

or you also can  Buy us a coffee and donut

 

Big thanks from VyOS team and state safe!