Protecting your network traffic during uncertain times

None of us really want to hear another word about the ongoing pandemic (I will refrain from using the name), soon hopefully only a distant memory. Throw in some Texas sized power outages, financial uncertainties, massive security breaches and the shift to a remote work-place.

What are we supposed to do? Simply wish for better times or start securing assets under our control? The latter seems the better choice.

Stay ahead of the industry with exclusive feature stories on the top companies, expert insights and the latest news delivered straight to your inbox. Subscribe today.

In this write-up I will focus on how companies and network operators can protect and sustain their increased network traffic. 

During crises, increasing demand or geo-political circumstances the supply-chain for monolithic and proprietary systems often gets hit the hardest. The safest option is to build your network from hardware that can be sourced from multiple places. Commercial-of-the-shelf (COTS) servers are increasingly being used for high-end routing, CG-NAT, VPN traffic and other network functions. These servers can be small uCPE type devices (often Intel ATOM or ARM processor based) and up to multi 100Gbps network routers running the latest Intel Platinum XEONs or AMD Epyc processors.

One could even use an old Intel XEON system sitting around by simply adding some Intel or Mellanox network adapters. These could be for instance 100G NICs providing the basis for a professional enterprise level network function all the while achieving some serious hardware supply-chain independence.

With the hardware secured and most likely already ahead financially compared to a monolithic solution, the next step would be applying a software network binary to implement your desired network function.

One such software package is 6WIND’s vRouter product. Major world-wide telecommunications companies and network equipment manufactures recognized early on the advantages and strength of this hardware independent solution and have been using the 6WIND software ever since.

The vRouter binary can be installed directly onto bare-metal servers or run virtualized as a VM. The VM can be configured in such a way as to have near bare-metal performance providing great deployment flexibility.

Once hardware has been selected and the bare-metal or VM image has been installed it is time to configure the network function.

6WIND IPsec vRouter

Let’s focus on securing network traffic with the product’s IPsec function. There are several use cases to consider. The most common ones are VPN Concentrator, Site-to-Site communications and the newer Secure Access Service Edge (SASE). Before we dwell into the individual use-cases, let’s look at what the 6WIND software based IPsec solution is capable of. 

The latest version of the 6WIND vRouter 3.x is capable of 14+ Gbps of IPsec traffic per server data-plane core. Download the datasheet.

What does that exactly mean? 

The vRouter binary comes complete with among other things a control plane, data plane and management plane. The underlying architecture is based on successful and proven technology that separates the data plane cores from the underlying O/S with its control and management planes. Each of these data-plane cores run independent with no O/S overhead, tied directly to the NIC cores where any hardware assist/offload such as Intel® QAT and AES-NI ensuring stellar performance.

Also keep in mind the encryption scheme, maybe it is dictated by the remote ‘tunnel end’ but if a mode can be chosen, configuring for AES-GCM will have better performance over AES-CBC.

The actual performance will of course depend on the CPU selected, but as cores are added to the 6WIND software it will scale in a very predictable linear manner with most normal network traffic patterns.

For the use-cases with a high number of tunnels, expect an establishment rate of up to 1K tunnels/sec. This rate can be of some importance when many users log-in at the same time in order to provide a good user experience.

How many tunnels will be needed in your use-case?

Up to 100K tunnels are supported by one instance of the vRouter, but this is highly dependent on the router and network configuration.

There are often two ways of setting up your VPN, with a route-based approach (a VPN tunnel is referenced by a route for determining what traffic goes through the tunnel) or a policy based approach (the routing table is not used to select traffic through the tunnel). I will recommend to Google search the terms in order to get a detailed explanation for benefits and drawbacks. The main consideration is that with a route-based configuration the number of tunnels supported will be much lower than with a policy-based configuration.

Getting back to the most popular use cases, let’s look at a VPN concentrator. This scenario often involves many remote branches, home-offices and road-warriors all connecting back to a router that decrypts the traffic for routing to the destination server.

These tunnels often carry less traffic than tunnels in other use-cases, tunnel establishment times are often important as well as what type of VPN clients (Microsoft, OpenVPN, ..) needs to be supported on the remote-end (laptops, uCPEs,..). Having good redundancy is critical in that many users will be immediately affected by an outage.

You will most often see a policy based IPsec configuration for this use-case. I have purposely not gone into detailed configurations for the mentioned use-cases, rather check the following link for an example of how to get it working:

VPN Concentrator – RoadWarrior example configuration 

With a VPN concentrator serving multiple remote sites, sometimes it is advantageous to have these individual branches be able to establish a direct tunnel between the branches (spokes) without having the tunnel traffic go through the VPN concentrator. The concentrator will merely be a conduit for providing a requesting branch with enough information dynamically for that spoke to be able to establish a tunnel to another branch/spoke. The underlying protocols for this is Dynamic Multipoint Virtual Private Network (DMVPN) which combined with Next Hop Resolution Protocol (NHRP) will allow for these dynamic spoke-to-spoke tunnels to be established.

A site-to-site use-case would not use DMVPN or have thousands of tunnels, rather there will often be a very limited number of “fat-pipes” tunnels between the sites often carrying a much higher amount of traffic. The configuration in this case is fairly simply, the main thing to look for would be ensure that the VPN software can distribute load to multiple cores over possibly one high-speed network interface (100Gbps for instance). If only one core can service that NIC, the performance will be fairly limited. Check the 6WIND’s User’s Guide to see configuration details for this.

Finally it is worth mentioning that the VPN concentrator use-case is quickly evolving into a Secure Access Service Edge (SASE) use-case. With the migration to running enterprise applications in the cloud, it has become less efficient to have to connect back to your main-site to be able to connect to your application running in the cloud. Rather the need now is to have a tunnel established directly from the remote-site to a cloud-provider running the enterprise applications. I won’t get into further details here but again point to the 6WIND web-site for more information.

Let me just mention one very interesting feature of the 6WIND IPsec solution, which is the high availability tunnel sync feature.

When a use-case such as a VPN concentrator has many tunnels (think thousands) the establishment rate of these tunnels are obviously of some importance, but what happens when thousands of users are remotely connected to their applications over these tunnels and suddenly the network path encounters an outage. 

Hopefully this network path would be supported by a second path for redundancy purposes. Often this is implemented by load-balancing or a VRRP (redundancy protocol) pair. In the case of a VRRP pair the 6WIND software has a unique feature that continuously synchronizes the tunnel security associations (SA’s) to the passive backup. In the case of an outage on the main path all these possibly thousands of tunnels would not have to be reestablished but would continue over the backup system now promoted to be the active. This ensures the absolutely minimum downtime and inconvenience for the users allowing them to continue their work with a minimum of downtime.

In summary, in order to secure a network, picking a white-box solution that can run on bare-metal as well as virtualized seems like the best financial and logical choice.