In his latest blog our technical expert, Gbenga Osoba tackles the topic of network security. He takes a deep dive into Software Defined WAN versus VPNs. What are the pros and cons of each technology?
What are the benefits of VPNs?
1. Reduced Cost - More and more, VPNs leverage an internet service provider's public network connection. Today, this is broadband in the form of ADSL, Cable or Fibre.
However, organisations can also request private circuits with dedicated bandwidth from their service provider to form a dedicated secure private network.
This can also be referred to as a VPN (or SPN and commonly marketed as MPLS). The advent of the internet has enabled individual/home and businesses to reduce the cost of VPNs.
2. Scalability - Leveraging VPNs over the public internet is much more scalable and agile to deploy, compared to dedicated circuits end-to-end.
For example, Customer A can easily connect to Customer B by using an internet-based VPN, and further customers as required. Whereas, attempting the same with dedicated private circuits would present more costs and be far less flexible.
VPNs can connect both domestically and internationally. They are only really limited by where internet connections exist. And by the device at each end which establishes the VPN.
3. Security - Your traffic flowing over the VPN is encrypted/secured and should use standards-based protocols to allow for connectivity between different vendors.
This allows users to work from home and connect back to their place of work systems. Plus, users can anonymise their presence on the Web and avoid snooping in public WiFi locations.
What are the limitations of VPNs?
1. Throughput / Bandwidth over the public internet can be limited: throttling by your service provider (or another intermediary service provider) can reduce application response times and impact the user experience. You may also suffer from congestion/packet loss within the internet - download speeds tend to be only as fast as the slowest link.
2. The internet cannot offer Quality of Service (QoS). Therefore, by extension a VPN cannot offer complete guarantees in terms of your application / user experience. But It can prioritise applications at each end of the internet link, where you have control of your network on the other/each side of the internet connection.
In the past QoS was not offered by internet service providers. Today, however, there are exceptions. For example, many mobile phone carriers and other VoIP platform companies have special agreements with service providers to prioritise their traffic over the internet. This helps provide a better experience for their customers. This type of arrangement also extends to streaming organisations like Netflix.
3. Traffic over the public internet is prone to snooping/attack
4. Limited Scalability - If there is a requirement to have many VPN connections due to your organisation having many sites/locations, each connected with each other.
This type of connectivity/model does not scale very well:
- The number of connections to configure is given by the formula Nx(N-1)/2, where N is the number of nodes/sites (assuming one node at each site for simplicity - there may be two configured as a High Availability pair. The above formula is simplistic and does not take an HA deployment into account, but can be easily modified to do so).
- So for example if you have 2 sites that require a VPN you will configure 2x(1)/2 = 1 connection, if you have 10 sites you will configure 10x(9)/2=45 connections , but in actual fact you will need to touch/configure 2 devices, given by the formula Nx(N-1) for the first example and touch 10 devices, 90 (10x(9)=90) times in total for the second example (ie as a worse case, if your locations were popping up sequentially over time).
You can see that this can be exhaustive where the number of sites increases and the requirement to configure connections becomes exponential in nature, and is prone to operator misconfigurations/errors. To overcome this scalability limitation, some VPN vendors now enable on-demand VPNs. These connect to the required sites over the internet when required, automatically. They scale very well to hundreds of nodes without the need to configure all possible VPN connections manually.
So, can software-defined WAN (SD-WAN) address those limitations?
Yes, here are the key ways SD WAN addresses some of the limitations of VPNs.
1. Reduced cost; SD-WAN can host interfaces for the different types of connections: MPLS/VPLS, Broadband, 4G/LTE. Where traditionally you might have a separate router presenting each service, now these functions can be collapsed into one SD-WAN device, thus reducing device costs and management.
2. Improved Bandwidth/Throughput; SD-WAN can address limitations of VPNs that use both public internet and dedicated secure private networks.
SD-WAN devices can support the three main types of connectivity concurrently; MPLS, Public Internet (broadband) and 4G/LTE.
By monitoring the behaviour/performance of applications, SD-WAN devices can choose the best connection to use of the three. In turn, this can greatly improve the quality of experience for the customer, whether that is because one, (or more) connection(s) is being starved of bandwidth thus impacting Voice traffic.
For example, SD-WAN will automatically reroute traffic to the better performing link(s). The decisions can be made automatically based on thresholds/metrics that the administrator of the SD-WAN devices set, these in turn would of course be aligned to the business requirements.
In addition, it is possible to configure multiple links for applications increasing bandwidth to that application or ensuring delivery by making multiple copies of the packets of information placed on the different connection types. Meaning, at least one of the packets will reach its destination, again enhancing the user experience.
This technique would be used where a connection was proving unreliable through congestion or dropping packets, or, could be a policy to always provision business critical applications utilising this capability.
3. Scalability/Security; SD-WAN can encrypt traffic between sites over MPLS*, Public Internet (Broadband) and 4G/LTE connections. Where companies have multiple sites SD-WAN can dynamically form connections between other SD-WAN enabled sites, thus eliminating the need to configure Nx(N-1)/2 connections. *There are some use cases which require encryption over MPLS too.
Given the security features in SD-WAN, such as segmentation, visibility and encryption, do we still need VPNs?
The capability of segmentation, visibility and encryption still facilitate packets traversing a service provider medium, whether that be through private or public connectivity.
SD-WAN can leverage VPN technology to secure/encrypt traffic that traverse the public internet or 4G/LTE, between sites.
VPN technology that encrypts traffic could also be used over MPLS inside of an SD-WAN deployment, where the business has a requirement.
So, we are not saying that SD-WAN and VPN are mutually exclusive, but that the SD-WAN deployment can use VPN as part of a site to site connection requirement; especially where public internet and 4G/LTE connections are used as the transport mediums.
If we still need VPNs, in what scenarios should we use them?
Where an SD-WAN device has a connection to the public internet and/or 4G/LTE broadband services, VPN technology should be used.
Moreover, there are business use cases where MPLS connections are deployed and security policy may dictate that the packets traversing the MPLS cloud should be encrypted also.
Some of the SD-WAN vendors have agreements with Cloud providers, and therefore allow you to spin up an SD-WAN virtual appliance in Azure or AWS where you have cloud workloads, enabling the business to benefit from the features of SD-WAN and the diversity of connectivity type that may be present at your cloud provider.
Can/should companies use both VPNs and SD-WAN?
Yes, companies should use both VPNs and SD-WANs as part of the same integrated solution and to enable a better quality of experience (QoE).
Gbenga used his expertise on network security to take part in a recent IDGTechTalk debate on this topic. You can check out the full IDG debate here.