Types of VPN Explained: IPsec, L2TP/IPsec, PPTP and SSL/TLS VPN

Key takeaways

• All four protocols build an encrypted tunnel, but they work at different layers and trust different cryptography.
• PPTP's encryption (MPPE with RC4) is broken by modern standards. Do not use it for anything that needs confidentiality.
• IPsec is strong and standard for site-to-site links. TLS-based VPNs are usually easiest for individual remote users because they blend in with normal HTTPS traffic.
• A VPN protects data in transit. It does not make the endpoints or the service behind it secure on its own.

What is a VPN, and why does the protocol matter?

A VPN creates an encrypted tunnel between two points over a network you do not fully trust, usually the public internet. The protocol decides how that tunnel is built: which layer it works at, how strong the encryption is, how it handles firewalls and NAT, and how easy it is to set up.

Picking the right one matters because the weakest protocol here, PPTP, is still found in old router firmware and legacy configurations, and using it for anything sensitive gives a false sense of security.

Quick comparison

IPsec VPN

IPsec secures IP packets at the network layer using two main protocols: ESP (Encapsulating Security Payload), which does the encryption, and AH (Authentication Header), which authenticates but does not encrypt. Most deployments use ESP. It runs in transport mode (encrypting only the payload) or tunnel mode (encrypting the whole original packet), and negotiates keys through IKE, now usually IKEv2. See RFC 7296 for the IKEv2 specification.

Strengths: strong, well-reviewed encryption; built into most routers, firewalls and operating systems; the standard for site-to-site links.
Weaknesses: configuration has many moving parts (phases, proposals, lifetimes), and strict NAT can cause problems unless NAT-T (UDP 4500) is enabled.
Typical use: two branch offices connect their firewalls over the internet with an IPsec tunnel, so traffic between them is encrypted without every application needing its own security.

L2TP/IPsec VPN

L2TP (Layer 2 Tunneling Protocol) builds the tunnel but has no encryption of its own, so it is always paired with IPsec, which supplies the encryption and authentication. Traffic is encapsulated twice: once by L2TP, then by IPsec.

Strengths: inherits IPsec's strong ciphers; native clients exist on Windows, macOS, iOS, Android and Linux with no extra software.
Weaknesses: double encapsulation adds overhead; still needs the same IKE/ESP ports as IPsec, which strict firewalls may block.
Typical use: an organisation's built-in VPN client for remote staff where installing a third-party app is not an option.

PPTP VPN

Point-to-Point Tunneling Protocol wraps PPP frames in GRE and encrypts them with MPPE, which by default uses RC4. RC4-based MPPE and the MS-CHAPv2 authentication it commonly pairs with have known, practical breaks, and GRE is easy for networks to block.

Strengths: very simple to set up, low processing overhead.
Weaknesses: its encryption can be broken with modern computing power, and it is vulnerable to known authentication attacks. It should not protect anything confidential.
Where you still see it: old routers and legacy configurations. If you find PPTP in production, that is a finding to raise, not a setting to leave alone.

SSL/TLS VPN

Rather than encrypting at the IP layer, an SSL/TLS VPN secures traffic using TLS, the same protocol that secures HTTPS, usually over port 443. Two common modes exist: clientless, where users reach specific internal web apps through a browser portal, and full-tunnel, where a client app routes all or selected traffic through the VPN. Modern alternatives such as WireGuard use their own lightweight protocol rather than TLS, but serve a similar remote-access role with simpler configuration and strong default cryptography; it is worth knowing that WireGuard is a separate protocol, not a TLS VPN, if you see it listed alongside these four.

Strengths: works through almost any firewall because it looks like ordinary HTTPS; easy for end users; granular access to specific apps in clientless mode.
Weaknesses: depends on keeping TLS configuration and certificates current; clientless mode can expose only what is published, which needs careful scoping.
Typical use: remote staff connecting to internal tools and SaaS resources from laptops and phones, which is now the most common deployment for new remote-access VPNs.

Which should you choose?

• Site-to-site between offices or data centres: IPsec.
• Remote workforce, BYOD, mixed devices: SSL/TLS VPN, or WireGuard where supported.
• Built-in client with no extra software, and firewall rules allow it: L2TP/IPsec is workable, though newer options are usually simpler and faster to set up today.
• PPTP: replace it. It should not appear in a current design.

Hardening tips for any VPN

• Use strong, unique pre-shared keys or certificate-based authentication, never a weak shared password.
• Require multi-factor authentication on the VPN login itself as well as on the applications behind it.
• Patch the VPN gateway and client software; VPN endpoints are a common target.
• Apply least privilege: a VPN connection should reach only what that user needs, not the whole network.
• Log and alert on VPN authentication failures and unusual connection times or locations.
• Retire PPTP and any configuration still using MS-CHAPv2 alone.

Next steps

For a closer look at choosing between the two modern options, read SSL/TLS VPN vs IPsec VPN. To go deeper on IPsec itself, see understanding IPsec. For structured networking and security fundamentals, see WebAsha's CCNA (200-301) course.

Related reading

• [2026] CCNA Interview Questions on Security Protocols