VyOS 1.4.0 LTS releases: network operating system

by · Published · Updated

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.

VyOS

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

Tags: