L2TP and L2TPv3 Explained: Control Channels, Pseudowires and Security

L2TP (Layer Two Tunneling Protocol) carries layer 2 traffic across an IP network. Version 2 (RFC 2661, August 1999) tunnels PPP sessions over UDP port 1701 between an access concentrator and a network server; version 3 (RFC 3931, March 2005) generalises that into pseudowires for Ethernet and other layer 2 links, over UDP or directly over IP protocol 115. Neither version encrypts anything, so a secure deployment wraps L2TP in IPsec, filters it to known peers, and treats its cookies and shared secrets as checks, not as protection.

That one fact explains most L2TP stories. The "L2TP VPN" on a laptop is L2TP inside IPsec, with IPsec doing all the security work. The L2TP in a broadband network hands your PPP session from one operator to another. And an L2TPv3 pseudowire between two sites is a virtual Ethernet cable that carries whatever anyone on the path injects unless you add protection. This post goes one level deeper than our explainers on IKEv2 and IPsec and WireGuard. It walks through the L2TPv2 control channel message by message, shows what tunnel authentication and hidden AVPs actually protect, explains RFC 3193 L2TP over IPsec with overhead arithmetic, covers what L2TPv3 changed, and ends with a Linux lab that builds an Ethernet pseudowire with ip l2tp, protects it with IPsec and proves with tcpdump that the payload is encrypted.

Key takeaways

• L2TP (RFC 2661, August 1999) was adopted from L2F and PPTP. It splits a PPP connection between an L2TP Access Concentrator (LAC), where the user's layer 2 link ends, and an L2TP Network Server (LNS), where PPP is terminated.
• L2TPv2 runs over UDP port 1701. A tunnel carries one reliable control channel and many sessions, each a PPP connection, identified by 16 bit Tunnel ID and Session ID fields.
• Tunnel authentication in RFC 2661 is optional, CHAP-like and only happens at tunnel setup. Hidden AVPs obscure values with an MD5 based XOR. Neither protects data packets.
• L2TP has no encryption by design. RFC 3193 (November 2001) says L2TP security implementations MUST use IPsec ESP for both control and data packets, MUST support transport mode, and SHOULD use IKE for keys.
• L2TPv3 (RFC 3931, March 2005) separates the protocol from PPP, uses 32 bit IDs, authenticates whole control messages with an HMAC Message Digest AVP, and can run directly over IP protocol 115.
• The L2TPv3 cookie is a 32 or 64 bit clear text value in every data packet. RFC 3931 requires 64 bits against blind insertion and says it gives no protection against an attacker who can read the traffic.
• On a 1500 byte path, L2TPv2 with PPP leaves about 1460 bytes for the inner packet, 1426 inside ESP with AES-GCM in transport mode, and 1418 behind NAT traversal.
• New remote access VPNs are usually better served by IKEv2 or WireGuard. L2TP's lasting homes are ISP wholesale handoff and simple layer 2 pseudowires, inside an encrypted, filtered underlay.

What problem L2TP solved, and who the LAC and LNS are

In the 1990s, connecting to a network usually meant dialling a modem or an ISDN line into a Network Access Server and running PPP over that call. The physical link and the PPP session ended on the same box. RFC 2661 describes the change L2TP made: it lets the layer 2 endpoint and the PPP endpoint "reside on different devices interconnected by a packet-switched network". The user's call lands on a concentrator close to them, such as a modem bank or a DSL access multiplexer, and the concentrator tunnels the individual PPP frames to a server somewhere else.

The RFC's own example of why that matters is money. Without L2TP, the call had to terminate at the NAS, which might mean a long distance toll charge. With L2TP, the call ends at a local concentrator and the PPP session is extended over shared infrastructure such as frame relay or the Internet. That split is still the reason L2TP exists in carrier networks: one company owns the access lines, another company owns the subscriber relationship and the IP addresses, and L2TP hands each subscriber's PPP session across the boundary.

RFC 2661 names the two roles:

• LAC (L2TP Access Concentrator): the node that sits between the remote system and the LNS. It receives the user's layer 2 connection and forwards PPP frames into the tunnel. In broadband networks this is the access provider's edge.
• LNS (L2TP Network Server): the peer of the LAC that terminates the PPP session. It runs PPP authentication, assigns the IP address and routes the user's traffic. In wholesale networks this is the retail ISP's edge, or a corporate gateway.

A tunnel exists between one LAC and one LNS pair and carries one control connection. Inside it, each user's PPP connection is a session. RFC 3193, the IPsec companion document, discusses the two ways of using the protocol. In compulsory tunnelling the LAC decides to build the tunnel on the user's behalf, often based on the domain part of their username. In voluntary tunnelling the user's own machine acts as the LAC, which is what a desktop "L2TP VPN" client does.

Where L2TP came from: L2F and PPTP

RFC 2661's acknowledgements state that L2TP was adopted from L2F (RFC 2341, May 1998, now Historic) and PPTP (RFC 2637, July 1999). The merge left traces in the wire format: RFC 2661 notes that UDP port 1701 is used for both L2F and L2TP packets, and that the Version field tells them apart, with L2F as version 1 and L2TP as version 2. A system that does not support L2F must silently discard L2F packets.

Dated timeline of the L2TP standards

How the L2TPv2 header works

Control and data messages share one header. RFC 2661 lays it out as a 16 bit flags and version word, an optional 16 bit Length, a 16 bit Tunnel ID, a 16 bit Session ID, optional 16 bit Ns and Nr sequence numbers, and an optional Offset Size and padding.

The flags matter more than they look:

• T (Type): 0 for a data message, 1 for a control message.
• L (Length): the Length field is present. It must be 1 on control messages.
• S (Sequence): Ns and Nr are present. It must be 1 on control messages and is optional on data messages.
• O (Offset): an Offset Size field is present. It must be 0 on control messages.
• P (Priority): on data messages only, asks for preferential queuing. The RFC gives LCP echo requests as the example, so a burst of congestion does not kill the keepalives and drop the link.
• Ver: must be 2 for L2TP. A value of 1 identifies L2F.

The Tunnel ID and Session ID are chosen by the receiver. Each side tells the other which ID it wants to see on incoming packets, so the values in the two directions differ. That is why packet captures look asymmetric and why a static configuration has to mirror IDs on each end.

A minimal data packet carrying PPP therefore has 6 bytes of L2TP header (flags, tunnel, session), or 8 when the sender sets the Length bit, plus the PPP header, plus UDP and IP. We work through the numbers below.

How the L2TPv2 control channel works

The control channel builds the tunnel, keeps it alive, builds and tears down sessions, and reports errors. Every control message is a list of Attribute Value Pairs (AVPs). The first AVP is always the Message Type.

Control messages

RFC 2661 defines these message types:

A typical broadband or remote access tunnel looks like this:

1. The LAC sends SCCRQ to UDP port 1701 on the LNS, from any source port. It includes a Tie Breaker AVP if both ends might start a tunnel to each other at once, so one of the two requests wins.
2. The LNS answers with SCCRP. RFC 2661 lets the responder reply from a different free port, and the initiator must then send to that port. This one detail causes trouble with IPsec policies and firewalls, as we will see.
3. The LAC sends SCCCN. The tunnel is up.
4. When a user connects, the LAC sends ICRQ, the LNS answers ICRP with its assigned Session ID, and the LAC sends ICCN with details of the call. In proxy authentication setups, the ICCN can also carry the PPP authentication exchange the LAC has already done with the user, so the LNS can reuse it.
5. PPP frames for that session now flow as data messages with T set to 0.
6. HELLO messages keep the control connection alive while it is idle. CDN ends a session; StopCCN ends the tunnel.

Reliable delivery

UDP does not retransmit, so L2TP brings its own reliable transport for control messages. RFC 2661 describes a sliding window: each control message carries Ns, its own sequence number starting at 0 and counting modulo 65536, and Nr, the next number the sender expects to receive. A message with nothing else to say, called a Zero Length Body (ZLB), acknowledges receipt without using a sequence number. Duplicates must still be acknowledged, in case the ACK was lost. Appendix A adds slow start and congestion avoidance for the control channel.

Data messages are not retransmitted. If a data packet is lost, PPP and the protocols inside it deal with it, just as they would on a lossy serial line. Sequencing on data messages is optional and only helps a receiver detect loss or reorder packets.

Tunnel authentication: what it protects

RFC 2661 section 5.1.1 describes "a simple, optional, CHAP-like" tunnel authentication. If a peer wants to verify the other, it puts a Challenge AVP of random bytes in its SCCRQ or SCCRP. The other side must answer with a Challenge Response AVP in its SCCRP or SCCCN, computed over the challenge with a single shared secret both ends hold. If the response does not match, tunnel establishment must be refused.

Read the security considerations and the limit is stated plainly. This authentication protects only tunnel establishment. RFC 2661 says "it is fairly simple" for a malicious user who can snoop the stream to inject packets once an authenticated tunnel has been set up. Nothing in the challenge exchange signs or encrypts the control messages that follow, and nothing touches the data packets.

So tunnel authentication answers one question, "does the peer that just started this tunnel know the shared secret?", and nothing else. It does not stop tampering with later control messages, session hijacking or eavesdropping. RFC 3193 agrees: it authenticates the peers at tunnel origination and does not protect control and data traffic per packet.

Hidden AVPs: obscured, not encrypted

Some AVPs carry sensitive values, notably usernames and passwords passed during proxy authentication. RFC 2661 lets a sender set the H (Hidden) bit and transform the value. The procedure takes an MD5 hash of the AVP type, the shared secret and a Random Vector AVP sent earlier in the message, XORs the first 16 bytes of the value with the hash, and chains further MD5 hashes for longer values. Padding may be added to hide the length.

This keeps the value out of a casual packet capture. It is not modern encryption: it depends on MD5, on one long lived shared secret per tunnel (the same one used for tunnel authentication), and on a random vector chosen by the sender. It also covers only the specific AVPs marked hidden. Treat hidden AVPs as obfuscation, and assume anything that matters needs IPsec underneath.

Why L2TP has no encryption of its own

L2TP was designed as a transport for PPP, and PPP already had optional authentication (PAP, CHAP and later EAP) and optional encryption negotiated through its Encryption Control Protocol. The authors also expected the underlying network to provide packet security when it was needed. RFC 2661 section 9.2 says securing L2TP "requires that the underlying transport make available encryption, integrity and authentication services for all L2TP traffic", and section 9.4 names IPsec as the way to do it when running over IP.

RFC 3193 set out why that layering is necessary. It lists the threats: someone snooping data packets to discover user identities, modifying control or data packets, hijacking the tunnel or the PPP connection inside it, denial of service by tearing down sessions or tunnels, and interfering with PPP's own encryption or authentication negotiation to weaken it. Then it states that "the L2TP protocol, and PPP authentication and encryption do not meet the security requirements for L2TP". PPP authenticates the user to the LNS but gives no per packet integrity or replay protection, and PPP encryption, where used, does not cover key management or the L2TP control channel at all.

There is one more reason. RFC 2661 section 9.3 points out that protecting the L2TP stream only protects it between the LAC and LNS. In a compulsory tunnel, the hop between the user and the LAC is outside the tunnel entirely. End to end security between hosts or applications still needs its own layer, such as TLS.

How L2TP over IPsec works (RFC 3193)

RFC 3193, "Securing L2TP using IPsec", published in November 2001, is the document behind every built in "L2TP/IPsec VPN" client.

What the RFC requires

• All L2TP security compliant implementations MUST implement IPsec ESP to protect both control and data packets.
• Transport mode MUST be supported; tunnel mode MAY be.
• Replay protection MUST be implemented.
• IKE SHOULD be supported for authentication, security association negotiation and key management.
• Implementations must support the IPsec mandated cipher suites of the time, including NULL encryption. The RFC notes that ESP with NULL encryption gives integrity and replay protection without confidentiality, for cases where the data is already encrypted. For a remote access VPN that is almost never what you want.

Transport mode is the natural fit. The L2TP packet is already a UDP datagram between the two tunnel endpoints, so IPsec only needs to protect the UDP payload between the same two addresses. The IPsec policy selects UDP traffic to and from port 1701 between the two peers and requires ESP for it. Everything inside, the L2TP header, the PPP frame and the user's IP packet, is encrypted and integrity protected.

The port change problem

RFC 3193 spends several pages on a detail from RFC 2661: the responder may answer an SCCRQ from a different UDP source port, and may even reply from a different IP address. If IKE has set up security associations for the original port pair, a reply from a new port does not match the policy. RFC 3193 says the responder is not required to support floating its port, but the initiator MUST allow it to. When the responder picks a new port, it must decide before sending SCCRP, L2TP must inject new filters into the IPsec policy database, and the responder must start a new IKE phase 2 negotiation for the new port. The simplest way to avoid the whole problem on a gateway you control is to keep the server replying from port 1701, so a single policy covers the tunnel.

Pre-shared keys and who they authenticate

RFC 3193 discusses IKE phase 1 with pre-shared keys bound to peer IP addresses. Remote access clients do not have fixed addresses, so many deployments ended up with one pre-shared key for the whole user population, combined with a username and password inside PPP. Vendor documentation for built in clients reflects this pattern. Apple's VPN deployment overview, for example, lists L2TP over IPsec "with user authentication by MS-CHAPV2 password and machine authentication by shared secret" alongside certificate options for IKEv2.

The weakness of a group key is structural. A shared key proves that a peer is a member of the group that knows it. It cannot prove to a client that the gateway is the real gateway, because every client also knows it. Anyone who has the key, which over time means every former employee and every laptop that has been lost, can stand up something that looks like the gateway to a client. Once IPsec is established with an impostor, the inner PPP password exchange is exposed to it. Certificates or EAP methods that authenticate the server avoid this.

NAT traversal

ESP is IP protocol 50 and has no ports, so it does not pass through ordinary port translating NAT. RFC 3948 (January 2005) defines UDP encapsulation of ESP on port 4500, with IKE detecting NAT and both sides switching to it. L2TP over IPsec clients behind home routers rely on this. Transport mode through NAT has a further complication, because the TCP or UDP checksum inside the ESP payload covers addresses that NAT changed. RFC 3948 section 3.1.2 describes the transport mode decapsulation procedure, in which the receiver incrementally recomputes or otherwise fixes those checksums using the original addresses learned during IKE. Section 5.2 of the same RFC also describes a conflict when two clients behind the same NAT use transport mode to the same server. This corner is where much of L2TP/IPsec's reputation for being awkward behind home routers comes from.

Double encapsulation and its overhead

An L2TP over IPsec packet from a remote client is a stack of headers: outer IPv4, sometimes UDP 4500, ESP header and IV, then UDP 1701, L2TP, PPP and finally the user's own IP packet, followed by ESP padding, trailer and integrity check value. That is why people describe it as double encapsulation: the user's packet is wrapped once in PPP and L2TP, and again in IPsec.

Worked example 1: L2TPv2 over UDP, no IPsec

On a 1500 byte Ethernet path with IPv4:

• Outer IPv4 header: 20 bytes
• UDP header: 8 bytes
• L2TP header with the Length bit set: 8 bytes (6 without it)
• PPP header: usually 4 bytes (address and control bytes 0xFF 0x03, then a 2 byte protocol field), less if the peers negotiate header compression

Total overhead: 20 + 8 + 8 + 4 = 40 bytes. Inner MTU: 1500 minus 40 = 1460. Without the Length field the overhead is 38 bytes and the arithmetic gives 1462, but many implementations set an MTU of 1460 or lower for safety. A TCP MSS for IPv4 traffic inside would be 1460 minus 40 = 1420.

Worked example 2: inside ESP transport mode with AES-GCM

Add ESP in transport mode using AES-GCM with a 16 byte ICV and an 8 byte IV (the RFC 4106 format):

• Outer IPv4: 20
• ESP header (SPI and sequence number): 8
• IV: 8
• Encrypted part: UDP 8 + L2TP 8 + PPP 4 + inner packet P + padding + 2 bytes of trailer (pad length and next header)
• ICV: 16

The total is 74 + P + padding. ESP requires the encrypted part to end on a 4 byte boundary, so 20 + P + padding + 2 must be a multiple of 4. Setting the total to 1500 gives P plus padding of 1426, which already satisfies the alignment with zero padding. Inner MTU: 1426. TCP MSS: 1386.

With NAT traversal, the extra 8 byte UDP header on port 4500 makes the total 82 + P + padding. P plus padding can be at most 1418, which also aligns with zero padding. Inner MTU: 1418. TCP MSS: 1378.

Worked example 3: older AES-CBC with HMAC-SHA1-96

Older gateways often negotiate AES-CBC with a 16 byte IV and a 12 byte truncated HMAC. CBC needs the encrypted part padded to a 16 byte block. Without NAT traversal, the space left for the encrypted part is 1500 minus 20 (IP) minus 8 (ESP) minus 16 (IV) minus 12 (ICV) = 1444 bytes. The largest multiple of 16 that fits is 1440. Subtract UDP, L2TP and PPP (20 bytes) and the 2 byte trailer and the inner MTU is 1418. Behind NAT, the 8 byte UDP header leaves 1436, the largest block multiple is 1424, and the inner MTU is 1402.

The lesson from all three examples: set the PPP MTU and MRU deliberately, and clamp TCP MSS at the LNS, rather than trusting Path MTU Discovery to work through a path that may filter ICMP.

What changed in L2TPv3 (RFC 3931)

By the early 2000s, operators wanted to use L2TP's control plane for something other than PPP: carrying Ethernet, frame relay, ATM and HDLC circuits across an IP core, a service the IETF called pseudowire emulation. RFC 3931, published in March 2005, is the result. It keeps the shape of RFC 2661 and changes the parts that tied it to PPP.

The main differences

RFC 3931 section 1.1 lists the notable changes from L2TPv2:

• Separation from PPP. All PPP specific AVPs and the PPP specific part of the data header move to a companion document. The base protocol carries any layer 2 payload.
• 32 bit identifiers. The 16 bit Tunnel ID and Session ID become a 32 bit Control Connection ID and a 32 bit Session ID. Large aggregation routers no longer run out of session numbers.
• Stronger control message authentication. Tunnel authentication is extended from a challenge in certain messages to the whole control message. A Message Digest AVP (attribute type 59) carries an HMAC over each control message: HMAC-MD5 must be supported and HMAC-SHA-1 should be.

The roles change name too. Because both ends of a pseudowire are usually equal peers, RFC 3931 calls them LCCEs (L2TP Control Connection Endpoints). LAC and LNS remain as descriptions of the remote access case.

IP protocol 115 versus UDP

L2TPv3 can run over UDP port 1701 like L2TPv2, or directly over IP using protocol number 115, which IANA lists as L2TP with RFC 3931 as the reference. Over IP, a data packet is just the outer IP header, a 4 byte Session ID, an optional cookie and an optional 4 byte L2-Specific Sublayer, then the layer 2 frame. Control messages over IP use a Session ID of zero, which RFC 3931 reserves for that purpose.

Dropping UDP saves bytes and lets hardware find the session from a fixed offset. The cost is that protocol 115 has no ports, so it does not cross port translating NAT and is often blocked by default on firewalls. The Linux ip-l2tp(8) manual puts it bluntly: use IP encapsulation only when there are no NAT devices or firewalls in the network path.

Cookies

The cookie is the L2TPv3 feature most often misread. It is an optional 32 or 64 bit field in every data packet, exchanged in the Assigned Cookie AVP during session setup (or configured by hand for static tunnels). The receiver looks up the session by Session ID, then checks the cookie against the stored value and drops the packet if they differ.

RFC 3931 explains its purpose in section 8.2. The Session ID keeps different customers' pseudowires apart, and the cookie adds a second check that the lookup was right and the Session ID was not corrupted. Against a blind attacker who cannot see the traffic, a random 64 bit cookie also makes it impractical to guess a value that will be accepted, which protects against frames being inserted into a customer's layer 2 network from outside.

The same section draws the limits clearly:

• For protection against brute force, blind insertion, a 64 bit cookie MUST be used. A 32 bit cookie "is vulnerable to brute-force guessing at high packet rates".
• The cookie provides no protection against an attacker who can sniff traffic. It is sent in clear text in every packet, so anyone on the path can read it and reuse it.

So a cookie is a spoofing filter for off path attackers, and a correctness check. It is not a secret, not an authentication mechanism and not integrity protection.

Ethernet pseudowires (RFC 4719)

RFC 4719, published in November 2006, defines how Ethernet frames ride L2TPv3. It has two pseudowire types: "Ethernet port", which carries every frame arriving on a physical port, and "Ethernet VLAN", which carries frames from one VLAN, with optional rewriting of the tag. The Ethernet frame is carried without its preamble or frame check sequence.

The RFC also does the overhead arithmetic. The encapsulated packet is M plus N bytes longer than the Ethernet frame, where M is the IP header and N is:

• 4 to 16 bytes for L2TPv3 over IP (Session ID 4, cookie 0, 4 or 8, L2-Specific Sublayer 0 or 4)
• 16 to 28 bytes for L2TPv3 over UDP (adding the 8 byte UDP header and 4 bytes of flags, version and reserved bits)

RFC 4719 warns that fragmentation in the provider network can happen unless MTUs are managed between customer and provider edges and across the core, and points to RFC 4623 for fragmentation and reassembly options. RFC 4667 (September 2006) adds the L2VPN extensions for signalling these services in a unified way.

L2TPv2 versus L2TPv3 at a glance

Where L2TP is still used, and why desktop clients are moving on

ISP wholesale and BNG handoff

The original LAC and LNS split is still how many broadband wholesale arrangements work. A subscriber's PPP session, often PPPoE from their router, reaches the access provider's broadband network gateway. That gateway acts as a LAC: it reads the domain part of the username, opens or reuses an L2TP tunnel to the retail ISP's LNS, and hands the PPP session across. The retail ISP authenticates the subscriber against its own RADIUS servers (see how RADIUS works and how to secure it) and assigns the address. The underlay here is a private interconnect, but the same protections apply: filter UDP 1701 to known peers, use tunnel authentication, and on any untrusted segment add IPsec.

PPP over L2TP and the Linux kernel

The Linux kernel documentation describes an L2TP subsystem that implements the data path for both versions: L2TPv2 over UDP, and L2TPv3 over UDP or directly over IP protocol 115. The kernel only handles data packets. The control protocol is left to user space, so an L2TP daemon exchanges SCCRQ and its friends over a tunnel socket, then tells the kernel through generic netlink to create tunnel and session contexts. Each session becomes a virtual network device, such as pppN for PPP sessions (via a PPPoL2TP socket) or l2tpethN for Ethernet pseudowires.

The kernel also supports static, unmanaged L2TPv3 tunnels with no control protocol at all, created with ip l2tp from iproute2. That is the easiest way to build an Ethernet pseudowire between two Linux machines, and it is what the walkthrough below uses. The trade off is spelled out in the manual page: with no control protocol, no consistency checks are possible, mismatched parameters simply drop traffic, and Linux does not support Hello messages on unmanaged tunnels.

Legacy remote access VPNs

L2TP over IPsec became a common built in VPN type because it worked with PPP's existing user authentication and needed no extra client software. Platform documentation still shows it, but increasingly as a legacy option:

• Apple's VPN deployment overview lists L2TP over IPsec as supported on iOS, iPadOS, macOS, tvOS and visionOS, with MS-CHAPv2 user authentication and shared secret machine authentication. The same page lists the newer features, including Always On VPN, per-app VPN with the built in client, and additional ML-KEM key exchanges on the 26 releases, under IKEv2.
• Android's developer documentation describes the built in PPTP and L2TP/IPsec client as what is "sometimes called legacy VPN", and points developers to the VpnService API for anything else.

The reasons the industry is moving away are the ones this post has already covered. Remote access L2TP depends on a pre-shared key that is often shared across users, an inner PPP password protocol, and IKEv1 era configuration. It adds two layers of overhead, struggles with NAT in transport mode, and has no built in support for roaming between networks. IKEv2 (first published in 2005 and current as RFC 7296, October 2014) brings certificate and EAP authentication, the MOBIKE extension for roaming (RFC 4555, June 2006) and a cleaner single layer tunnel, and WireGuard offers a small fixed cryptographic design with roaming built in.

Comparison: L2TP over IPsec, IKEv2 with IPsec, WireGuard and GRE

The overhead figures are approximate and depend on cipher, options and NAT; recompute them for your own stack. The WireGuard figure comes from its protocol description: a 16 byte data message header plus a 16 byte authentication tag, on top of UDP and IP.

How to secure L2TP and L2TPv3

1. Run it inside IPsec on any network you do not fully control. Use ESP with an AEAD cipher such as AES-GCM, keyed with IKEv2 where both ends support it, and never ESP NULL for user traffic.
2. Authenticate the gateway with certificates, not a group key. If you must keep L2TP/IPsec for remote access, issue per device certificates or at least per user keys, so the server can be verified and a single leaked key does not expose everyone.
3. Filter the underlay. Accept UDP 1701 and IP protocol 115 only from known peer addresses, and on IPsec protected tunnels only after decryption. Drop L2TP from the Internet at the edge.
4. Turn on L2TP's own checks as defence in depth. Use tunnel authentication on L2TPv2, Message Digest AVPs on managed L2TPv3, and 64 bit random cookies on every L2TPv3 session. None of them replaces IPsec; all of them reduce the noise an off path attacker can make.
5. Set MTUs and clamp MSS. Compute the real overhead for your header stack and set PPP MRU, l2tpeth MTU and TCP MSS accordingly.
6. Filter what comes out of the tunnel. A pseudowire puts the far end on your layer 2 segment. Apply the same controls you would to a new switch port: DHCP snooping or static assignments, storm control, and no trust in source addresses until they are checked.
7. Keep the endpoints patched. The L2TP data path lives in the kernel and the control plane lives in daemons. Track both in your patch process like any other network facing service.

Step by step: an L2TPv3 Ethernet pseudowire between two Linux hosts, protected with IPsec

This lab joins two Linux hosts, A (192.0.2.10) and B (198.51.100.20), with an unmanaged L2TPv3 Ethernet pseudowire over IP protocol 115, then protects it with IPsec ESP in transport mode and verifies the result. Use test machines or virtual machines; the addresses are documentation ranges, so substitute your own.

1. Load the modules and check the path

# On both hosts
sudo modprobe l2tp_eth
sudo modprobe l2tp_ip
lsmod | grep l2tp

# Confirm the underlay MTU and reachability (from A)
ip route get 198.51.100.20
ping -c 3 -M do -s 1472 198.51.100.20   # 1472 + 28 = 1500 bytes on the wire

If the 1472 byte ping fails with "message too long" or times out, your path MTU is below 1500 and every number below shrinks by the same amount.

2. Generate a random 64 bit cookie for each direction

# Run once, copy the values to both hosts
openssl rand -hex 8   # cookie that A sends, B expects: e.g. 9f3a6c21d40b7e58
openssl rand -hex 8   # cookie that B sends, A expects: e.g. 41c7e2a09b6d3f15

Use 64 bit cookies, as RFC 3931 requires for protection against blind insertion. Remember they travel in clear text until IPsec is added.

3. Create the tunnel and session

# Host A
sudo ip l2tp add tunnel tunnel_id 1000 peer_tunnel_id 2000 \
    encap ip local 192.0.2.10 remote 198.51.100.20
sudo ip l2tp add session name l2tpeth0 tunnel_id 1000 \
    session_id 1100 peer_session_id 2200 \
    cookie 9f3a6c21d40b7e58 peer_cookie 41c7e2a09b6d3f15

# Host B (IDs and cookies mirrored)
sudo ip l2tp add tunnel tunnel_id 2000 peer_tunnel_id 1000 \
    encap ip local 198.51.100.20 remote 192.0.2.10
sudo ip l2tp add session name l2tpeth0 tunnel_id 2000 \
    session_id 2200 peer_session_id 1100 \
    cookie 41c7e2a09b6d3f15 peer_cookie 9f3a6c21d40b7e58

The ip-l2tp(8) manual explains that the IDs and addresses must be matched and reversed at each site, and that with no control protocol nothing checks this for you. If the values disagree, traffic is silently dropped.

Check the result on each host:

ip l2tp show tunnel
ip l2tp show session

4. Set the MTU and bring the interface up

For L2TPv3 over IP with a 64 bit cookie and no L2-Specific Sublayer, the overhead on top of the bridged frame's payload is 20 (IP) + 4 (Session ID) + 8 (cookie) + 14 (inner Ethernet header) = 46 bytes, so the most the l2tpeth0 MTU can be on a 1500 byte path is 1454. We will add IPsec next, so set the final value now (step 7 shows the arithmetic):

# Both hosts
sudo ip link set l2tpeth0 mtu 1420 up

5. Test it as a point to point IP link

# Host A
sudo ip addr add 10.42.1.1/30 dev l2tpeth0
# Host B
sudo ip addr add 10.42.1.2/30 dev l2tpeth0

# From A
ping -c 3 10.42.1.2

6. Look at the traffic before IPsec

# On A's underlay interface (eth0 here), while the ping runs
sudo tcpdump -ni eth0 -X 'ip proto 115' -c 4

You will see IP packets with protocol 115. In the hex dump you can read the Session ID, the 8 byte cookie, the inner Ethernet header with both MAC addresses, the inner IP header with 10.42.1.1 and 10.42.1.2, and the ICMP payload. Anyone on the path can see all of it, and anyone who copies the cookie can inject frames that B will accept.

To bridge instead of routing, remove the addresses and add l2tpeth0 to a bridge with a physical port, as the manual page shows. The security point stands either way: the far end becomes part of your layer 2 network.

7. Protect the pseudowire with IPsec transport mode

The cleanest way is IKEv2 with certificates, here shown with strongSwan's swanctl.conf. The traffic selectors limit the security association to IP protocol 115 between the two hosts, and transport mode leaves the outer addresses unchanged.

# /etc/swanctl/conf.d/l2tpv3.conf on host A (mirror on B)
connections {
    l2tpv3-pw {
        version = 2
        local_addrs  = 192.0.2.10
        remote_addrs = 198.51.100.20
        proposals = aes256gcm16-prfsha384-ecp384
        local {
            auth = pubkey
            certs = hostA.crt
            id = hostA.example.net
        }
        remote {
            auth = pubkey
            id = hostB.example.net
        }
        children {
            pw {
                mode = transport
                local_ts  = dynamic[115]
                remote_ts = dynamic[115]
                esp_proposals = aes256gcm16
                start_action = trap
            }
        }
    }
}

strongSwan's documentation says a traffic selector can carry a numeric protocol in square brackets after the subnet, and that dynamic is replaced with the tunnel's outer address. Load and start it:

sudo swanctl --load-all
sudo swanctl --initiate --child pw
sudo swanctl --list-sas

The MTU arithmetic with AES-GCM in transport mode: outer IP 20, ESP header 8, IV 8, then the encrypted part (Session ID 4, cookie 8, inner Ethernet 14, payload P, padding, 2 byte trailer), then a 16 byte ICV. The total is 80 + P + padding. The encrypted part, 28 + P + padding, must be a multiple of 4. On a 1500 byte path P can be at most 1420, which aligns with no padding. That is the value set in step 4. If the frames you bridge carry an 802.1Q tag, take off another 4 bytes.

8. Verify that the payload is encrypted

# Plain L2TPv3 should no longer appear on the wire
sudo tcpdump -ni eth0 'ip proto 115' -c 4 &
# ESP should
sudo tcpdump -ni eth0 esp -c 4
ping -c 4 10.42.1.2

The first capture should stay empty while the ping runs. The second should show ESP packets with an SPI and sequence number and nothing readable after them: no cookie, no MAC addresses, no inner IP addresses.

Confirm with the kernel's own counters:

sudo ip -s xfrm state     # byte and packet counters rise with the ping
sudo ip xfrm policy       # in, out and fwd policies for proto 115

The inbound policy is what makes this a security control rather than an option. RFC 4301 describes inbound processing: a packet that arrives without ESP is checked against the security policy, and only traffic the policy marks as bypass gets through. Plain protocol 115 from the peer matches a policy that requires protection, so it is discarded instead of delivered. Test it: stop the IPsec connection and confirm the ping fails rather than falling back to clear text.

9. Filter the underlay

Accept the tunnel only from the peer. With nftables on host A:

sudo nft add table inet l2tp
sudo nft add chain inet l2tp input '{ type filter hook input priority 0; policy accept; }'
sudo nft add rule inet l2tp input ip saddr != 198.51.100.20 ip protocol 115 drop
sudo nft add rule inet l2tp input ip saddr != 198.51.100.20 ip protocol esp drop
sudo nft add rule inet l2tp input ip saddr != 198.51.100.20 udp dport { 500, 4500, 1701 } drop
sudo nft list table inet l2tp

Adjust for your own policy; on a host with a default drop input policy, write the equivalent accept rules instead.

10. Tear down

sudo swanctl --terminate --ike l2tpv3-pw
sudo ip l2tp del session tunnel_id 1000 session_id 1100
sudo ip l2tp del tunnel tunnel_id 1000
sudo nft delete table inet l2tp

Sessions must be deleted before their tunnel, as the manual notes.

Where Safeguard fits

Safeguard does not inspect tunnels, network devices or firewall rules, and it does not manage endpoints or VPN clients. The fit here is indirect. L2TP endpoints run software: the kernel data path, user space L2TP daemons, IPsec and IKE daemons, RADIUS servers behind the LNS, and often a container image or appliance build that bundles them with open source libraries. If your team builds those images or packages, Safeguard can scan the repositories, container images and SBOM files you produce (for example safeguard scan --image your-gateway-image or safeguard scan --dir .), match their components against vulnerability databases, show which projects contain a given component and version, and open fix pull requests when a fixed version exists. It does not cover the host kernel outside an image or the firmware in a vendor router, which still have to come from the distribution or the vendor.

Common mistakes

• One pre-shared key for every remote user. A group key cannot prove the gateway's identity to clients, and it leaks with every lost laptop and departing employee. Use certificates or per user credentials, and rotate.
• Exposing UDP 1701 or protocol 115 without IPsec. L2TP has no encryption and only setup time authentication. A tunnel visible on the Internet without IPsec exposes user traffic and invites injection and teardown.
• Treating the L2TPv3 cookie as authentication. It is sent in clear text and RFC 3931 says it offers no protection against anyone who can read the traffic. It only stops blind guessing, and only at 64 bits.
• Using 32 bit cookies. RFC 3931 calls them vulnerable to brute force guessing at high packet rates. Always use 64 bits.
• MTU black holes. Double encapsulation can take 80 or more bytes off a 1500 byte path. If ICMP is filtered anywhere, large packets vanish while pings succeed. Set the MTU, clamp MSS, and test with a do not fragment ping.
• Mismatched static parameters. Unmanaged tunnels have no control protocol to catch a swapped Session ID or cookie. Write both ends from one source of truth.
• Choosing IP protocol 115 through NAT. It has no ports. Use UDP encapsulation, or better, put the whole tunnel inside IPsec with NAT traversal.
• Assuming the inner PPP authentication is safe on its own. PAP, CHAP and MS-CHAPv2 inside L2TP rely on the IPsec layer to protect them. Without it, they are exposed to anyone on the path.
• Forgetting the layer 2 side. A pseudowire makes the remote site part of the same broadcast domain. Loops, rogue DHCP servers and ARP spoofing travel through it too.
• Leaving ESP NULL enabled. RFC 3193 requires implementations to support it; that does not mean you should allow it in your proposals.

FAQ

What is L2TP used for?

L2TP carries layer 2 connections across an IP network. Its original use, still common, is carrying subscribers' PPP sessions from an access provider's equipment (the LAC) to an ISP or corporate server (the LNS). It is also used inside IPsec as a remote access VPN, and in version 3 to build Ethernet and other layer 2 pseudowires between sites.

Is L2TP secure?

Not on its own. L2TP has no encryption, and its optional tunnel authentication only covers tunnel setup. RFC 2661 says it is simple for someone who can see the stream to inject packets afterwards. Use it inside IPsec ESP, as RFC 3193 specifies, and authenticate the gateway with certificates.

What port does L2TP use?

L2TPv2 uses UDP port 1701, registered with IANA. L2TPv3 can use UDP 1701 or run directly over IP protocol number 115. L2TP over IPsec also needs UDP 500 for IKE and UDP 4500 for IKE and ESP when NAT traversal is in use, or IP protocol 50 for ESP without NAT.

What is the difference between L2TP and L2TPv3?

L2TPv2 (RFC 2661) carries PPP only, over UDP, with 16 bit tunnel and session IDs. L2TPv3 (RFC 3931) separates the base protocol from PPP so it can carry any layer 2 frame, uses 32 bit IDs, can run directly over IP protocol 115, adds an HMAC based Message Digest for whole control messages, and adds optional cookies on data packets.

Why does L2TP need IPsec?

Because L2TP was designed to rely on the underlying transport for security. RFC 3193 lists the threats, from snooping user identities to hijacking sessions, and states that L2TP and PPP security do not meet them. IPsec ESP provides the encryption, integrity, replay protection and key management that L2TP lacks.

What is an L2TPv3 cookie?

A 32 or 64 bit value carried in every L2TPv3 data packet after the Session ID. The receiver checks it against the value agreed for that session and drops mismatches. It guards against misdelivered frames and blind spoofing; RFC 3931 requires 64 bits for that purpose and says the cookie gives no protection against an attacker who can read the traffic.

What MTU should I use for L2TP over IPsec?

It depends on your cipher and NAT. On a 1500 byte path with AES-GCM in transport mode, plain L2TPv2 with PPP leaves 1426 bytes for the inner packet, or 1418 behind NAT traversal. Older AES-CBC with HMAC-SHA1 leaves 1418, or 1402 behind NAT. Set the PPP MTU at or below those values and clamp TCP MSS 40 bytes lower for IPv4.

What are LAC and LNS in L2TP?

The LAC (L2TP Access Concentrator) receives the user's layer 2 connection and forwards PPP frames into the tunnel. The LNS (L2TP Network Server) terminates the PPP session, authenticates the user and routes their traffic. In broadband wholesale, the access provider runs the LAC and the retail ISP runs the LNS.

Should I use L2TP/IPsec or IKEv2 for a new VPN?

For a new remote access VPN, IKEv2 with IPsec or WireGuard is usually the better fit: certificate or EAP authentication, built in roaming, lower overhead and fewer layers to configure. Platform documentation increasingly describes L2TP/IPsec as legacy. Keep L2TP where you need its specific strengths, such as PPP wholesale handoff or a simple layer 2 pseudowire.

Can L2TP carry Ethernet frames?

Yes, with L2TPv3. RFC 4719 defines Ethernet port and Ethernet VLAN pseudowires over L2TPv3, and Linux supports them through l2tpeth interfaces created with ip l2tp. Bridge the interface with a physical port to extend a layer 2 segment, and protect the tunnel with IPsec.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You ask it to fix a lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to the repository that builds your VPN gateway image or the tooling that templates your L2TP and IPsec configuration.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. Network teams often keep gateway builds and configuration on internal hosts, and the runner lets those scans happen where the code already lives.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. If your team already asks an assistant to review tunnel configurations or gateway Dockerfiles, this is how Safeguard's findings can sit alongside that work, with you deciding what the assistant may touch.

Click through it at your own pace, or open it full screen.

Ready to try it on your own repositories? Download Safeguard or read the CLI documentation.

Quick check

Sources

• RFC 2661: Layer Two Tunneling Protocol "L2TP" (August 1999)
• RFC 3931: Layer Two Tunneling Protocol, Version 3 (L2TPv3) (March 2005)
• RFC 3193: Securing L2TP using IPsec (November 2001)
• RFC 4719: Transport of Ethernet Frames over L2TPv3 (November 2006)
• RFC 2341: Layer Two Forwarding (Protocol) "L2F" (May 1998)
• RFC 2637: Point-to-Point Tunneling Protocol (PPTP) (July 1999)
• RFC 3070: Layer Two Tunneling Protocol (L2TP) over Frame Relay (February 2001)
• RFC 3145: L2TP Disconnect Cause Information (July 2001)
• RFC 3438: L2TP IANA Considerations Update (BCP 68, December 2002)
• RFC 3948: UDP Encapsulation of IPsec ESP Packets (January 2005)
• RFC 4301: Security Architecture for the Internet Protocol (December 2005)
• RFC 4623: Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly (August 2006)
• RFC 4667: Layer 2 Virtual Private Network (L2VPN) Extensions for L2TP (September 2006)
• RFC 5641: L2TPv3 Extended Circuit Status Values (August 2009)
• RFC 6169: Security Concerns with IP Tunneling (April 2011)
• RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2) (October 2014)
• RFC 4555: IKEv2 Mobility and Multihoming Protocol (MOBIKE) (June 2006)
• RFC 4106: The Use of Galois/Counter Mode (GCM) in IPsec ESP (June 2005)
• WireGuard: Protocol and Cryptography
• IANA: Assigned Internet Protocol Numbers
• IANA: Service Name and Transport Protocol Port Number Registry
• Linux kernel documentation: L2TP
• Linux manual page: ip-l2tp(8)
• Linux manual page: ip-xfrm(8)
• strongSwan documentation: swanctl.conf
• Apple Platform Deployment: VPN overview for Apple device deployment
• Android Developers: VPN

Related reading: IKEv2 and IPsec explained, WireGuard protocol explained and How the RADIUS protocol works.

Last reviewed: 24 October 2026. Overhead and MTU values depend on your cipher, options and NAT situation; recompute them for your own header stack and check your platform's documentation before relying on a specific behaviour.