- Get four Apple AirTags for just $73 with this Black Friday deal
- I tested Beats' new Pill speaker and it delivered gloriously smooth sound (and it's on sale for Black Friday)
- These Sony headphones are a fan favorite - and $150 off for Black Friday
- I tested a 'luxury' nugget ice maker, and it's totally worth it - plus it's $150 off for Black Friday
- The Dyson Airwrap is $120 off ahead of Black Friday - finally
VPNs can complement SASE
The pandemic has accelerated the development of better ways to serve and secure remote workers, which make it a good time to rexamine VPNS.
Recently VPNs have received technical boosts with the addition of protocol options that improve functionality far ahead of where they were when first invented. At the same time, new security architectures zero trust network access (ZTNA), secure access service edge (SASE), and security service edge (SSE) are making inroads into what had been the domain of remote-access VPNs.
VPNs vs ZNTA
ZTNA’s main thesis is that you need to authenticate every user and device that wants network access. Instead of granting wide swaths of privileged access, you are stingy about what you grant when and to whom. This is because zero trust assumes that threats can originate both inside and outside the corporate network. While some enterprises have forsaken IPsec VPNs entirely for more comprehensive ZTNA-based networks, they still need other kinds of protection, such as encrypting employees’ smartphones from being tracked and hacked when they travel.
Cloudflare has a nice explanation of the differences between ZTNA and VPNs, focusing on three features:
- OSl layers: IPsec VPNs operate at layer 3, the network layer, while ZTNA—and by extension SSE and SASE—operates mainly at layers 4 through 7 via gateways and using web protocols such as TLS. This means ZTNA offers more complete protection, especially when it comes to protecting specific apps and devices. But layer 3 protection is useful to block broader malware movements and to segment your network for particular classes of users.
- On-premises hardware and software: Most corporate VPNs require their own on-premises servers that endpoints connect to via client software on each endpoint device. That means the server can be a single point of failure, and usually means traffic to and from cloud-based resources must pass through the corporate data center that houses the server, adding latency. ZNTA has a lighter footprint and is typically implemented with cloud-based resources and can operate with or without specific endpoint software agents. When they do employ agents, they can add to the endpoint’s CPU load.
- Granular control: Most VPNs are geared towards securing an entire network by providing a protected tunnel through which remote machines can gain access to the network. That sounds good in theory but is bad in practice because a single infected endpoint that gains access can serve as the jumping-off point for a malware attack on the entire network. ZTNA can be more precise by restricting both network access and application access and can therefore enforce fine-grained policies that allow access for a specific user on a specific device at a specific time for a specific application. This adaptive and more flexible security is a big benefit when dealing with unmanaged, BYOD-type devices, or IoT devices that don’t have any client software to secure them. ZTNA can also be used as a way to unify various security management tools. For example, Palo Alto Networks’ Prisma Access uses ZTNA to combine its firewalls, cloud access security brokers and SD-WAN tools
Despite these differences, there are situations where VPNs and ZTNA can co-exist. For example, a VPN can be used when connecting a remote office or when users need to connect to on-premises file servers. VPNs warrant a closer look right now for two reasons. First, VPNs and ZTNA can complement each other and provide a more comprehensive security envelope, especially as large numbers of workers remain in remote locations.
But more importantly, the VPN protocol environment has greatly improved over the past 15 or 20 years. IPsec has been largely replaced by version 2 of Internet Key Exchange (IKEv2), a tunneling protocol that is supported by Windows, macOS, and iOS. It also includes network address transversal (NAT) that provides faster tunnel reconnections for mobile devices as they move, uses AES and Blowfish for better encryption, and certificate-based authentication to prevent man-in-the-middle attacks. IKEv2 is also supported by many enterprise VPNs such as Cisco’s SSL AnyConnect and Juniper’s VPN products.
But there are also two recent VPN protocols Wireguard and OpenVPN. Both have a smattering of other services that are partly open sourced including a server network, endpoint clients, and the actual protocols themselves.
OpenVPN
The OpenVPN project has been adopted by consumer-grade VPN providers including Windscribe, Hotspot Shield, NordVPN, and ExpressVPN, and it supports Windows, MacOS, iOS, Android, and Linux clients. That has some spillover benefits for enterprise users, because being open sourced, there are more eyes on the code and its various implementations.
The project has developed what it calls the OpenVPN Cloud, which obviates the need for an on-site VPN server because you can connect to it as managed service. A free tier allows you to establish three concurrent connections, and monthly plans start at $7.50 per endpoint connection per month for at least 10 connections. That drops to just a few dollars a month for more than 50 connections. The OpenVPN Server software is also available for self-hosting configurations at similar prices. In addition to its VPN, the project also offers CyberShield, a service that encrypts DNS traffic, which is helpful to prevent DoS and man-in-the-middle attacks.
OpenVPN runs on both TCP and UDP ports, increasing its flexibility. This means connections via OpenVPN can be more resilient when state-sponsored actors try to block well-known remote access ports. One problem is that most of OpenVPN’s local servers are in the northern hemisphere so users connecting from other locations will experience longer latencies. The consumer-grade providers such as ExpressVPN and NordVPN have larger global footprints.
WireGuard
WireGuard is also an open-source project, and like IKEv2, it is designed for quick reconnections, which improves reliability. Like OpenVPN, it comes with an entire constellation of services, including Windows, MacOS, iOS, Android, and Linux clients, and it is supported by consumer-grade VPN providers including Mullvad, ProtonVPN, Surfshark, NordVPN, and Private Internet Access. Its advocates claim that because of its lean and mean architecture, it can outperform other VPN protocols and can be implemented easily in container collections. It is free, and it runs on any UDP port. Its authors have published very explicit instructions on its security limitations that include a lack of traffic obfuscation and the fact that the protocol is still very much a work in progress.
With either WireGuard or OpenVPN, enterprises have more power and flexibility in evaluating their remote protocol collection. You might come for the security but stay because of the utility. For example, you can use the managed OpenVPN cloud to quickly scale up or down your remote access needs, which is closer to the way ZTNA-based solutions operate.
OpenVPN and WireGuard in the enterprise
Given that both OpenVPN and WireGuard have been adopted by consumer-grade VPN providers, why should an enterprise pay any attention to them? First, their lower overhead can reduce latencies and improve usability. Second, because they demonstrate the benefits of using open-source code and methods such as third-party security audits to validate their worth, privacy, and other features. Enterprise VPN vendors could adopt these strategies for competitive reasons to improve their own offerings.
Does this mean enterprises should give up on SSE and SASE? Not at all. Enterprises have all kinds of remote-access needs that span a wide collection of applications, bandwidth requirements, and end user devices. Applications are run across all kinds of infrastructure: private cloud, public cloud, containers, and on-premises gear. A typical business uses multiple identity providers, authentication tools, and network configurations. Add to this mix the ability of SASE and SSE to isolate browsing sessions or to set up cloud access security brokers to further secure these resources.
Gone are the days when all remote users would connect via a rack of gateway servers housed in the data center, but the latest VPN protocols can complement the brave not-so-new world of zero trust, too.
Copyright © 2022 IDG Communications, Inc.