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.
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
(incl. VAT)