Software-Based Routing with VyOS

A modern business’ stability and efficiency depend largely on the continuous operation of its IT infrastructure. Unfortunately, maintenance and operating expenses can be quite high, especially for small and medium-sized businesses.

To cut costs, many companies are now looking to IT outsourcing: instead of purchasing their own equipment, companies rent from a data center and hire professionals to maintain it.
For this to be beneficial from an organizational and financial standpoint, the technical side of things needs to be thoroughly thought out.

When transferring part of an IT infrastructure to a data center, it’s important to decide how all of the resources will connect to a single network. Solutions offered by the leading manufacturers (Juniper, Cisco, etc.) are often too pricey for small and medium-sized businesses. Keeping this in mind, it’s no surprise that there has been a growing interest in free open-source products. In terms of functionality, most of these work the same as their for-pay counterparts, if not better.

A key member of the corporate network is the router–a special network device that connects network elements together and exchanges packets between them. Routers can be both hardware and software-based. When trying to build an IT infrastructure while minimizing expenditures, a software-based router may be the best option.

In this article, we’ll be looking at the VyOS router, which is distributed under free license, and how it can be used to solve some real-life tasks.

VyOS: General Information

VyOS is a fork of the now defunct Vyatta network OS (now owned by Brocade). It was first released in December 2013 under the codename Hydrogen.

Its latest major release, Helium, was published in September 2014. The VyOS command line interface (CLI) is similar to the CLI for Juniper Networks devices.

VyOS has many different features, including:

IPv4 and IPv6 firewalls with p2p traffic filtering;

network address translation (NAT);

IPv4 and IPv6 DHCP servers;

an intrusion detection system;

load balancing and backup channels;

secondary routing with connection status table synchronization;

VPN (IPsec, L2TP/IPsec, PPTP, OpenVPN);

traffic analysis (NetFlow and sFlow);

web proxy and URL filtering.

Like Vyatta, VyOS is built on Debian. This lets us add functions by installing additional deb packages.

Installation

For detailed instructions, look here. VyOS has two installation methods: install system and install image. The first option (install system) just installs the operating system onto a disk. When you choose install image, every version of VyOS gets saved to a separate directory, letting you rollback to a previous version if any issues arise (this is the recommended installation method).

So, we boot from our disk, log into the system (login – vyos, password – vyos), and run the install image command. During the installation, we’ll need to answer the standard Linux installation questions. Once the installation is complete, we run reboot, and again start up the system and log onto VyOS with the login and password we set during installation.

Practical Example

We’ll look at VyOS’ features by running some practical examples. The scenario: an organization is made up of three geographically distributed branches: one in Moscow, one in St. Petersburg, and the third in Habarovsk. They have four servers in a data center in St. Petersburg. Our task: allow only one server to connect directly to the Internet; the others should be connected to a local network and access the Internet through the router. Each of our branches will be using a different connection type: L2TP/IPsec, PPTP, and OpenVPN.

Our network will look like this:

Configuring Nodes

Even though we’ve already installed VyOS, we still don’t have a network, so we’ll start by configuring one in the KVM console.

We configure the first network interface (external) to have the address 95.213.170.75. Then, we enter configuration mode by entering the command configure.

Here, we’ve assigned interface eth0 an IP address and a description to avoid confusion later on.

Then we set the default gateway address and DNS address:

set system gateway-address 95.213.170.73
set system name-server 188.93.16.19

We’ve entered the address for the Selectel DNS in St. Petersburg, but any will do.
Next, we configure our SSH service, which we’ll later use for configuring future nodes:

set service ssh port "22"

The logic behind VyOS is almost the same as with Juniper Networks devices: before any changes come into effect, the commit command has to be executed. For changes to stay in effect after rebooting, we have to run the save command. This is where the VyOS command logic differs from JunOS: in Juniper’s network OS, changes don’t have to be saved after running commit.

We connect to our router via SSH then log onto the system by entering the login and password we set during installation. Once we’ve logged on, we configure the internal network interface eth1. This is the local network interface that the servers in the data center connect to. We assign it the address 10.0.10.1 with netmask /24 and add a description:

If we want our machine to recognize network resource names, we have to configure the DNS. We can configure a DNS forwarder, which will forward requests to the name resolution assigned in the configuration. Configuring this component is fairly simple:

set service dns forwarding cache-size "0"
set service dns forwarding listen-on "eth1"
set service dns forwarding name-server "188.93.16.19"
set service dns forwarding name-server "188.93.17.19"

In the first command, we set the cache size of the DNS forwarder for saving records. Since there’s really no point for us to save any DNS records, we set this to zero. The second command sets the interface the DNS forwarder will listen on. We’ve entered an internal interface so that our DNS forwarder won’t be accessible to the whole Internet. The third and fourth commands establish which addresses requests will be forwarded to. Our example uses Selectel’s DNS, but again, you can set any servers you want.

All of the components we need for our local network are ready to go. Now we configure the firewall.

In VyOS, we can use firewall rulesets and assign them names. In our example, we use a set of rules called OUTSIDE for our external network and INSIDE for our internal network.

We want to permit all connections “from the inside out” for our external interface, and for our internal interface, all connections “from the inside out” and SSH access.

set firewall name OUTSIDE default-action "drop"
set firewall name OUTSIDE rule 1 action "accept"
set firewall name OUTSIDE rule 1 state established "enable"
set firewall name OUTSIDE rule 1 state related "enable"

These commands allow all pre-established and related connections.

Then we set the INSIDE firewall rules:

View Rules

set firewall name INSIDE default-action 'drop'
set firewall name INSIDE rule 1 action 'accept'
set firewall name INSIDE rule 1 state established 'enable'
set firewall name INSIDE rule 1 state related 'enable'
set firewall name INSIDE rule 2 action 'accept'
set firewall name INSIDE rule 2 icmp type-name 'echo-request'
set firewall name INSIDE rule 2 protocol 'icmp'
set firewall name INSIDE rule 2 state new 'enable'
set firewall name INSIDE rule 3 action 'drop'
set firewall name INSIDE rule 3 destination port '22'
set firewall name INSIDE rule 3 protocol 'tcp'
set firewall name INSIDE rule 3 recent count '4'
set firewall name INSIDE rule 3 recent time '60'
set firewall name INSIDE rule 3 state new 'enable'
set firewall name INSIDE rule 31 action 'accept'
set firewall name INSIDE rule 31 destination port '22'
set firewall name INSIDE rule 31 protocol 'tcp'
set firewall name INSIDE rule 31 state new 'enable'

In the first line, we assign the default action; here, it’s “drop” (the firewall will drop all packets that fall outside any of our rules). The first rule mimics the rules we wrote for the external interface. The second rule allows all ICMP packets; this is needed for pinging the router if anything goes wrong. The third rule is responsible for SSH connections: we’re only allowing TCP traffic from port 22.

Now we apply these new rules to the appropriate interfaces:

set interfaces ethernet eth0 firewall in name 'OUTSIDE'
set interfaces ethernet eth1 firewall out name 'INSIDE'

Take a look at the in and out parameters. These describe traffic relative to the router, either incoming or outgoing, and are in no way related to the names of the firewall rulesets.

We won’t forget to apply and save our configuration using the commit and save commands.

Configuring a VPN

As we’ve already said, our branches will be using different kinds of VPN connections. We’ll start by configuring L2TP/IPSec (for more information, see here):

In the first three commands we configure IPSec: we define the interface where packets will be sent, we enable NAT traversal, and allow NAT for all networks. The next commands are for L2TP. It’s fairly obvious what they’re responsible for, so we’ll just take a look at a few parameters:

outside-address: sets the VPN server’s external address;

pre-shared-secret: sets the password which will later be used when configuring the VPN on client devices;

authentication mode local: sets the authentication type. Our example uses a local database for authentication, but a RADIUS server can also be used for centrally managing user accounts.

In the last line, we create a user and define their password. Afterwards, we add some rules to the firewall to allow L2TP/IPSec traffic.

Now let’s look at configuring our second VPN connection and set up an OpenVPN server. We start by copying the easy-rsa files to the directory /config/easy-rsa2 to avoid losing them when updating the system:

The generated files are necessary for connecting clients to the server, which means they will have to be transferred to the client’s side. This can be done using any SCP client: WinSCP for Windows or the standard console client scp for Linux.

Take a look at the last command: we forward name resolution requests to the DNS forwarder that we configured earlier. We’d also like to point out that with OpenVPN, we first used a separate network for building the actual tunnel, and then routed it to the local network with our servers. This is due to the nature of the protocol. We’ll write more detailed information on this in a future article.

Configuring a PPTP Server

Now we’ll configure the last of our VPN connections–PPTP. Of course, PPTP is not very secure and thus not often used for transferring confidential information; however, it has many applications for providing remote access. Practically every device with a network connection has a PPTP client.

From our example, we can see that PPTP is configured almost the same way as L2TP:

set vpn pptp remote-access authentication mode local
set vpn pptp remote-access authentication local-users username password
set vpn pptp remote-access client-ip-pool start 10.0.10.31
set vpn pptp remote-access client-ip-pool stop 10.0.10.40
set vpn pptp remote-access dns-server server-1 188.93.17.19
set vpn pptp remote-access outside-address 95.213.170.75
In the first command, we set user authentication mode to local. If you have a RADIUS server, you can choose radius authentication mode, which can be used to manage user accounts much more comfortably.
Then we create local users and set an IP address range and DNS data for clients. The last command sets the address of the interface our server will listen on.
Then we apply and save the configuration:

commit
save

The server is now ready for clients.

All that’s left is to let traffic from the local network out. This is how Internet access is provided to servers in the local network and to users connected to our router from the branches:

Conclusion

Now we’re ready: we’ve built a network to accomplish our task with the given conditions. One of the servers (located in St. Petersburg) acts as a router, the others are connected to it via a local network. The branches’ routers can access local network resources over a secure VPN connection.

In this brief overview, we described only the basics of building a small corporate network. In future articles, we’ll talk more in depth about VyOS’ capabilities and teach you how to more flexibly configure a firewall and port forwarding, allow traffic from protocols commonly used in corporate networks, and also look at the following topics:

Today we’re going to look at how we can build a ready-made infrastructure from a virtual device using the OpenStack orchestration module, Heat.
Heat requires the python-heat package, which is included in the repositories of most Linux systems. It can be installed from the PyPI repository using the PIP utility. Installation instructions can be found under...

Workloads need to be assessed and addressed when a project is first being development. This is the best way to avoid dropped servers and ensuing losses, both reputational and material. Even though we can increase a server’s power and optimize its algorithms and code to accommodate growing loads, sooner or later, these methods just won’t...