L2TP/IPsec Explained: The Built-In Protocol That Outlived Its Prime

Last updated: July 5, 2026 · 30 min read

L2TP/IPsec is, simultaneously, the most available VPN protocol ever built and one that three major platform vendors have moved to retire. It ships natively on Windows 10 and 11, runs on virtually every consumer router on the market, and for two decades required no third-party software to configure. Between 2021 and 2025, Google removed it from Android, Microsoft deprecated it from Windows Server, and Apple’s macOS 26 Tahoe dropped the cryptographic primitives it depends on. This article explains what L2TP/IPsec is, how the protocol actually works from the inside, and what that coordinated departure means for anyone still running it.

L2TP/IPsec in plain English

Think of L2TP as a pipe buried between your device and the VPN server. It creates the path and provides the channel, but the pipe itself is open: anyone who can access it can see what flows through. IPsec is the lock fitted to that pipe. It encrypts everything inside so that the pipe can be intercepted but not read.

That two-part design — one protocol for the tunnel, a separate one for the security — is the defining characteristic of L2TP/IPsec. It is also the source of its double-encapsulation overhead, the reason a connection takes four phases to establish, and ultimately why platform vendors are moving away from it: modern protocols like IKEv2 and WireGuard combine the tunnel and the lock into a single layer, without the complexity and performance cost of stacking two independent protocols.

Quick facts

L2TP and IPsec: two separate protocols, one combined name

The slash in “L2TP/IPsec” reflects a genuine architectural split. They are two independent protocols, each doing a job the other cannot, combined because neither is sufficient on its own.

L2TP: the tunneling half

L2TP stands for Layer 2 Tunneling Protocol. As the name indicates, it operates at OSI Layer 2, the data link layer. Its job is to create a virtual point-to-point tunnel between two endpoints: the L2TP Access Concentrator (LAC) on the initiating side and the L2TP Network Server (LNS) on the receiving side.

L2TP provides tunneling. It does not provide encryption, authentication, or data integrity. A raw L2TP tunnel carries your traffic in an unprotected form — readable by anyone who can intercept it.

There are two models for how the tunnel gets established. In voluntary tunneling, the client device itself initiates the L2TP session and runs the L2TP stack directly: the standard model for VPN remote access. In compulsory tunneling, an ISP’s access server or NAS device creates the tunnel on the client’s behalf, without the client running any L2TP software at all. This second model is why L2TP persists in carrier infrastructure such as DSL aggregation even as it exits VPN use: the protocol was designed for both scenarios from the start.

L2TP also replaced its two predecessors: Microsoft’s PPTP and Cisco’s L2F. For a full look at PPTP and why it was retired, see the dedicated PPTP guide.

IPsec: the security half

IPsec (Internet Protocol Security) is the framework that provides what L2TP cannot. It supplies encryption via the Encapsulating Security Payload (ESP), key exchange via IKE (Internet Key Exchange), and data integrity via HMAC. In an L2TP/IPsec deployment, IPsec operates in transport mode, the mandatory configuration per RFC 3193 §2.1. Transport mode encrypts the packet payload while leaving the original IP header exposed, rather than wrapping the entire packet in a new outer header as tunnel mode does. Tunnel mode is permitted by the specification, but redundant: L2TP already handles the tunneling layer, so adding IPsec tunnel mode on top would simply double-wrap unnecessarily.

For IPsec’s full security architecture — including how ESP and AH compare and how Security Associations work — see IKEv2/IPsec Explained.

Why neither is enough alone

The combination is not redundancy. It is specialisation at two different protocol layers. IPsec operates at Layer 3 (the network layer); L2TP operates at Layer 2 (the data link layer). They cannot substitute for each other because they are not doing the same thing. L2TP provides the tunneling mechanism, the PPP framing, and the LAC/LNS session model. IPsec provides the encryption and authentication. Together, they produce a secure tunnel. Separately, they produce either an unprotected tunnel or security with no tunnel.

That structural combination is also the source of double encapsulation: two protocols, each doing a separate job, each adding its own header layer to every packet.

A brief history: where L2TP came from

The merger of PPTP and L2F (1999)

By the mid-1990s, two competing tunneling protocols had emerged. Microsoft led a vendor consortium (the PPTP Forum, which included Ascend, 3Com, ECI Telematics, and US Robotics) in developing PPTP, published as RFC 2637. Cisco independently developed L2F (Layer 2 Forwarding), a tunneling protocol with a different architecture focused on ISP use cases. The IETF worked to consolidate both into a single standard rather than maintaining two parallel protocols with overlapping purposes.

RFC 2661, published in August 1999, formalized L2TP as that consolidated standard. It combined features from PPTP and L2F into a new specification, with both Cisco and Microsoft as co-authors. The deliberate design choice was that L2TP would handle tunneling only, with security handled by a separate layer. RFC 3193 (“Securing L2TP using IPsec”), published in November 2001, formalized the L2TP/IPsec pairing.

L2TPv2 versus L2TPv3

RFC 2661 defines L2TPv2: PPP-based tunneling for VPN remote access, which is the subject of this article. RFC 3931 (March 2005) defined L2TPv3, which extended the protocol substantially for carrier use: it can tunnel Ethernet frames, VLANs, Frame Relay, and ATM across IP networks, enabling ISPs to build pseudowire services over their infrastructure. L2TPv3 is not a VPN protocol in the consumer or enterprise sense and is not covered here. When any VPN documentation refers to “L2TP,” it means L2TPv2.

How L2TP/IPsec works: the connection sequence

Establishing an L2TP/IPsec connection requires four sequential phases. No user data flows until all four are complete.

Phase 1: IKE negotiation (UDP 500)

Before any data moves, IKEv1 negotiates the IPsec Security Association between client and server. L2TP/IPsec was specified against IKEv1 in RFC 3193 (published in 2001, four years before IKEv2 existed), and implementations across all platforms universally use IKEv1. The negotiation runs on UDP port 500 initially; if either party detects a NAT device in the path, the exchange switches to UDP 4500 for NAT Traversal.

Authentication at this stage uses either a pre-shared key (PSK) or certificates. Most consumer and small business deployments use PSKs. Enterprise deployments use certificates. The security implications of this choice are substantial and covered in the security section below.

The full mechanics of the IKE handshake, including Phase 1 and Phase 2 message exchange and Diffie-Hellman key derivation, are explained in depth in IKEv2/IPsec Explained. Note that IKEv2 (covered in that article) improves on IKEv1 significantly in speed, security, and functionality; the L2TP/IPsec use of IKEv1 is one of the protocol’s structural limitations.

Phase 2: the ESP transport channel (IP Protocol 50)

Once IKE completes, IPsec’s Encapsulating Security Payload activates in transport mode. ESP is identified by IP Protocol 50, a protocol number at the IP layer rather than a TCP or UDP port number (just as TCP is IP Protocol 6). No tunneling is happening yet; no user data is flowing. The secure pipe is in place.

Phase 3: the L2TP tunnel (UDP 1701)

With the IPsec channel established, L2TP control messages begin on UDP 1701. Importantly, this traffic runs inside the encrypted ESP channel from Phase 2, so UDP 1701 is never directly exposed on the wire. A firewall passing L2TP/IPsec traffic needs UDP 500, UDP 4500, and IP Protocol 50 to be open; it does not need to pass UDP 1701 as a separate rule.

The LAC negotiates the L2TP tunnel with the LNS, then establishes a PPP (Point-to-Point Protocol) session inside that tunnel. PPP handles per-user authentication (PAP, CHAP, or MS-CHAPv2) and provides the Layer 2 framing for user data. L2TP inherited this PPP model from its predecessors, which is why the protocol terminates at Layer 2 and why it requires a separate security layer rather than building its own.

Phase 4: data flow

User traffic is encapsulated as a PPP frame, wrapped in an L2TP header, then encrypted and authenticated by IPsec ESP — wrapped twice before it leaves the device.

Double encapsulation: what is actually inside the packet

The anatomy of an L2TP/IPsec packet, from outermost to innermost layer:

Why two layers are structurally required

IPsec operates at Layer 3 (the network layer). L2TP operates at Layer 2 (the data link layer). They solve different problems at different levels of the protocol stack, and neither can substitute for the other. IPsec provides security: encryption, key exchange, and integrity. L2TP provides the Layer 2 tunneling mechanism, the PPP framing, and the LAC/LNS session model that allows the tunnel to carry multiple PPP sessions and support multi-protocol routing.

The performance cost is structural. Every outbound packet requires two complete processing passes: L2TP encapsulation first, then IPsec encryption and authentication. Every inbound packet requires two complete unwrapping passes in reverse. This overhead cannot be tuned away through configuration. It is inherent in combining two protocols that each add their own header layer to every packet.

Header overhead and MTU arithmetic

Double encapsulation is measurable. Every L2TP/IPsec packet on an IPv4 path with NAT Traversal carries approximately 68 bytes of protocol overhead before and after the payload. Here is the per-layer breakdown compared to the two most common alternatives:

Two things stand out from those figures. First, the raw byte overhead of L2TP/IPsec (~68 B) is not dramatically larger than WireGuard (~60 B). The header cost is real but not the primary source of the performance gap. Second, L2TP/IPsec requires two processing passes per packet while both alternatives require one. That difference in CPU work per packet, compounded across high-throughput connections without hardware offloading, is where most of the performance penalty originates.

The practical consequence of the reduced effective MTU is that TCP segments sized for a standard 1500-byte Ethernet path will exceed the tunnel’s capacity. Applying an MSS clamp of 1,392 bytes to TCP SYN packets at the VPN gateway prevents oversized segments from entering the tunnel entirely.

Comparison with single-encapsulation protocols

IKEv2/IPsec in tunnel mode wraps the entire original packet once inside the ESP tunnel: one processing pass, one set of headers. WireGuard applies a single outer IP/UDP header plus ChaCha20-Poly1305 encryption in one kernel-space operation. L2TP/IPsec requires both the L2TP layer and the IPsec layer, each doing a full pass.

L2TP/IPsec vs the modern alternatives

Here is how L2TP/IPsec compares to its three most common replacements on the dimensions that matter for migration decisions. For a full comparison across speed, battery, and firewall traversal, see VPN Protocols Explained.

Ports, NAT traversal, and firewall behaviour

A practical note on UDP 1701: L2TP’s control and data traffic uses this port internally, but it travels inside the encrypted ESP channel from Phase 2 and never appears as plaintext UDP 1701 on the wire. Firewall rules for L2TP/IPsec need to pass UDP 500, UDP 4500, and IP Protocol 50. UDP 1701 does not need to be opened on the perimeter.

The NAT problem

ESP (IP Protocol 50) has no port numbers. NAT devices work by tracking connections through port mappings, and they cannot track a connectionless protocol with no ports. When ESP packets pass through a NAT device, the device has no mechanism to route the return traffic correctly, and the connection silently fails.

NAT Traversal solves this by wrapping ESP inside UDP 4500, giving the NAT device a port it can track. The negotiation is handled by RFC 3947; the encapsulation format is defined in RFC 3948. Most real-world L2TP/IPsec deployments end up using UDP 4500 rather than IP Protocol 50, because most users are behind at least one NAT device. This adds yet another header layer to packets that are already heavily wrapped.

The Windows NAT registry fix

Windows clients have an additional NAT traversal complication that has existed since Windows XP and remains present in Windows 11. By default, Windows blocks IPsec NAT-T when the client itself is behind NAT. The fix requires a registry modification:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent
Value: AssumeUDPEncapsulationContextOnSendRule (DWORD)
  0 = default (no NAT-T security associations permitted when server is behind NAT)
  1 = server is behind NAT
  2 = both client and server behind NAT

Value 2 covers the most common scenario: a home or office network where both the Windows client and the VPN server sit behind NAT devices. A system restart is required after the change. This is originally documented in Microsoft KB 926179 and applies to Windows 10 and Windows 11. IKEv2 eliminated this requirement by building NAT-T directly into its core specification.

Why fixed ports mean easy blocking

UDP 500, UDP 4500, and IP Protocol 50 are fixed, well-known, non-standard values. Any firewall can target them with a single rule. Unlike OpenVPN’s TCP port 443 mode, which makes VPN traffic appear identical to standard HTTPS to a stateless firewall, L2TP/IPsec has no obfuscation capability and no TCP-443 fallback. A network administrator can disable all L2TP/IPsec traffic with two firewall rules. A censorship system can do it at national scale in minutes. For a full explanation of DPI-based VPN detection and what obfuscation techniques address it, see What Is an Obfuscated VPN?

Security: four concerns worth understanding clearly

L2TP/IPsec’s security profile is not a single verdict. “No known practical break for a typical enterprise user” and “inappropriate for anyone facing state-level adversaries” can both be accurate at the same time. The four concerns below apply differently depending on your threat model.

1. AES-256-CBC: strong cipher, older architecture

L2TP/IPsec’s primary encryption cipher is AES-256-CBC. The 256-bit key provides no known practical brute-force vulnerability: that part of the security story is sound. The limitation is in the mode. CBC (Cipher Block Chaining) is not an AEAD cipher. It encrypts data but does not authenticate it in a single pass; a separate HMAC operation provides integrity as a second step. This two-pass architecture is what modern AEAD ciphers (AES-256-GCM, ChaCha20-Poly1305) replaced. In 2026, AES-256-CBC remains in widespread use and has no known practical break in VPN deployments, but AEAD is the architecturally correct choice for any new configuration. For the full explanation of what AEAD mode provides and why the mode suffix matters more than the key length, see VPN Encryption Explained.

2. The pre-shared key problem and CVE-2018-5389

Most consumer and small business L2TP/IPsec deployments authenticate IKEv1 with a pre-shared key. PSK authentication has two distinct vulnerability modes in IKEv1.

IKEv1 Aggressive Mode has been known for years to expose the PSK-derived hash before the encrypted channel is established. A passive attacker who captures the IKE negotiation can attempt an offline dictionary attack against the hash to recover the PSK. Aggressive Mode is inherently vulnerable to offline cracking.

IKEv1 Main Mode was long considered safer because the identity exchange runs inside the encrypted channel. CVE-2018-5389 (CVSS 5.9, published 2018-09-06, Felsch et al., USENIX Security 2018) established that Main Mode is also vulnerable to offline dictionary attack given an active man-in-the-middle position. The attacker must be able to intercept and modify IKE traffic, but once positioned, they can capture the material needed to crack the PSK offline.

A separate and common failure mode is specific to deployment practice rather than the protocol itself: many VPN providers, router manufacturers, and IT guides publish their PSKs publicly or use generic defaults across customers. A PSK authenticates the IKE connection, not the data channel. An attacker who knows the PSK can impersonate the VPN server, establish an IKE session with the client, and intercept traffic. Certificate-based authentication eliminates this attack surface entirely: the private key never leaves the device and cannot be captured for offline cracking.

3. The 1024-bit Diffie-Hellman precomputation problem

IKEv1 implementations historically defaulted to DH Group 2 (1024-bit MODP) for key exchange. Group 2 is the specific point of concern raised by Adrian et al. in “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice” (ACM CCS 2015, weakdh.org). The paper’s core finding was that a nation-state actor with sufficient hardware investment could precompute lookup tables for specific 1024-bit DH primes. Because IKE has historically used a small set of well-known primes, those tables, once built, would allow passive decryption of traffic using those primes. The paper found that 66.1% of profiled IKEv1 servers preferred Oakley Group 2 (1024-bit MODP), meaning that breaking a single 1024-bit prime would allow passive decryption of approximately 66% of IKE-based IPsec VPN traffic at the time of writing.

Two precisions matter here. First, this concern applies to IKE wherever a weak DH group is negotiated: IKEv2 configured with Group 2 carries the same risk, though current IKEv2 implementations default to Group 14 (2048-bit) or higher. L2TP/IPsec using IKEv1 with a Group 2 default is the historically common vulnerable configuration. Second, the paper’s authors noted that NSA’s documented VPN-decryption capabilities, visible in materials published by Der Spiegel in December 2014, are consistent with a 1024-bit DH precomputation break. This is the researchers’ inference from the available evidence, not a confirmed technical fact.

For most enterprise users whose adversaries do not include nation-state actors, this concern is not operationally relevant today. For anyone facing state-level adversaries, it is a material risk. For the mechanics of how ephemeral key exchange delivers forward secrecy — and why DH group selection determines whether that protection holds — see Perfect Forward Secrecy in VPNs.

4. The NSA and deliberate-weakening allegations

Der Spiegel’s December 2014 report “Prying Eyes: Inside the NSA’s War on Internet Security” described leaked documents showing NSA capturing IKE and ESP handshake traffic and passing it to high-performance computing systems to recover session keys. The documents do not specify the cryptographic method used; the technique is presented as classified capability rather than explained in the published materials.

In September 2013, following the initial Snowden disclosures, John Gilmore (EFF co-founder, and founder and principal funder of the FreeS/WAN Linux IPsec project) published a detailed argument that the IPsec standard was deliberately weakened. Gilmore was adjacent to the IETF IPsec working group through FreeS/WAN and observed NSA employees holding editorial and leadership roles. His specific claims were that the standard was made deliberately over-complex, making it difficult for cryptographers to evaluate, and that mandatory support for weak options (NULL encryption, single-DES, a 768-bit DH group) was embedded in the specification to enable downgrade attacks. He spoke out publicly in 2013, not contemporaneously during 1990s standardisation.

The calibrated verdict by threat model: a typical enterprise user maintaining a legacy L2TP/IPsec deployment, with no state-level adversaries in their threat model, faces no known practical break of well-configured AES-256-CBC L2TP/IPsec. The concerns above are real but do not translate into an immediate operational risk for that user profile. A journalist, activist, political dissident, or anyone with documented state-level adversaries should not use L2TP/IPsec. The combination of CVE-2018-5389, the 1024-bit DH precomputation risk, and the NSA capability context all point toward IKEv2 with certificate authentication or WireGuard as the appropriate tools for that threat model.

Performance: the cost of running two protocols in sequence

The double encapsulation overhead

Every outbound packet requires two full processing passes: L2TP encapsulation (PPP framing plus L2TP header) and IPsec encryption and authentication (AES-CBC plus HMAC). Every inbound packet requires two full decryption and unwrapping passes in reverse. This is not a configuration problem. It is structural, inherent in combining two protocols that each process every packet independently.

No equivalent hardware offloading

Modern IKEv2 implementations and WireGuard are designed to take full advantage of hardware-accelerated AES (AES-NI, available on virtually all mainstream processors since the mid-2010s) and kernel-space processing. WireGuard runs entirely in the operating system kernel. IKEv2 on modern systems can offload cryptographic operations to hardware with measurable throughput gains.

L2TP/IPsec’s IKEv1 implementation and its userspace daemon architecture (xl2tpd on Linux, the legacy RRAS stack on Windows) do not benefit from equivalent optimisation. IKEv1’s handshake also takes more round trips to complete: Main Mode requires 6 Phase 1 messages plus 3 Quick Mode messages (9 total), and Aggressive Mode requires 3 plus 3 (6 total), compared to IKEv2’s 4-message completion. This slower handshake produces a measurably longer initial connection establishment. For the full IKEv1 versus IKEv2 comparison, see IKEv2/IPsec Explained.

MTU and TCP MSS clamping

Double encapsulation reduces the effective tunnel MTU to approximately 1,432 bytes on a standard 1,500-byte Ethernet path (see the overhead table in Section 4 for the byte-by-byte breakdown). Without adjustment, large TCP segments exceed this limit. The symptom is consistent: small pages load correctly while large file transfers stall or fail, because the size limit only bites on larger packets. Applying a TCP MSS clamp of 1,392 bytes at the VPN gateway corrects this. On Linux, a single iptables rule handles it; on router firmware, a dedicated MSS clamping setting is typically available in the VPN configuration panel.

Platform support and the industry-wide deprecation

Google and Android (2021–2022)

The Android removal happened in two stages. Android 12 (released October 2021) removed L2TP/IPsec from the native VPN client’s “Add connection” interface: only IKEv2/IPsec variants remained selectable for new connections. Android 13 (2022) removed the legacy VPN stack entirely, making existing L2TP/IPsec profiles non-functional. There was no formal Google deprecation announcement; the change is documented through AOSP behaviour, vendor advisories (including Fortinet technical notes), and community forum records. Android 12 is now three major versions behind the current release, and no subsequent version has re-added native L2TP support.

Microsoft (October 2024)

Microsoft published “PPTP and L2TP deprecation: A new era of secure connectivity” on the Windows Server News and Best Practices TechCommunity blog on October 8, 2024. The announcement states that future versions of Windows RRAS Server will no longer accept incoming connections using PPTP or L2TP — and this has already begun: Windows Server 2025 does not enable PPTP or L2TP by default in new RRAS installations. Outgoing client connections from Windows 10 and 11 machines remain supported. Microsoft’s stated rationale covers both security concerns (misconfiguration risk, L2TP’s lack of built-in encryption) and the availability of stronger replacements. The recommended migration targets are IKEv2 and SSTP, with IKEv2 as the preferred path for most environments.

Apple and macOS 26 Tahoe (September 2025)

Apple’s approach was more oblique than a direct removal of L2TP support. macOS 26 Tahoe and iOS 26 (both released September 15, 2025) removed a set of legacy IPsec cryptographic algorithms from the system’s shared cryptographic library: DES, 3DES, SHA1-96, SHA1-160, and Diffie-Hellman groups below Group 14 (2048-bit MODP). Apple’s enterprise release notes frame the change specifically as affecting IKEv2 VPN connections (note 148767790) — the documentation does not explicitly name L2TP/IPsec. However, the removal affects the shared IPsec stack that both IKEv2 and L2TP/IPsec draw on, and the practical impact on L2TP/IPsec is confirmed by third-party gateway vendors (VPN Tracker, Fortinet, Cisco compatibility advisories). L2TP/IPsec gateways that negotiate using 3DES, SHA-1, or DH groups below Group 14 (the majority of older enterprise gateways and consumer router implementations) will fail at the cryptographic negotiation stage on macOS 26 and iOS 26 clients. The L2TP configuration option in System Settings is not removed; the connection attempt proceeds and then fails on cipher negotiation.

The pattern across three vendors is distinct but the outcome is consistent. Google removed the user-facing interface. Microsoft deprecated the server-side acceptance. Apple removed the cryptographic primitives the protocol depends on. Three different technical mechanisms, all pointing the same direction across a four-year window.

Common L2TP/IPsec errors and what they mean

Most L2TP/IPsec failures resolve to one of five recurring root causes, each with a distinctive error signature on the client side. The table below covers the most common ones.

Should you still use L2TP/IPsec? A verdict by user type

The right answer depends on who you are, what you are maintaining, and what adversaries you are protecting against.

Legacy IT administrator maintaining existing infrastructure

Verdict: Defensible to maintain in the short term. Plan migration before the next major release cycle.

L2TP/IPsec is functional today for typical enterprise threat models. What creates genuine urgency is the platform trajectory: future Windows Server versions will reject incoming connections, macOS 26 Tahoe and iOS 26 clients may already be failing against gateways using 3DES or SHA-1, and Android users have been unable to connect natively for three years.

A practical migration checklist for Windows Server RRAS environments:

1. Stand up a Certificate Authority if one does not already exist. IKEv2 with certificate authentication is Microsoft’s recommended replacement. Easy-RSA or a Windows Server CA both work.
2. Issue server and client certificates. The server certificate must carry the Server Authentication EKU. Client certificates are required only for certificate-based mutual authentication; EAP-MSCHAPv2 is the simpler path for existing username/password deployments.
3. Configure IKEv2 on the RRAS server. Add IKEv2 as a permitted protocol alongside L2TP/IPsec — do not remove L2TP yet.
4. Distribute client profiles. For Windows clients: the built-in VPN client supports IKEv2 without any additional software. For macOS clients: IKEv2 is also built in. For Android: IKEv2/IPsec PSK or certificate connections are available natively from Android 12.
5. Validate and run parallel. Keep L2TP/IPsec active during the transition period. Confirm IKEv2 connections are stable for each client group before cutting over.
6. Remove L2TP/IPsec from the RRAS configuration once all clients have migrated. This completes the transition before a future Windows Server release forces it.

An alternative migration path for environments with heterogeneous clients — Windows machines on SSTP, mobile devices on L2TP, Linux workstations on OpenVPN — is to consolidate all protocols behind a single SoftEther VPN Server, which accepts all five protocol types simultaneously without separate server instances.

For the full IKEv2 architecture, see IKEv2/IPsec Explained. For a comparison of all current protocol options, see VPN Protocols Explained.

Consumer VPN user choosing a protocol in the app settings

Verdict: Do not choose L2TP/IPsec if WireGuard or IKEv2 are available.

Every reputable VPN provider supports WireGuard or IKEv2, and both are better choices in every measurable dimension. A provider still offering L2TP/IPsec as a primary or default protocol option in 2026 is signalling that the protocol stack has not been updated recently. If L2TP/IPsec is the only option available, that is a reason to evaluate whether the provider itself is current enough to trust. If for some reason you do use it, verify that the provider uses certificate authentication rather than a publicly distributed PSK.

High-risk user: journalist, activist, or dissident

Verdict: Do not use L2TP/IPsec.

CVE-2018-5389, the 1024-bit DH precomputation risk, and the documented NSA capability context all converge on the same conclusion for anyone whose threat model includes state-level adversaries. The protocol’s IKEv1 foundation, combined with its historical DH Group 2 defaults, puts it precisely in the vulnerable category identified by the published academic analysis of nation-state VPN decryption capabilities.

The minimum acceptable option for this threat model is IKEv2 with certificate authentication through a provider with an independently verified no-log policy. WireGuard through a provider that has addressed the static peer table privacy issue (Mullvad and ProtonVPN have both published their approaches) is the stronger option. See IKEv2/IPsec Explained for the certificate authentication model, and WireGuard Explained for the privacy architecture considerations.

ISP and carrier deployments

Verdict: L2TP without IPsec remains in active, legitimate use here. This is a different use case.

Compulsory L2TP tunneling is widely used in DSL aggregation, broadband wholesale, and carrier-grade infrastructure, typically without IPsec, because the transport layer in those environments is trusted by design. This is not a VPN use case in the consumer or enterprise sense. The deprecation narrative above does not apply here. L2TP’s persistence in carrier infrastructure reflects its original design for exactly this role.

Frequently asked questions

What is L2TP/IPsec?

L2TP/IPsec is a VPN protocol formed by combining two independent standards. L2TP (Layer 2 Tunneling Protocol, RFC 2661) creates a virtual tunnel between two endpoints but provides no encryption on its own. IPsec (Internet Protocol Security) provides the encryption, key exchange, and integrity checking that L2TP lacks. The combination pairs L2TP’s tunneling capability with IPsec’s security framework to produce an encrypted VPN connection. It was the dominant enterprise remote-access VPN protocol for much of the 2000s and 2010s and is now in the process of being retired by all major platform vendors.

Why does L2TP need IPsec?

L2TP was designed as a pure tunneling protocol with no built-in security. RFC 3193 (November 2001) formally established the L2TP/IPsec pairing as the intended deployment model: the security layer was always meant to come from IPsec, not from L2TP itself. A raw L2TP tunnel carries traffic in cleartext. IPsec adds the encryption (via ESP), the key exchange (via IKE), and the integrity verification (via HMAC) that make the combination usable as a private network. Without IPsec, L2TP is a tunnel with no lock on it.

How does L2TP/IPsec establish a connection?

The connection happens in four sequential phases. First, IKEv1 negotiates the IPsec Security Association over UDP 500 (or UDP 4500 if NAT is detected), establishing the encrypted control channel. Second, IPsec ESP activates in transport mode on IP Protocol 50, creating an encrypted path between client and server. Third, L2TP control messages run over UDP 1701 inside that ESP channel, and the LAC negotiates a tunnel with the LNS followed by a PPP session. Fourth, user data flows through all layers simultaneously: each packet is PPP-framed, wrapped in an L2TP header, then encrypted and authenticated by IPsec. No data moves until all four phases are complete.

What ports does L2TP/IPsec use?

L2TP/IPsec uses four values: UDP 500 for IKE negotiation, IP Protocol 50 for the ESP data channel (a protocol number, not a port), UDP 4500 for NAT Traversal when either endpoint is behind NAT, and UDP 1701 for L2TP control and data traffic. UDP 1701 is carried inside the encrypted ESP tunnel and is not directly exposed on the wire; perimeter firewalls only need to pass UDP 500, UDP 4500, and IP Protocol 50. On Windows clients behind NAT, a registry key change (AssumeUDPEncapsulationContextOnSendRule = 2) is required before the connection will establish.

Is L2TP/IPsec still safe to use in 2026?

The answer depends on your threat model. For a typical enterprise user with no state-level adversaries, L2TP/IPsec using AES-256-CBC and certificate authentication has no known practical break in 2026. For a user whose adversaries include nation-state actors: no, it is not safe. CVE-2018-5389 demonstrated that both IKEv1 authentication modes are vulnerable to offline dictionary attacks under specific conditions, and academic analysis of the NSA’s documented VPN decryption capabilities points to the 1024-bit Diffie-Hellman precomputation break as a plausible mechanism. These are not theoretical concerns for users facing state-level adversaries. IKEv2 with certificate authentication or WireGuard are the appropriate replacements.

What is the 1024-bit Diffie-Hellman problem in L2TP/IPsec?

IKEv1 implementations historically defaulted to DH Group 2, which uses 1024-bit MODP Diffie-Hellman for key exchange. Adrian et al. in “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice” (ACM CCS 2015) demonstrated that a nation-state actor with sufficient hardware investment could precompute lookup tables for common 1024-bit DH primes. The paper found that 66.1% of profiled IKEv1 servers preferred Oakley Group 2 (1024-bit MODP), meaning that breaking a single 1024-bit prime would allow passive decryption of approximately 66% of IKE-based IPsec VPN traffic. This concern applies to IKE in general wherever a weak group is negotiated; IKEv1 defaults to Group 2 are the historically common vulnerable case. IKEv2 with Group 14 (2048-bit) or higher is not affected.

Did Microsoft, Apple, and Android all deprecate L2TP/IPsec?

Yes, across a four-year window and through three distinct mechanisms. Android 12 (2021) removed L2TP from the native VPN client UI; Android 13 (2022) removed the legacy stack entirely. Microsoft published its formal deprecation in October 2024, stating that future Windows Server RRAS versions will not accept incoming L2TP connections. macOS 26 Tahoe (September 2025) removed 3DES, SHA-1, and DH groups below Group 14 from its cryptographic library, which breaks L2TP/IPsec connections to gateways using those algorithms. Each vendor took a different technical approach, but the direction is consistent across all three.

What is the difference between L2TP/IPsec and IKEv2/IPsec?

Both use IPsec as their security framework, but they differ in almost every other dimension. L2TP/IPsec adds a tunneling layer (L2TP) that produces double encapsulation and uses IKEv1 for key exchange, which is slower and less secure than its successor. IKEv2/IPsec uses IPsec in tunnel mode directly without a separate tunneling layer, completing the handshake in 4 messages versus IKEv1’s 6–9, and includes MOBIKE for seamless network transitions on mobile. IKEv2 is the protocol Microsoft recommends for migrating away from L2TP/IPsec. For the full IKEv2 architecture, see IKEv2/IPsec Explained.

How does L2TP/IPsec compare to WireGuard?

WireGuard replaces almost everything L2TP/IPsec does with a simpler, faster, more modern design. Where L2TP/IPsec stacks two protocols (producing double encapsulation and two processing passes per packet), WireGuard is a single kernel-space protocol that encrypts and routes in one operation. Where IKEv1 requires 6–9 messages, WireGuard’s handshake requires 2. Where L2TP/IPsec uses AES-256-CBC (non-AEAD), WireGuard uses ChaCha20-Poly1305 (AEAD). The only dimension where L2TP/IPsec has any practical advantage is native availability on older hardware routers that do not support WireGuard. For everything else, WireGuard is the correct replacement. For the full WireGuard architecture, see WireGuard Explained.

How do I migrate from L2TP/IPsec to IKEv2?

For a Windows Server RRAS environment, the migration involves six steps: (1) set up a Certificate Authority if one does not exist; (2) issue server and client certificates; (3) add IKEv2 as a permitted protocol on the RRAS server while keeping L2TP active; (4) distribute IKEv2 connection profiles to clients — Windows 10/11, macOS, and Android 12+ all support IKEv2 natively without additional software; (5) run both protocols in parallel and validate IKEv2 stability across all client groups; (6) remove L2TP/IPsec from the RRAS configuration once all clients have migrated. The IT administrator verdict section above has the full checklist. For the IKEv2 handshake, authentication methods, and certificate requirements, see IKEv2/IPsec Explained.

Why did Apple and Android remove native L2TP support?

Neither company published a detailed technical rationale. Android’s removal followed the broader trend of modernising the built-in VPN client to support only IKEv2/IPsec for new connections, reflecting Android’s shift toward enterprise-focused VPN capabilities. Apple’s macOS 26 Tahoe and iOS 26 releases (both September 15, 2025) were framed as security hardening measures: dropping legacy algorithms (3DES, SHA-1, weak DH groups) that no longer meet current security standards. Apple’s release notes document the change explicitly for IKEv2 VPNs (note 148767790), and the downstream effect on L2TP/IPsec — which depends on those same algorithms in common gateway configurations — is confirmed by third-party VPN vendors. iOS 18 and earlier retain native L2TP/IPsec support; iOS 26 does not support connections to legacy gateways using the removed algorithms.

Can I still use L2TP/IPsec on Windows 11?

Yes, for outgoing client connections. Windows 11, including the 24H2 release, still offers L2TP/IPsec (both PSK and certificate variants) in Settings → Network and Internet → VPN → Add a VPN connection. Microsoft’s October 2024 deprecation covered incoming connections on Windows Server RRAS, not outgoing connections from Windows clients. If you connect from a Windows 11 machine to a corporate or personal VPN server using L2TP/IPsec, that configuration continues to work. If you are running a Windows Server RRAS setup accepting incoming L2TP connections, migration to IKEv2 or SSTP is warranted before future Windows Server versions remove that server-side capability.