VyOS 1.2.5 maintenance release
Posted 14 Apr, 2020 by Yuriy Andamasov
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
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!
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.
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”).
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|
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!
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
or you also can Buy us a coffee and donut
Big thanks from VyOS team and state safe!