VyOS 1.4.0 LTS releases: network operating system

by Nam Phong · April 15, 2020

VyOS is forked from the Vyatta community, is a network operating system that provides software-based network routing, firewall, and VPN functionality. VyOS is based on Debian GNU/Linux and is fully open source free. VyOS can run on physical devices and virtual platforms, supporting integration packages for para-virtual drives and virtual platforms.

Feature

VLANs:

802.1q and QinQ

Static and dynamic routing:

BGP for IPv4 and IPv6, OSPFv2, RIP, RIPng, policy-based routing, equal-cost multi-path

Firewall:

Firewall rulesets for IPv4 and IPv6 traffic you can assign to interfaces, zone-based firewall, address/network/port groups for IPv4 firewalls

Tunnel interfaces:

PPPoE, GRE, IPIP, SIT, static L2TPv3, VXLAN

VPN:

Site-to-site IPsec for IPv4 and IPv6, L2TP/IPsec server, PPTP server, OpenVPN for site-to-site and remote access

NAT:

Source NAT, port forwards, one to one, one to many, and many to many translations

DHCP:

DHCP and DHCPv6 server and relay

Redundancy:

VRRP, connection table synchronization

Flow accounting:

NetFlow and sFlow

Proxy:

Web proxy and URL filtering

Shaping:

QoS policies (drop tail, fair-queue, and others), traffic redirection.

Changelog 1.4.0 LTS

Redesigned features

Some features still offer the same functionality and many improvements, but their CLI is now very different from older versions. One of them if the firewall configuration subsystem.

Firewall

Ever since the first days of VyOS, firewalls have been a complicated subject for us. Before the fork, the original authors of the Vyatta CLI decided to mimic the access list CLI of Cisco IOS — maybe because many of them worked at Cisco before, maybe because they thought it would be a familiar CLI for network admins who grew up with Cisco IOS and products that took inspiration from it.

The main principle of that firewall CLI was that users define rulesets and assign them to network interfaces in particular directions (in, out, or local).

There were multiple issues with that approach. First, the limitation that a firewall rule could not apply to multiple network interfaces was completely artificial — Linux firewalls never had that limitation ever since the earliest days. The usual practice for firewall configuration on bare Linux was always to make rules centered on services and traffic directions so that they could apply to any network card layout.

Second, it made exposing more functionality of the Linux firewall (currently, NFTables) a lot more difficult. For example, transparent firewalls don’t fit that paradigm at all.

To unblock the path forward, we had to eliminate the interface-based CLI and redesign it completely. That was a daunting task that required a lot of coding and testing, but finally, we were there.

More…

Download

Support Our Threat Intelligence

If you find our technology report and cybersecurity news helpful, consider supporting our work.

Buy Me a Coffee PayPal