Solving the Cumbersome Challenges of Site to Site VPN Management

Today’s network landscape is broad and dispersed. Over the past few years, staggering numbers of IP connected devices were deployed, applications and data have been moving out of the internal data center and into the public cloud, and users sprawled out of corporate buildings.

The risky proposition of providing access to a varied list of contractors, suppliers, partners, customers, and developers has also compounded.

Delivering and maintaining security across these multiple networks, endpoint devices and applications are challenging due to the siloed management of existing products coupled with a lack of IT and cybersecurity talent and experience.

The legacy method for security when connecting multiple separate site local area networks (LANs) is fractured and cumbersome, making management and new additions overly complex.

All of this complexity rears its head in a big way in the management of site-to-site VPNs for organizations of all sizes.

Biggest problems with Site to Site VPN network management

There are a few key reasons why most current methods for site-to-site VPN management are cumbersome and difficult.

Individual site VPN configuration and management

Most of the time, deploying a site-to-site VPN requires the use of physical security appliances, like a firewall or security gateway, at each site you want to be connected through a VPN tunnel.

This involves installing, configuring, and managing dispersed individual (hardware) appliances at headquarters and each remote branch location. Each location also typically comes with its own maintenance, services, and support contracts.

There are two topologies for building a site-to-site virtual network.

The first is a mesh network architecture (spoke-to-spoke), where all of an organization’s networks are connected to one another.

The second is a hub-and-spoke architecture where all of the branch office networks (spokes) tunnel back to a headquarters (hub). In this case, the spokes are not directly connected with one another.

In either topology, the management of each individual hardware appliance or site VPN could require a physical presence at the site, so anytime a change needs to be made, someone has to physically go to the site to make the change on the VPN device.

With traditional architectures, this fragmented system introduces unnecessary complexity into the already time and resource-constrained IT department.

🔎 Related Articles: Hardware VPN Buyers Guide

Addition of a new site in the architecture

The initial configuration and ongoing management complexity of multi-site VPN become prohibitive as the number of remote branches increases. This is because all ends of the VPN tunnel need to be manually created and tuned through a time-consuming and error-prone process.

Variables such as IP addresses of the appliances, subnets available at each location, pre-shared keys or certificates, authentication and encryption protocols, and more need to be defined on each VPN gateway appliance.

If any of these variables changes (say the introduction of a new office or remote site), the setting(s) on each appliance, in each location, would need to be updated locally in order for each VPN tunnel to re-establish its connection.

This makes adding new sites to your private network an incredibly time-consuming and manual process.

Bandwidth requirements for secure access service edge

On top of all of this, as technology has improved and advanced, so has its thirst for bandwidth.

Applications that are developed are requiring more and more bandwidth. In general, bandwidth availability is taken for granted during application development, with creators assuming that as much bandwidth as needed will be able to be accessed.

The evolution of IT technologies has also altered traffic flows within distributed organizations. Not only do remote users require significantly more bandwidth (for example, when using video), but they also need to directly access SaaS and cloud-based applications such as Salesforce, Office 365, and off-premise storage (such as Dropbox, Evernote, and so on).

As such, the general bandwidth requirements continue to increase with the increasing list of technologies in use.

Limitations and costs of dedicated or leased lines

Traditional methods to build out site-to-site architectures depended upon the purchase of dedicated or leased lines. Things like Multiprotocol Label Switching (MPLS) lines have historically been used to execute this, but are often cost-prohibitive. For instance, a 100MB link could cost you upwards of $1,000 per month.

MPLS lines also have limitations that may reduce their effectiveness in a site-to-site VPN architecture.

For instance, traditional MPLS networks, which transmit all traffic from the branch to a centralized data center, can’t offer low latency, high-performance access to cloud applications.

In addition, the security and management requirements associated with disparate traffic flows have added to the complexity of managing branch operations - thus increasing operational (staffing) costs for many IT organizations, in addition to the already high cost of the leased line itself.

The evolution of technology

There have been quite a few changes and advances in the industry in terms of what kinds of providers exist and the technologies that can facilitate site-to-site operations.

Next gen firewalls and advanced security practices have changed the abilities of the hardware appliances at each physical location in a site-to-site architecture, and the arrival of SD-WAN providers have created an environment where some of these problems can be solved.

What is needed to solve the problems?

The most important requirements that are needed to solve the problems that face site to site VPN deployments include:

• The ability to execute rapid deployment of WAN services (such as bandwidth and firewall) to distributed branch operations without the need to send IT personnel on-site.

• The ability to add bandwidth easily (with additional circuits), or reduce it as business requirements evolve.

• Internet connectivity (including cable, DSL, Ethernet, and fiber) that is widely available, quick to deploy, and a fraction of the cost of equivalent MPLS circuits.

• Elimination of backhaul penalties of traditional MPLS networks.

• The ability to provide secure, high-performance connections from the branch to cloud to provide remote access VPN users with significant improvements in their experience when using the cloud or SaaS-based applications through a VPN client.

Using SD-WAN to improve Site to Site VPN connection management

As these needs arose, a new class of service materialized.

SD-WAN providers arrived to help solve some of the problems listed above and meet the requirements for the “new wave” of deployments.

What is SD-WAN?

SD-WAN uses software and cloud-based technologies to simplify delivery of WAN services to branch offices. Software-based virtualization enables network abstraction that results in the simplification of network operations.

By combining basic internet connectivity from multiple different providers as failovers, SD-WAN allows businesses to achieve the level of service provided by MPLS providers at a fraction of the cost.

SD-WAN enables IT and business managers to deploy Internet-based connectivity (with its benefits of ubiquity, high bandwidth, and low cost) easily, quickly, and with quality, reliability and security.

It also allows centralized management of all sites, requiring fewer configuration changes and eliminating the need for physical presence on location.

SD-WAN maturity

SD-WAN as a technology category is still young, and thus still maturing.

Ultimately, you will want an SD-WAN solution that covers all of the following tiers (affectionately named “Vesh’s Tiers of SD-WAN”):

• Tier 0, Command Line Interface (CLI) or wizard site-to-site: This is the foundational requirement for all deployments. At minimum, there should be a centralized CLI that allows for the adjusting of configuration settings across hardware appliances.

• Tier 1, Auto provisioning site-to-site: Tools in this category allow you to connect branches without any tedious, manual VPN connection configuration. Dedicated security appliances are used to configure, monitor, and maintain VPN settings.

• Tier 2, Backhaul failover and load balancing, Quality of Service (QoS), and routing: In this tier, adding key functions like connection failovers and shifting of VPN traffic to manage the load across all lines helps with efficiency and throughput. The addition of advanced QoS and routing features also help to improve performance.

• Tier 3, WAN (path) optimization: Technologies in this category help to improve the network application experience at each site, and look to make better, more effective, use of limited network resources.

• Tier 4, Cybersecurity: This layer involves ensuring that all communications over the site-to-site connections maintain the highest level of security.

The table below outlines where current technologies (as of this writing) stand on providing each of the tiers above in their deployments.

Final Thoughts

While improvements to site-to-site VPN architecture and security will never fully be “done,” many of the recent industry and technology changes of the past few years have fundamentally changed how site-to-site VPNs are architected and deployed.

Evaluating the use of SD-WAN technologies for site-to-site deployments vastly reduces the effort required by IT teams to set up and manage these architectures, and significantly reduces the cost barriers associated with them.