Open source multipoint VPN with VyOS

Connected Mesh

Requirements

A large VPN cloud with a multipoint setup isn't enough, because the GRE tunnel is unencrypted. In this example, I'll use IPsec to secure the traffic and prevent anybody from eavesdropping on the data or injecting packets.

When the transport is secure, you should focus on routing. All VPN gateways must announce their connected IP subnets. Static routing is possible, but very time consuming. A better approach is dynamic routing, which also includes automatic rerouting in case of link failures. With the OSPF (open shortest path first) option, every router sends its IP information to all other routers, which then calculate and build their own routing tables (see the "Dynamic Routing: RIP vs. OSPF" box).

Dynamic Routing: RIP vs. OSPF

Two of the open source routing protocols are not too complicated: RIP and OSPF. Oddly, and for no obvious reasons, nobody chooses RIP these days.

RIP calculates the metric for each route from the number of hops between the local system and the target network. A path with three hops is preferred over a path with eight hops. Unfortunately, in a VPN mesh, every network is three hops away. The technique behind the tunnel just skips many hops. Consequently RIP can't even decide which path is actually shorter. The result is poor: Either the traffic is load-shared over all links, or the wrong path is taken, which could end in asymmetric routing.

The metric used by OSPF looks at the bandwidth: The path (VPN tunnel) with the highest bandwidth is used to reach the target network. The bandwidth isn't measured; it is chosen by the administrator. The exact value is not important; the goal is to give the primary tunnel a higher bandwidth than the secondary tunnel.

Therefore, RIP makes sense in simple networks, but when it comes to dynamic routing over VPN tunnels, OSPF is a better choice.

If DMVPN is already in place, VyOS could be a cheap backup router. Cisco prefers proprietary technology, but in this case, all components have a good chance of playing well together. If everyone sticks to the RFC, it should work. However, it is best to ensure that Cisco and VyOS integrate well when choosing additional features, the cryptographic algorithm, and protocol variants.

VyOS performs on virtually anything, so the hardware platform is up to you. If a commodity server is not at hand, several recommendations are listed below.

Lab Network

When reviewing a technology like DMVPN, the use of real Internet links is mostly impossible. Thus, the features are tested in a lab network with simulated links and virtual machines. The demonstration network here (Figure 2) contains several sites with one or two VyOS VPN routers mixed with Cisco gear to test interoperability. Even the DMVPN hub is a VyOS-Cisco pair. All routers are connected by WAN emulators running WANem [4], which can introduce link instability, delay, and packet loss, so you can monitor network quality while WANem is doing bad things to your packets.

Figure 2: The lab prototype of a corporate network with Internet access.

Availability is always a concern in corporate networks, and designers use two different DMVPN networks to meet the requirement. Sites with two Internet uplinks obtain redundancy for both cabling and the provider. Sites with a single Internet link and two routers get at least some hardware redundancy. Small field offices normally have only one router, resulting in no redundancy even when both DMVPN tunnels are configured.

Hardware

VyOS needs a hardware platform with an Intel i386/x86_64 CPU or compatible. Also, it is fully supported when running as a virtual machine on VMware or VirtualBox. However, when using embedded hardware or single-board computers, double-check the specs first.

The test scenarios and lab network put VyOS on an apu system board by the Swiss manufacturer PC Engines [5]. The board comes with 3Gb adapters, low power consumption, and no fans. The chipset is Realtek, so please don't take "gigabit" literally: Serious research and testing shows at least 250Mbps throughput [6].

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Routing with Quagga

    Cisco and Juniper have implemented routing protocols to help your router find the optimum path. On Linux, you can use software like Quagga, with its Zebra daemon, to help automate this process.

  • Flexible software routing with open source FRR
    The FRR open routing stack can be integrated into many networks because it supports a large number of routing protocols, though its strong dependence on the underlying kernel means it requires some manual configuration.
  • IPv6 tunnel technologies
    Now that IPv6 is the official Internet protocol, all that remains is the simple task of migrating all the machines on the Internet. Until that happens, tunnel technologies provide an interim solution.
  • Creating a redundant array of inexpensive links
    The Fault Tolerant Router daemon uses multipath routing among multiple Internet connections to keep you connected, even when some connections go down.
  • IPv6 security on IPv4-only networks
    Even though corporations are looking to move to IPv6, in some situations networks still rely exclusively on IPv4. We discuss ways to minimize delays and unsatisfactory behavior in mixed IPv4/IPv6 IT environments.
comments powered by Disqus