Learn L2TP IPsec - Core Concepts & Main Architecture

#Introduction

Now that you understand the history, it is time to understand the anatomy. Episode 2 dissects L2TP/IPsec as a system — not just a collection of daemons — focusing on how the protocols work and how they are assembled into a single stack. This understanding is the key to reading logs, choosing configuration options, and solving problems in the episodes that follow.

L2TP/IPsec involves two major protocols: L2TP which handles Layer 2 tunneling, and IPsec which handles security. They work at different layers with different responsibilities, but they collaborate closely. Let us dissect each one, then reassemble them as a single unit.

#The L2TP Protocol: Layer 2 Tunneling

#The Roles of LAC and LNS

L2TP defines two endpoints of a connection. The LAC (L2TP Access Concentrator) is usually on the user side — a home device or software client — and is the entry point for traffic. The LNS (L2TP Network Server) sits on the corporate network side and is the tunnel endpoint, where PPP sessions are terminated and injected into the internal network. In your lab, the client from episode 0 is the LAC and the server is the LNS.

#Control Connection and Data Messages

L2TP distinguishes two types of messages. The Control Connection manages the tunnel itself: establishment via the SCCRQ, SCCRP, and SCCCN messages, and session establishment via ICRQ, ICRP, and ICCN. These messages must be reliable and are answered with acknowledgments. By contrast, the Data Message carries the PPP payload and receives no acknowledgment — similar to plain UDP. This is why L2TP uses UDP 1701: data is sent without reliability overhead, while control uses its own sequence numbers.

The order of tunnel and session establishment:

Tunnel : SCCRQ -> SCCRP -> SCCCN
Session: ICRQ  -> ICRP  -> ICCN
Then   : PPP negotiation (LCP, CHAP/MS-CHAPv2, IPCP)

#The IPsec Protocol: Layer 3 Security

#IKE: Key Exchange

IKE (Internet Key Exchange) is the protocol responsible for building a Security Association (SA): an agreement on algorithms, shared keys, and security parameters between two hosts. IKE runs on UDP 500 and, once NAT traversal is active, moves to UDP 4500. There are two versions — IKEv1 and IKEv2 — which we will compare thoroughly in episode 4. IKE produces the encryption keys that ESP will later use.

#ESP: Data Encryption

ESP (Encapsulating Security Payload) is the protocol that actually encrypts and authenticates data. ESP runs directly over IP with protocol number 50 and provides both confidentiality (encryption) and integrity (authentication). In L2TP/IPsec setups, ESP is always used in tunnel mode — it wraps the entire IP packet, including the original header. The transport mode versus tunnel mode comparison is in episode 5.

#Assembling the L2TP/IPsec Stack

#PPP inside L2TP inside ESP

When a client sends data, the flow from the inside out is: the PPP frame is wrapped by L2TP as a Data Message, L2TP is wrapped in UDP port 1701, UDP is wrapped by ESP in tunnel mode, and finally it is wrapped in the original IP that carries the packet across the internet.

The stack from the inside out:

+--------------------------+
| PPP frame                |
+--------------------------+
| L2TP header (UDP 1701)   |
+--------------------------+
| ESP header + trailer     |
+--------------------------+
| Outer IP header          |
+--------------------------+

Each layer adds overhead, and this total overhead is the basis for the MTU calculation in episode 15. Think of the PPP frame as a letter in an L2TP envelope, that envelope placed inside a locked ESP box, and that box delivered in an outer IP packet.

#System Components on the Server Side

On the Linux server side, the L2TP/IPsec architecture is realized by three daemons working together:

• IKE daemon — pluto in Libreswan or charon in strongSwan — handles IKE negotiation and builds the IPsec SAs.
• xl2tpd — the L2TP daemon that listens on UDP 1701 and implements the LNS role.
• pppd — the PPP daemon that manages sessions, authentication, and the ppp0 interface at the LNS endpoint.

When a client connects, the IKE daemon builds the IPsec SAs first. Once the UDP 1701 path is secured, xl2tpd accepts the control connection and session, then hands the data to pppd. The ppp0 interface produced by pppd becomes the gateway for client traffic into the internal network.

Check the role of each service on your system:

systemctl status ipsec
systemctl status xl2tpd
ip addr show ppp0

The command systemctl status ipsec shows the status of the IKE daemon. If ppp0 does not appear when there is no client, that is normal — the interface is created dynamically while a session is active.

#The Journey of a Packet

#From Application to the Internet

Let us follow one packet from an application on the client to the server. When an application sends data, the kernel stack wraps it in a PPP frame. The PPP frame is then wrapped by L2TP as a data message, wrapped again in UDP with source and destination port 1701, protected by ESP with an SPI and sequence number, and finally wrapped in an outer IP header that carries the packet across the internet.

The steps from the inside out:

1. Application: user data (application TCP/UDP)
2. PPP        : PPP frame adds the PPP header
3. L2TP       : data message adds the L2TP header
4. UDP        : UDP header with port 1701
5. ESP        : encrypts and authenticates the entire payload
6. Outer IP   : routed across the internet

On the server side, the process is reversed: the outer IP and ESP headers are removed, UDP 1701 is forwarded to xl2tpd, L2TP extracts the PPP frame, and pppd hands the data to an application on the internal network. Understanding this order lets you predict which layer a problem belongs to — for example, why tcpdump on the server shows UDP 1701 even though the application is sending TCP.

#Practical Consequences of Encapsulation

Each layer adds headers, and that brings two consequences. First, the packet size grows, so the tunnel's effective MTU shrinks — we will calculate the exact numbers in episode 15. Second, every layer can become a point of failure: if IKE fails there is no ESP, if xl2tpd dies UDP 1701 goes unanswered, if pppd has problems the PPP frames are not processed. This is why the troubleshooting tools in episode 8 work layer by layer.

#Closing

Episode 2 gave you the architectural language used throughout the series: LAC and LNS, control connection versus data messages, the tasks of IKE versus ESP, and the encapsulation order of PPP inside L2TP inside ESP. With this understanding of the layers, you can read every log and every configuration option with the right context.

Key takeaways:

• LAC is the client endpoint, LNS is the server endpoint of the L2TP tunnel.
• The control connection manages the tunnel; data messages carry the PPP payload.
• IKE builds keys and SAs; ESP encrypts and authenticates data.
• L2TP/IPsec always uses ESP in tunnel mode.
• Stack: PPP -> L2TP -> UDP 1701 -> ESP -> IP.
• On Linux, this architecture is realized by pluto/charon, xl2tpd, and pppd.

In the next episode, episode 3, we will start our first hands-on practice: installation and initial setup — installing Libreswan and xl2tpd, assembling /etc/ipsec.conf, /etc/ipsec.secrets, /etc/xl2tpd/xl2tpd.conf, and /etc/ppp/options.xl2tpd, then verifying that all services are running. Make sure your server VM is ready.