The winter break is over and the first month of the new year has passed. As usual, we’ve been busy with improving VyOS and its infrastructure. The main highlights of this month include a new website specially for community members and contributors available at vyos.net, introduction of monthly snapshots (finally!), and quite a few development updates.
Latest research by Armis shows that the h.323 conntrack/NAT helper allows bypassing the firewall and connecting directly to any device inside the network. The attack was nicknamed “NAT slipstreaming 2.0”.
We are grateful to Armis for testing VyOS specifically. Indeed, VyOS has all conntrack modules enabled by default as of now. The reason for it is that it was an important compatibility concern for many users, while an exploitable vulnerability wasn’t demonstrated until recently.
For now, you can mitigate the issue with set system conntrack modules h323 disable
Since an attack does exist now, we’ll need to reconsider the default behavior in future releases. The preliminary plan is to flip the syntax to allow enabling individual modules, and write a migration script that enables them if they weren’t disabled in old configs.
We have deprecated the old wiki long ago, but it has remained online, in a state of decay. By now, the information contained in it is mostly outdated and irrelevant. The wiki workflow never took off, it was mostly edited by maintainers and a few contributors, and it had really awful spam problems. Replacing it with a new git-based workflow, Sphinx, and readthedocs.org created an active documentation project with more contributors than the wiki ever had.
Now it’s time to retire the wiki host. Its content well-reserved in the Wayback Machine, so there is no irrecoverable information loss. Before shutting the wiki down, we’ve compiled a list of the most popular pages and set up redirects to appropriate sections of the new documentation.
The main page of the wiki itself will now redirect to the new community website. Which community website? Read on.
We are fully aware that the current vyos.io website isn’t really good for either community members or commercial users. It’s a mix of information that is only useful for one category of people or the other, not very well-structured and not always well-presented. It’s not the worst website around, but it could be a lot better.
Our decision was to start with splitting it into two websites: one for community members and contributors, the other for commercial users. The new community website is now live and available at vyos.net while (vyos.io will be a website for commercial services, following a common .org/.com separation pattern).
First of all, it’s fully static (no backend) and very fast. Right now it’s hosted on Netlify, but since it’s static, it will be very easy to re-host it somewhere else if we aren’t happy with Netlify.
More importantly, its source is in a git repository at github.com/vyos/community.vyos.net. Thus, if you find any typos or confusing wording, or want to add something, you can make a pull request on GitHub.
There are still some stub pages, and may still be issues with broken links, but it’s a start and we hope it will become a good information hub for the community.
Monthly snapshots are here
One reason we didn’t roll out the new community website sooner is that we wanted some other things to fall into place first. One of those things is long-promised monthly snapshots. Snapshot build procedure wasn’t very easy to get right, but there was also a question where to store them so that people can find them. The new community website is a logical place for that.
The Get VyOS page there is now a one-stop shop for all downloads including nightly builds and snapshots. There’s also information about contributor subscriptions and how to apply to them.
The snapshots specifically have their own page. Snapshots are available as a generic ISO, VMware OVA, KVM qcow2 images, and a Hyper-V .vhdx Their goal is to provide a middle ground between “completely unstable” nightly builds and “completely stable” LTS releases. They include experimental features, but they are tested not to be horribly broken.
Right, the current branch is now what will become the 1.4/sagitta release in the future. That means time for risky changes has come, now that the upcoming 1.3/equuleus LTS release is branched off and safe from changes we are making in current.
First, the kernel got updated to 5.10.10, and the linux-firmware package was also updated to a very recent version. We’ve also updated the Intel QAT driver to 1.7.l.4.12 from 1.7.l.4.09. However, Intel NICs drivers received a different kind of an update—we are back to using the in-kernel, upstream driver rather than Intel’s official tarball. The performance and code quality of the in-tree drivers is better now, so we hope it will stay this way, since it makes build procedures much simpler. This mirrors a story with Mellanox drivers that also went from in-kernel version to official Mellanox tarballs and back.
Routing protocol CLI is also seeing some big changes. The BGP and RPKI CLI are now in the new XML+Python style. OSPF and OSPFv3 also got rewritten in the new style. Compared to the legacy node.def+Perl, that’s a lot easier to maintain and extend.
Substantial parts of the operational mode are also getting rewritten in the new style. Past year we hit the 50% legacy code target, and we hope this year we can eliminate most if not all of it.
We are also glad to see people from the community help us a lot. Thanks to our contributor Cheeze-It, we now have IS-IS segment routing and dynamic BGP neighbors. Thanks to jack9603301, we’ve got an initial implementation of NAT66 and improved support for VLAN-aware bridges. Brandon Stepler made improvements to the DHCP-PD.
Our smoketest infrastructure is also improving, and everyone is welcome to join that work!
At the same time, we are working on stabilizing the 1.3/equuleus branch to make it a new LTS. We are planning to support the 1.2/crux LTS until at least 2022, but the support will be limited to bug fixes and security updates only, so all new development will be going to 1.3 and 1.4.
Stabilization is going to take quite a bit of time, so better start early. We are planning to build the first EPA images in February, and we’ve also kept equuleus nightly builds for those who want to test them. All active testers will be eligible for contributor subscriptions and badges, so there’s some motivation to help us, we hope!
We are planning to support ARM64 AWS instances. If that works well, that will be the first step to support bare-metal ARM64 platforms. Starting from virtual machines is easier since there are no hardware variations and no drivers and device tree issues.
And the GUI time is coming… stay tuned for updates!