VPN Technologies, and Which One Belongs on Which Job

The two jobsThe two jobs, which is the only division that matters

VPN technologies divide into two groups before anything else about them matters. Every one of them is built for one of two problems, and the choice between those is settled before any protocol is named.

Joining two networks. A branch office needs to reach the file server, the phone system and the domain controllers at headquarters. The tunnel is permanent, both ends are equipment rather than people, nobody logs into anything, and the traffic is whatever the two subnets send each other.

This is a site to site VPN, and the shape of the network built from these tunnels is almost always hub and spoke.

Joining a device to a network. A person with a laptop needs to reach those same servers from a hotel.

The tunnel is temporary, one end is a human being who has to authenticate, and the interesting questions are about identity, device posture and what happens to the connection when the network changes underneath it. This is remote access, and it is where most of the security thinking belongs.

The technologies are not interchangeable across that line even where they are technically capable of crossing it. An IPsec tunnel to every laptop is a certificate and client management problem that grew out of a protocol designed for equipment.

An SSL VPN between two data centers works and gives up the routing behavior that made IPsec the standard for the job.

The technologiesThe technologies, one at a time

IPsec is a suite of protocols rather than a single one: IKE negotiates the keys and the security policy, and ESP carries and encrypts the data.

It runs at the network layer, which is what makes it right for joining networks, because routing decisions can be made about the tunnel the same way they are about any other link.

It is the most widely implemented and most interoperable of these protocols, and configuring it between two vendors is still an afternoon of matching parameters that both ends have to agree on exactly, from the AES key length down to the lifetime of the security association. When people say a VPN is hard to set up, they are almost always describing IPsec.

IKEv2, paired with IPsec, is the same suite pointed at the remote access job, and it is what the VPN clients built into the major operating systems speak natively: Windows, macOS, iOS and Android all support it without installing anything.

Two properties make it the default for mobile users. It re-establishes secure connections by itself when the network changes, so a phone moving from wifi to cellular data keeps its session instead of dropping it, and it negotiates quickly enough that the reconnection is not noticed.

Its security is IPsec security, since it is IPsec, and its weakness is the one every IPsec deployment has: fixed UDP ports that restrictive networks block.

SSL and TLS VPNs run over the same TLS protocol that secures web traffic, which is the whole point: the tunnel leaves on port 443 and traverses hotel wifi, mobile data networks and hostile firewalls that would drop anything else. An SSL VPN comes in two forms.

The clientless kind publishes specific applications through a browser portal. The client kind installs software and gives the device a network connection. Both authenticate people rather than equipment, which is exactly what the remote access job requires, and both inherit the AES encryption and certificate handling of TLS rather than defining their own.

WireGuard is the newest protocol of the set and the smallest by an enormous margin: a few thousand lines of code against several hundred thousand for the alternatives, one modern encryption suite with nothing to negotiate, and no options to get wrong.

That is a security argument as much as a speed one, because most insecure VPN deployments got that way through misconfiguration rather than through broken cryptography. It connects faster, roams between networks without ceremony, and its speed beats everything else here.

WireGuard has one design consequence worth understanding before deploying it: it is stateless and identifies peers by public key rather than by session, so the account lifecycle features an enterprise expects sit in the product built around it rather than in the protocol.

OpenVPN is the veteran of the remote access protocols: TLS based, endlessly configurable, running over UDP or TCP on any port, and supported by every operating system and firewall vendor.

Its flexibility is also its cost, because the configuration surface is large and its speed is the weakest of the three current options. Support for it is universal, which is why it remains the safe answer where a strange network condition has to be worked around.

L2TP with IPsec, and PPTP. L2TP provides no encryption of its own and is always paired with IPsec, which makes L2TP a heavier way to reach the same security IKEv2 reaches directly.

PPTP has been broken for years: its authentication and encryption were both defeated, and recovering a key is a service anyone can rent. Both protocols survive because operating systems ship with them and they appear in the connection dialog, which is not a reason to pick either.

GRE, with or without IPsec. GRE is a tunneling protocol with no encryption and no security properties at all, used to carry the data IPsec alone cannot, including multicast and routing protocols. The pairing of GRE inside IPsec is common in networks that need a routing protocol to run across the tunnel and still want the traffic encrypted.

MPLS is not a VPN protocol and belongs here only because it is the alternative people are actually choosing between. It is a service bought from a carrier, in which data stays on the carrier network and never crosses the public internet.

MPLS offers a performance guarantee no internet VPN can match, at a price no internet VPN comes close to, and it is not a secure transport on its own, because it encrypts nothing by default and its security rests entirely on trusting the carrier.

Zero trust network access replaces the remote access job rather than competing inside it. Instead of putting a device on the network, zero trust access authenticates a user and a device for each application individually.

The security difference that matters is blast radius: a compromised VPN client is on the network, and a compromised zero trust session has reached one application.

Site to siteChoosing for a site to site link

Three questions settle it, and none of them is about the protocol.

Is the data crossing the internet or a carrier network? Over the internet, IPsec, and there is very little argument. Over a carrier MPLS service, encryption is optional and security-minded organizations add it anyway, which is IPsec again.

Does a routing protocol need to run across the tunnel? Plain IPsec carries unicast IP and nothing else, so OSPF or BGP across the tunnel means GRE inside IPsec, or a vendor implementation that does the same thing under another name.

How many sites, and do they talk to each other? With a handful of sites and a hub, IPsec tunnels configured by hand are fine. Past that, the configuration burden is what SD-WAN products exist to remove, and the underlying tunnels are still IPsec.

Remote accessChoosing for remote access

Start by asking whether it should be a VPN at all. If people need three cloud applications and one internal system, a zero trust product reaches that one system without putting anybody on the network. This is the direction the whole category is moving, and starting there avoids replacing a VPN in two years.

If a VPN is right, WireGuard for speed, IKEv2 for mobile, SSL for compatibility. WireGuard has the best speed and roams between networks cleanly. IKEv2 has native operating system support on every platform and survives a change of network.

An SSL VPN goes through restrictive networks on port 443 and arrives with the enterprise features already built, because it is sold as a product rather than as a protocol.

Decide the split tunnel question deliberately. Whether all traffic goes through the tunnel or only traffic bound for the corporate network is a security and capacity decision with real consequences on both sides, and split tunneling is worth reading before the default is accepted.

PitfallsWhere people go wrong

Comparing a site to site protocol with a remote access one. IPsec against SSL VPN is not one comparison. For joining networks IPsec wins on routing behavior, and for joining people it usually loses on client management.

Treating MPLS as a VPN. It is a transport service. The real comparison is cost and guaranteed performance against the internet, and encryption is a separate decision layered on top.

Choosing a protocol before choosing the job. Every one of these can be forced into either role. Only two of them are good at each.

Keeping PPTP because it is in the connection dialog. Its encryption has been broken for over a decade. Being built into the operating system is not a security property.

Assuming a VPN gives zero trust security. A VPN authenticates once and then grants network access, which is the opposite of the zero trust model. Adding multi-factor authentication is worth doing and changes nothing about what a session can reach after the login.

Sizing the hub for the branches and forgetting the people. Remote access data and site to site data land on the same firewall, and the count of concurrent connections is the number that gets missed. Encryption throughput is the specification to check, not the interface speed.

ComparisonFive technologies, and the row that decides between them

The first row is the decision and the rest is detail. Everything that looks like a close call in the middle of this table stops being one as soon as the job is named.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Remote access What Is an IPsec VPN? The standard answer for joining two networks, and the one whose configuration is what people mean when they say a VPN is hard. Open this next11 min

• Identity and access · 13 min Zero Trust Explained The model replacing remote access VPNs, and the reason is blast radius rather than performance.
• Remote access · 11 min SSL VPN Explained, and the Reason It Needs Patching First The remote access option that goes through restrictive networks because it leaves on the same port as web traffic.