Software routing with VyOS

The stability and efficiency of business processes of a modern organization largely depends on the smooth functioning of the IT infrastructure. The maintenance of IT infrastructure in many cases is expensive, especially for small and medium-sized companies.

In order to optimize costs, many organizations today resort to the practice of IT outsourcing: instead of purchasing equipment, the company rents it in a third-party data center, and attracts third-party specialists to service it.
In order for this practice to be profitable from an organizational and financial point of view, you need to carefully consider the technical side of the issue.
')
When planning to transfer part of the IT infrastructure to a third-party data center, you should decide exactly how all the information resources of the organization will be combined into a single network. Solutions from leading manufacturers (Juniper, Cisco and others) are often expensive; small and medium-sized companies may not afford them. In this regard, it is quite natural and explainable that the increased interest in free open source products, many of which are as good as paid counterparts, and sometimes even surpass them.

An important element of a corporate network is a router - a specialized network device designed to unite network segments and forward packets between them. Routers are both hardware and software. In the case when it is necessary to build an IT infrastructure with minimal expenses, the use of a software router may be quite a suitable option.

In this article, we will talk about the VyOS router, an interesting and promising product, which is also distributed under a free license for free, and we will show how it can be used to solve practical problems.

VyOS: general information

VyOS is a fork of the well-known network operating system Vyatta . His first release codenamed Hydrogen was introduced in December 2013.

The latest release to date - Helium - was released in September 2014. The command line interface (CLI) in VyOS is similar to CLI devices from Juniper Networks.

The possibilities of VyOS are really wide. This is not a complete list:

• firewall for IPv4 and IPv6, including filtering p2p traffic;
  Network Address Translation (NAT);
• DHCP server for IPv4 and IPv6;
• intrusion detection system;
• load balancing and channel redundancy;
• reservation of routers with synchronization of the connection state table;
• virtual private networks (IPsec, L2TP / IPsec, PPTP, OpenVPN);
• traffic accounting (Netflow and sFlow);
• web proxy and URL filtering.

Like Vyatta, VyOS is based on Debian. This allows you to extend the functionality by installing additional deb-packages.

Installation

We will not give a detailed installation guide for VyOS, and there is no need for it: everything is detailed here . There are two types of VyOS installation: install system and install image. The first type (install system) implies a standard OS installation on disk. When installing using install image, each version of VyOS will be in a separate directory, which makes it possible to roll back to a previous release in case of problems (recommended installation method).

So: boot from the disk, log in (login - vyos, password - vyos), execute the install image command. The installation begins, during which you will need to answer standard Linux installer questions. Upon completion, run the reboot command and log in again and log in with the login and password specified during installation.

Practical example

Consider the features of the VyOS on a specific practical example. Conditions of the problem: the organization consists of three geographically distant units: one in Moscow, the second in St. Petersburg, and the third in Khabarovsk. In St. Petersburg there are four servers installed in the data center. You need to make sure that only one of them needs to be connected to the Internet directly. The rest must be connected to the local network and access the Internet through a router. We will use different types of connections for branch offices - L2TP / IPsec, PPTP and OpenVPN.

Our network will look like this:

Gateway configuration

After installing the network yet, so we will first configure it through the KVM console.

To begin with we will configure the first network interface (external), which will have the address 95.213.170.75. We switch to the configuration mode with the configure command — yes, yes, everything is like that of the “older” iron counterparts.

set interfaces ethernet eth0 address 95.213.170.75/29 set interfaces ethernet eth0 description "WAN" 

In this case, we assigned the address to the interface eth0 and specified the port description in order not to get confused in the future.

We also indicate the default gateway addresses and the DNS server:

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

Here we use the St. Petersburg Selektel DNS server, but you, of course, can specify any other.
We will configure the SSH service, with which we will further configure the gateway:

 set service ssh port "22" 

The logic of VyOS is almost the same as that of Juniper Networks devices. To apply the changes, you need to execute the commit command. In order for the changes to remain in force after a reboot, they must be saved using the save command. This vyOS command differs in terms of logic from JunOS: in a network operating system, after Juniper, commit does not need to save changes after commit.

Connect to the router via SSH. To enter the system, enter the username and password specified during installation. Then we configure the eth1 internal network interface. This is the local network interface to which the servers in the data center are connected. Assign it the address 10.0.10.1 with the network mask / 24 and add a description:

 set interfaces ethernet eth1 address 10.0.10.1/24 set interfaces ethernet eth1 description "LAN" 

In order for our machines to recognize the names of network resources, you need to configure DNS. We will configure the DNS forwarder, which will redirect requests for resolving names to the servers specified by the configuration. The setup procedure for this component is 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" 

The first command specifies the cache size that the DNS forwarder will use to store the records. We set the cache size to zero, since in our case the storage of DNS records does not make much sense. The second command sets the interface on which the DNS forwarder will “listen”. We specifically use only the internal interface on which the DNS forwarder will “listen” to requests, in order not to make the DNS forwarder accessible to the entire Internet. In the third and fourth command addresses are indicated, where requests will be sent. In our example, the selector DNS servers are used, but instead of them, of course, you can specify any others.

All components necessary for the functioning of the local network are ready for operation. Go to the firewall setup.

In VyOS, we can use firewall rules sets, calling them by any name. In our example, the external network uses a set of rules under the name OUTSIDE, for the internal, respectively, INSIDE.

For the external interface, we will allow all the connections "from the inside to the outside", for the internal interface - all from the "inside to the outside" and access to SSH.

Create rules for the external interface:

 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" 

By the above commands, we resolve the previously established (established) and related (related) compounds.

Then we define the firewall rules:

In the first rule, we set the default action - in our case it is “drop” (all packets that do not fall under the established rules will be dropped by the firewall). In the second, we allow the passage of ICMP packets; First of all, this is necessary so that in the event of a failure, we can “ping” our router. The third rule is responsible for SSH connections: we allow TCP traffic coming on port 22.

Let's apply the created rules to the corresponding interfaces - external and local:

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

It is worth paying attention to the in and out parameters - they specify the type of traffic inbound or outbound relative to the router and are not associated with the names of the firewall rule sets.

Do not forget to apply and save the configuration using the commit and save commands.

VPN configuration

As mentioned above, in branches we will use different types of VPN connections. Let's start with setting up L2TP / IPSec (see here for more details):

 set vpn ipsec ipsec-interfaces interface eth0 set vpn ipsec nat-traversal enable set vpn ipsec nat-networks allowed-network 0.0.0.0/0 set vpn l2tp remote-access outside-address 95.213.170.75 set vpn l2tp remote-access client-ip-pool start 10.0.10.20 set vpn l2tp remote-access client-ip-pool stop 10.0.10.30 set vpn l2tp remote-access ipsec-settings authentication mode pre-shared-secret set vpn l2tp remote-access ipsec-settings authentication pre-shared-secret <> set vpn l2tp remote- access authentication mode local set vpn l2tp remote-access authentication local-users username <> password <_> 

Using the first three, we set the IPSec configuration: specify the interface to which the packets will go, enable NAT traversal and enable NAT for all networks. Next come the commands responsible for L2TP. In general, it is not difficult to guess from the writing of the teams what they are responsible for, let us pay attention only to some parameters.

• outside-address - specifies the external address of the VPN server;
• pre-shared-secret <password> - sets the password for the connection, which will later be used to configure VPN on client devices;
• authentication mode local - sets the authentication type. In our example, local authentication is used, but a RADIUS server can also be used for centralized account management.

In the last line, we create a user and set a password for it.
After that, we will make adjustments to the firewall rules and allow L2TP / IPSec traffic.

Rule 4 allows ESP protocol traffic on which the established IPSEC tunnel works, 42 - NAT traversal, 43 - port 1701, on which L2TP is running.

Now let's move on to setting up the second type of VPN connection and “raise” the OpenVPN server.
First, copy the easy-rsa files to the / config / easy-rsa2 directory, so as not to lose them when updating the system:

 cp -rv /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /config/easy-rsa2 

If necessary, you can change the variables specified by default in certificates, for example:

 nano /config/easy-rsa2/vars export KEY_COUNTRY="RU" export KEY_CITY="Saint-Petersburg" export KEY_ORG="Selectel" export KEY_EMAIL="t-rex@selectel.ru" 

This data will be indicated in the fields of certificates that we will generate. Go to the / config / easy-rsa2 / directory and load the variables:

 cd /config/easy-rsa2/ source ./vars 

Delete all keys:

 ./clean-all 

Then we generate the certificate authority files:

 ./build-ca ./build-dh 

and server certificate:

 ./build-key-server t-rex-server 

After that, copy the keys to the appropriate directories:

 cp /config/easy-rsa2/keys/ca.crt /config/auth/ cp /config/easy-rsa2/keys/dh1024.pem /config/auth/ cp /config/easy-rsa2/keys/t-rex-server.key /config/auth/ cp /config/easy-rsa2/keys/t-rex-server.crt /config/auth/ 

Next, prepare the client files for connecting to the server:

 ./build-key branch-msk 

and immediately copy them to a separate folder:

 cd /config/easy-rsa2/keys mkdir branch-msk cp branch-msk* branch-msk/ cp ca.crt branch-msk/ 

The generated files will be needed to connect clients to the server, so they will need to be transferred to the client side. This can be done using any SCP client: WinSCP for Windows or the standard scp console client for Linux.

Next, go to the server configuration:

 set interfaces openvpn vtun0 mode 'server' set interfaces openvpn vtun0 server name-server '10.0.10.1' set interfaces openvpn vtun0 server push-route '10.0.10.0/24' set interfaces openvpn vtun0 server subnet '10.1.10.0/24' set interfaces openvpn vtun0 tls ca-cert-file '/config/auth/ca.crt' set interfaces openvpn vtun0 tls cert-file '/config/auth/t-rex-server.crt' set interfaces openvpn vtun0 tls dh-file '/config/auth/dh1024.pem' set interfaces openvpn vtun0 tls key-file '/config/auth/t-rex-server.key' set service dns forwarding listen-on vtun0 commit save 

Let's pay attention to the last command: in it we redirect the name resolution requests to the DNS forwarder configured earlier. We also note that in the case of OpenVPN, we first used a separate network to build the tunnel itself, and then we routed it to the local network where our servers are located. This is due to the features of the protocol. In more detail we will tell about it in the following publication.

PPTP server setup

Configure the last type of VPN connection - PPTP. Of course, PPTP is weakly protected and therefore can hardly be used to transmit confidential information, but it is widely used to provide remote access. PPTP client is present in almost any device that has a network connection.

From the above example, you can see that PPTP is configured in much 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 the local user authentication mode. If you have a RADIUS server, you can select the radius authentication mode: with its help, it is much more convenient to manage user accounts.

Then we create local users, specify the range of IP addresses and DNS server data issued to clients. The last command sets the address of the interface on which our server will “listen”.

Apply and save the settings:

 commit save 

The server is ready to connect clients.

It remains only to allow the passage of traffic from the local network to the outside. Thus, we will provide Internet access to servers connected to the local network, as well as users connecting to our router from the branches:

 set nat source rule 1 outbound-interface 'eth0' set nat source rule 1 source address '10.0.10.0/24' set nat source rule 1 translation address masquerade 

Conclusion

So, that's it: we have built a network in accordance with the conditions of the task. One of the servers (located in St. Petersburg) acts as a router, the other three servers are connected to it via a local network. Routers in branch offices have access to local network resources through secure VPN connections.

In this small review we described only the basics of building a small corporate network. In the next post, we’ll talk about VyOS’s capabilities in more detail and learn how to more flexibly manage firewall rules, forward ports, allow traffic of various protocols frequently used in company networks, and also consider the following questions:

• GRE tunnel organization;
• work with L2TPv3 protocol;
• QoS;
• zone-based firewall;
• performance tuning of the network interface;
• VRRP.