SD-WAN vs. VPN: How do they compare?

When it comes to comparing SD-WAN vs. VPN services, enterprises choosing between the technologies should consider factors like cost, cloud usage and application awareness.

With software-defined WAN sometimes marketed as an upgraded version of a virtual private network over the internet,...

many IT teams wonder about the fundamental differences and similarities of selecting SD-WAN vs. VPN services.

While the preferred connectivity option for SD-WAN platforms is indeed based on the internet -- or public IP, to be specific -- the technology is connectivity-agnostic. SD-WAN marketing teams might want users to believe internet connectivity is the primary option for SD-WAN, but the original concept for software-based networks was -- and still is -- to support multiple interfaces.

In order to choose the right option for their organizations, enterprise IT teams are looking to cut through the hype surrounding SD-WAN by comparing and contrasting the benefits of SD-WAN vs. VPN.

A look at VPNs

For decades, the fundamental mission of basic IPsec VPN has been to drop packets that are not from authenticated endpoints. All traffic in between endpoints is encrypted at the highest level, which forms the basis of a VPN over the internet. VPNs can be simple and cost-effective, but they can also be problematic in terms of guaranteeing network performance.

How VPNs work
Traffic is encrypted as it passes from Point A to Point B.

At their most basic level, VPNs can prioritize applications and traffic before they are encrypted. The value in doing so is limited, however, because once traffic travels within an encrypted tunnel, it cannot be prioritized from the provider network perspective, as the header is encrypted and can't be viewed. What's left is a best-effort network that supports traffic at a reasonable performance level.

A typical VPN is fine for small businesses running their operations over a single IP backbone. For larger businesses with multiple locations, however, an IPsec VPN often causes issues with voice and video applications due to high latency or congestion on the network.

Although SD-WAN can act as a savior for these larger networks, enterprises still face end-to-end traffic concerns, especially on an international basis. So, why would a business select an IPsec VPN instead of SD-WAN?

Essentially, enterprises comparing SD-WAN vs. VPN should base their decisions on a sound alignment of business processes, applications and strategy. In basic terms, they should consider the following questions:

  • Does your business need to guarantee application performance, or is best effort acceptable?
  • Does your business use the cloud and support remote, unsecured networks?
  • Does your business want to manage its own WAN?

For businesses looking to implement cost-effective, best-effort VPN services, using a traditional VPN appliance with a simplified feature set, a simple router or client with IPsec functionality is acceptable. The cost of deploying such a service is typically minimal. Some companies deploy VPN services with broadband for less than $100 per month.

When to consider SD-WAN

SD-WAN technology starts to make sense once enterprises adopt and rely on cloud services or require application awareness, remote access and granular security. While SD-WAN doesn't have end-to-end quality of service (QoS) like a Layer 3 MPLS VPN, SD-WAN meets the challenge by providing the capability to sense network conditions and locally prioritize applications. SD-WAN's local QoS is far more advanced than basic internet VPN services due to its granular level of support, as well as technologies like caching or application acceleration.

When organizations require cloud services, they should consider security and application awareness. SD-WAN appliances and clients are typically more robust in terms of feature sets that align with current working practices, like working from home, coffee shops or hotels. With SD-WAN's increased control, IT teams or providers can restrict and secure traffic based on user profile and traffic types.

In many cases, simplified self-management with easy-to-use GUIs is driving SD-WAN adoption. While traditional Cisco IOS VPN configuration required expertise and accreditation, SD-WAN configuration is based on the point-and-click approach.

The promise of SD-WAN is to support any type of network connectivity, from MPLS to virtual private LAN service (VPLS) and, of course, internet VPN. Currently, it still costs less to deploy simple IPsec devices to create standard VPN connectivity.

SD-WAN vs. traditional WAN architecture
SD-WAN can use multiple types of connectivity.

In the meantime, SD-WAN appliances and clients will offer everything in one basic, easy-to-use capability. The original promise of SD-WAN will start to become reality when every device or client is simply a fast conduit to a centralized management server. In other words, businesses will be able to consume the most basic SD-WAN services or the more complex elements -- depending on their overall need or on a site-by-site basis -- essentially using cloud network functions virtualization capability.

SD-WAN technology isn't quite there yet, as the majority of providers are pushing cost savings by using low-cost internet connectivity with hardware that is still programmable on an individual basis; although, it does take configuration from a server.

SD-WAN vs. VPNs: How to decide

While it's difficult to predict the future, businesses will no doubt look for the best network performance, security and flexibility for relatively low cost.

The objective of SD-WAN is to take business elements and map them into business enablement. With SD-WAN, the network becomes more granular, enabling better reporting, security and application performance. Unlike a standard internet VPN, SD-WAN can sense network conditions to ensure a predictable level of performance, no matter where clients connect.

SD-WAN technology starts to make sense once enterprises adopt and rely on cloud services or require application awareness, remote access and granular security.

When comparing SD-WAN vs. VPN over the internet, SD-WAN is far more comprehensive. SD-WAN technology has the potential to enable basic internet VPNs and to terminate global MPLS and VPLS networks.

But when considering any networking technology, enterprises need to be wary of marketing hype that can lead them down a path of buying SD-WAN with the wrap of a particular service provider offering, which can lack key components.

As IT teams move forward, technology acceleration and product features will continue, ultimately resulting in simple VPNs becoming a thing of the past. Enterprises will need to secure and treat application traffic with a more focused approach to avoid hacking threats or poor allocation performance -- all of which affect business.

Dig Deeper on WAN technologies and services

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What would drive your organization to replace VPN services with SD-WAN?
I understand where you're coming from and also the motivation to adopt SD-WAN compared to traditional IPSec based VPNs.

However, I want to raise a point regarding QoS markings for packets that are to be encrypted.

For the majority of QoS designs, classification is performed based on DSCP markings in the ToS byte of the IP packet. However, when an IP packet is encrypted through IPSec, the original ToS byte values also are encrypted and, thus, unusable by QoS mechanisms that process the packet (post encryption).

To overcome this predicament, the IPSec protocol standards inherently have provisioned the capability to preserve the ToS byte information of the original IP header by copying it to the IP headers added by the tunneling and encryption process.

If its GRE-over-IPSec, the original IP ToS byte values are copied initially to the IP header added by the GRE encapsulation. Then these values are copied again to the IP header added by IPSec encryption.

This process compensates for the fact that the original IP header (including the ToS byte) is actually unreadable (because of encryption) and allows the packet to be processed by (post encryption) QoS mechanisms in the same manner as any other packet.

Additionally, this process underscores the importance of ensuring that the encrypted traffic is marked properly (at Layer 3) before encryption.

Saying all this, I do understand that if the ISP queues any kind of internet traffic coming from the site into a best effort queue, copying of all these markings is pointless but some providers offering business internet do value these markings.