Learn L2TP IPsec - History, Background & Why L2TP/IPsec

#Introduction

Every major technology is born from a real problem. L2TP/IPsec emerged in the late 1990s when companies wanted employees outside the office to keep accessing internal networks securely over the internet — without having to lease expensive dedicated lines. Episode 1 opens that journey: how VPNs evolved, why L2TP was created, and the key decision to combine it with IPsec.

Understanding history is not mere nostalgia. Many L2TP/IPsec design decisions — such as why it needs two protocols at once, why UDP port 1701 is used, or why NAT Traversal is required — only make sense when you know where this technology came from. Let us start at the very beginning of the VPN evolution.

#VPN Evolution: From PPTP to L2TP

#PPTP: The Commercial Pioneer

In 1996, Microsoft released PPTP (Point-to-Point Tunneling Protocol). PPTP combines PPP with GRE (Generic Routing Encapsulation) and carries PPP across IP networks. Unfortunately, PPTP's built-in authentication proved weak — MPPE, which uses RC4, was easily attacked — and the protocol itself had no solid key exchange mechanism. PPTP became popular because it shipped inside Windows, but it was cryptographically fragile.

#L2F: Cisco's Answer

On the other side, Cisco developed L2F (Layer 2 Forwarding) for centralized dial-in solutions. Instead of encrypting, L2F focused on forwarding Layer 2 frames between gateways. A standards war emerged: Microsoft used PPTP, Cisco used L2F, and devices from different vendors could not talk to each other.

#L2TP: Consolidating Two Worlds

In 1999, the IETF merged PPTP and L2F into L2TP (Layer 2 Tunneling Protocol) through RFC 2661. L2TP took the tunneling concept from L2F and wrapped PPP like PPTP, but sent data over UDP port 1701 — not GRE. The goal: one open standard usable across vendors such as Cisco, Microsoft, and Juniper.

You can remember the evolutionary sequence as follows:

PPTP (1996, Microsoft) -> L2F (Cisco) -> L2TP (1999, RFC 2661)
Pure L2TP (no encryption) -> L2TP/IPsec (2001, RFC 3193)

#Problems Solved by L2TP

#Vendor-Neutral Layer 2 Tunneling

The main problem before L2TP: there was no standard way to carry Point-to-Point connections across IP networks across vendors. L2TP solved this by defining two roles: LAC (L2TP Access Concentrator) on the client side and LNS (L2TP Network Server) on the server side. The two build an L2TP tunnel containing one or more PPP sessions.

#PPP Authentication Support

Because L2TP wraps PPP, the entire PPP authentication ecosystem comes along: PAP, CHAP, MS-CHAPv2, and EAP. This is why L2TP feels natural to enterprises — users keep using the same username and password as their dial-up connections, and it can be mapped to RADIUS or LDAP. We will cover the details in episodes 7 and 11.

#Why L2TP Must Be Combined with IPsec

#Pure L2TP Does Not Encrypt

This is the most important point: pure L2TP provides no encryption or data authentication. PPP frames are sent in cleartext over UDP 1701. Anyone who can intercept the network can read the entire VPN traffic. L2TP only provides tunneling — carrying packets from point A to point B — without protecting their contents.

#IPsec Provides the Missing Security

IPsec offers full encryption and authentication at Layer 3, but its configuration is complex and its model is less natural for supporting thousands of dial-in users. The solution: combine both. IPsec handles security, L2TP handles Layer 2 tunneling and user authentication. This combination was standardized in RFC 3193 in 2001, which defines how L2TP runs over ESP in tunnel mode.

As a result, UDP port 1701 for L2TP is locked behind ESP, and IKE negotiates to secure the connection before L2TP starts its tunnel:

PPP -> L2TP (UDP 1701) -> ESP (IPsec, tunnel mode) -> IP

#L2TP/IPsec's Position Today

L2TP/IPsec is now more than two decades old, and security observers often rate it weak compared to modern standards. It is still used because of its native support on all operating systems — iOS, Android, Windows, and macOS — without needing additional applications, making it a practical choice for remote access. However, because IKEv1 with PSK and MS-CHAPv2 have weaknesses, many practitioners recommend migrating to pure IKEv2 or WireGuard.

We will measure all of this objectively in episode 13 (security) and episode 22 (modern comparison). For now, one important fact: understanding L2TP/IPsec means understanding that every PPP frame you send is wrapped twice — once by L2TP, once by ESP. This wrapping order is what we will dissect in episode 2.

#Two Documents That Build the Foundation

#RFC 2661 and RFC 3193

Two standards documents form the backbone of L2TP/IPsec. RFC 2661, published in 1999, defines L2TP itself: message structure, control connection mechanism, and how data messages are wrapped. RFC 3193, published in 2001, adds the next chapter: how L2TP runs inside ESP, which encapsulation modes are allowed, and how UDP port 1701 is locked by IPsec.

You can read both documents directly from the official source:

curl -O https://www.rfc-editor.org/rfc/rfc2661.txt
curl -O https://www.rfc-editor.org/rfc/rfc3193.txt

The command curl -O https://www.rfc-editor.org/rfc/rfc2661.txt downloads the official document to the working directory. Both are worth reading at least once — especially the "Security Considerations" section of RFC 3193, which explicitly explains why L2TP needs IPsec.

#Why UDP 1701 Is Not a Shortcoming

A question that often comes up: why does L2TP use UDP, when UDP does not guarantee packet delivery? The answer lies in L2TP's design. Control messages implement their own reliability with sequence numbers and acknowledgments, while data messages genuinely do not need to be reliable — that is handled by the layers above, such as TCP running inside PPP.

By choosing UDP, L2TP avoids unnecessary layered transport overhead. This is an important pattern: every protocol makes its own trade-off. L2TP chose UDP for simplicity, then hands reliability to the layers that actually need it.

#Reading Standards Documents

There is no better way to understand L2TP/IPsec than reading its specification. When reading the RFCs, pay attention to three things:

• Control messages: how SCCRQ and its companions build the tunnel.
• Data payload: how PPP frames are wrapped and sent.
• The IPsec combination: how RFC 3193 connects the two protocols.

Detailed discussion of each mechanism will accompany us in episodes 2, 4, and 7. For now, just note that these two RFCs are the official references you can always return to.

#Closing

Episode 1 gave you the historical context: L2TP was born from the consolidation of PPTP and L2F in RFC 2661, then combined with IPsec in RFC 3193 because pure L2TP encrypts nothing. You also saw why this combination became popular in the enterprise and why it is starting to be abandoned.

Key takeaways:

• VPN evolution: PPTP (1996), L2F (Cisco), then L2TP (RFC 2661, 1999).
• L2TP merged PPTP and L2F tunneling into one vendor-neutral standard.
• Pure L2TP is insecure: no encryption, no data authentication.
• IPsec provides the security L2TP lacks.
• RFC 3193 (2001) standardized L2TP/IPsec: L2TP inside ESP tunnel mode.
• Native support on all OSes keeps L2TP/IPsec in use to this day.

In the next episode, episode 2, we will dissect the core concepts and main architecture — how LAC and LNS communicate through the control connection and data messages, how IKE builds keys, and how ESP protects PPP frames inside tunnel mode. These are the technical foundations used throughout the entire series.