What Is L2TP? L2TP/IPsec vs Other VPN Protocols

L2TP (Layer 2 Tunneling Protocol) is a tunnelling protocol that carries PPP sessions inside UDP datagrams on port 1701. It doesn’t encrypt anything on its own, so VPNs run it inside IPsec, and that pairing is what “L2TP/IPsec” means. It still works, and Windows still ships a client for it. But in 2026 it’s a legacy choice.

That’s the short version. Here’s how it stacks up against everything you’ll be asked to compare it with:

The rest of this guide explains each row, counts the bytes L2TP/IPsec adds to every packet, gives you a working Cisco ASA config, and fixes the Windows errors people actually hit.

What Is L2TP?

L2TP is a protocol that tunnels a PPP session across an IP network, so the far end sees a point-to-point link as if you’d connected to it directly. It was published as RFC 2661 in August 1999 and runs over UDP port 1701. It provides the tunnel. It doesn’t provide encryption.

The “Layer 2” part is the bit people skip. L2TP doesn’t just forward your IP packets. It carries a whole Layer 2 session, PPP, with its own login, its own address assignment and its own link negotiation. If the OSI layers are fuzzy, our OSI model cheat sheet puts them on one page.

L2TP didn’t come from nowhere. RFC 2661’s acknowledgements say its basic concept and many of its constructs “were adopted from L2F and PPTP”: Cisco’s Layer 2 Forwarding protocol (RFC 2341, May 1998) and Microsoft’s Point-to-Point Tunneling Protocol (RFC 2637, July 1999). So it’s a merge of two vendors’ ideas, not an extension of one of them.

What does L2TP stand for?

Layer Two Tunneling Protocol. The RFC spells out “Two”. You’ll also see “Layer 2 Tunnelling Protocol”, same thing.

What are the LAC and LNS?

Every L2TP tunnel has two ends, and RFC 2661 names them:

• LAC (L2TP Access Concentrator): the end that accepts a remote system’s connection and forwards its PPP frames into the tunnel.
• LNS (L2TP Network Server): “the logical termination point of a PPP session”, in the RFC’s words. It’s where your PPP session actually ends, gets authenticated and gets an IP address.

The classic design is compulsory tunnelling: a provider’s access box (the LAC) took a subscriber’s PPP call and tunnelled it to the network that owned the subscriber (the LNS). The subscriber never knew L2TP was involved.

Your laptop’s VPN works the other way. It’s the voluntary case. The RFC calls it a “LAC Client”, a host which runs L2TP natively. Your PC is its own LAC, and the VPN server is the LNS. Every Windows or ASA L2TP VPN works like this.

Top: compulsory tunnelling. The provider’s LAC takes your PPP call and tunnels it to the LNS, and you never see L2TP. Bottom: voluntary tunnelling. The laptop is its own LAC, the “LAC Client” in RFC 2661, and that’s how every Windows and ASA L2TP VPN works.

What is L2TPv3?

L2TPv3 is the 2005 rewrite, RFC 3931 (March 2005). Its abstract describes “tunneling multiple Layer 2 connections between two IP nodes”, so it isn’t limited to PPP any more. It can also run straight over IP as protocol 115, with no UDP header. It’s a carrier and pseudowire tool, and it isn’t what anyone means by “L2TP VPN”. When people say L2TP, they mean version 2.

How Does an L2TP Tunnel Work?

An L2TP tunnel has two layers of its own: one control connection between the two ends, and one or more sessions inside it. Each PPP connection is a session. Both ends pick their own Tunnel ID and Session ID, and they’re only locally significant.

Here’s the order of events for an L2TP/IPsec connection from Windows to a VPN server:

1. IKE phase 1 builds a protected channel between the two machines, on UDP 500. If either side detects NAT, it moves to UDP 4500.
2. IKE phase 2 (Quick Mode) builds an IPsec SA that protects only UDP port 1701 between those two addresses.
3. The L2TP control connection comes up: SCCRQ, SCCRP, SCCCN (Start-Control-Connection Request, Reply, Connected). Control messages always carry sequence numbers, so they’re delivered reliably.
4. A session comes up inside it: ICRQ, ICRP, ICCN (Incoming-Call Request, Reply, Connected).
5. PPP runs over that session: LCP negotiates the link, the user logs in (usually MS-CHAPv2), and IPCP hands the client an inside address.
6. Data flows. Data messages are unreliable, like the UDP they ride in. HELLO messages keep the tunnel alive, CDN closes a session and StopCCN closes the tunnel.

Notice the double login. IPsec authenticates the machine (a pre-shared key or a certificate) in steps 1 and 2. PPP authenticates the user in step 5. That’s two separate failures waiting to happen, and it’s why the Windows error codes later in this guide split into “IPsec layer” and “PPP layer” problems.

Two keys, two logins. IKE proves the machine with a PSK or certificate on UDP 500 (4500 behind NAT). TUNNEL is L2TP’s control connection and session, built inside that IPsec protection. Then PPP proves the user, usually with MS-CHAPv2, and IPCP hands out the inside address.

Make sense so far? Good. Because the next part is where it gets interesting.

What Is L2TP/IPsec?

L2TP/IPsec is L2TP’s UDP 1701 traffic protected by IPsec ESP in transport mode, with keys negotiated by IKE. The standard for it is RFC 3193 (November 2001), and it exists because L2TP has no real security of its own.

RFC 3193 doesn’t soften this. It says “The L2TP protocol, and PPP authentication and encryption do not meet the security requirements for L2TP.” L2TP’s tunnel authentication only happens when the tunnel starts, so it can’t protect packets one by one. PPP authenticates the user but gives no per-packet integrity or replay protection.

So RFC 3193 makes ESP mandatory for both control and data packets, and it says “Transport mode MUST be supported; tunnel mode MAY be supported.” Windows uses transport mode. Cisco’s own L2TP/IPsec guide for the ASA tells you to set the transform set to transport for exactly that reason.

There’s one more detail that matters a lot in 2026. On Cisco ASA, Cisco states plainly: “L2TP over IPsec supports only IKEv1. IKEv2 is not supported” (Cisco doc 200340). And the IETF deprecated IKEv1 in RFC 9395 (April 2023), moving its RFCs to Historic status. Hold that thought.

L2TP vs IPsec: what’s the difference?

They do different jobs, so it isn’t really either-or:

• L2TP is the delivery mechanism. It carries the PPP session, and PPP handles user login and address assignment.
• IPsec is the lock. It encrypts, authenticates and integrity-checks the packets.

The useful comparison is L2TP/IPsec vs plain IPsec. A modern remote-access IPsec VPN (IKEv2) puts your IP packets straight into ESP tunnel mode and hands out the client address with IKEv2’s own configuration payload (RFC 7296 defines attributes like INTERNAL_IP4_ADDRESS). No PPP. No L2TP. One login framework instead of two, and fewer bytes per packet, as the worked example below shows.

What is an L2TP/IPsec PSK?

The PSK (pre-shared key) is the password for the IPsec layer, the machine-level secret from steps 1 and 2. It isn’t the user’s password.

Here’s the catch. On an ASA, a PSK-based L2TP/IPsec client always lands in the DefaultRAGroup tunnel group, because the Windows client has no way to name a group. So every user of that VPN shares one key. Anyone who has that key can stand up a gateway your clients will trust. After that, the only thing protecting the user’s password is MS-CHAPv2, which Microsoft’s Security Advisory 2743314 flags as weak when it isn’t wrapped in something stronger.

Use certificates if you’re keeping L2TP/IPsec. If you must use a PSK, make it long, random and private. A PSK printed on a help page isn’t a secret.

What Ports Does L2TP Use?

The L2TP port is UDP 1701. L2TP/IPsec needs UDP 500, UDP 4500 and IP protocol 50 (ESP) open toward the VPN server. Port 1701 doesn’t need opening at the edge, because it travels inside ESP.

Microsoft’s RRAS setup guide says to allow UDP 500 and 4500 inbound to the VPN server. Cisco’s L2TP guide adds ESP. Our common ports cheat sheet has the rest of the numbers you’ll need for an exam.

Here’s a quick sanity check from the protocol design. In transport mode, ESP encrypts everything after the IP header, the UDP 1701 header included. So a capture in front of a working L2TP/IPsec server shows ESP or UDP 4500, never clear UDP 1701. See clear 1701 on the wire? The tunnel isn’t encrypted.

Fun detail: IANA lists port 1701 for both l2f and l2tp. RFC 2661 tells the two apart by the version field in the header (1 for L2F, 2 for L2TP).

What is L2TP passthrough?

L2TP passthrough is a setting on home and small-office routers, usually sitting next to IPsec and PPTP passthrough. The exact behaviour depends on the router vendor, but the idea is the same: it lets a device behind the router’s NAT reach an L2TP VPN server outside.

It only touches that VPN traffic. If nobody behind the router uses an L2TP VPN, on or off makes no difference to anything else, games included. If you do use L2TP/IPsec from behind NAT, NAT-T on UDP 4500 is what carries it (RFC 3948), so make sure UDP 500 and 4500 aren’t blocked outbound. NAT itself is covered in our NAT guide.

Is L2TP Secure?

Bare L2TP isn’t secure at all. L2TP/IPsec is as secure as the IPsec settings under it, and on a Cisco ASA those are IKEv1-only, a protocol the IETF deprecated in 2023. With certificates, AES and a strong Diffie-Hellman group, it’s still defensible for legacy clients. With a shared, published PSK, it isn’t.

The weak spots, in the order they bite:

1. IKEv1 only, at least on ASA. RFC 9395 deprecated IKEv1 and moved RFCs 2407, 2408 and 2409 to Historic. Nothing new will be built on it.
2. One shared PSK. Covered above. Everyone who knows it can impersonate the server.
3. Old crypto in old configs. Cisco’s own 2016 L2TP example uses 3DES and Diffie-Hellman group 2. According to the ASA command reference, ASA 9.15(1) removed DH groups 1, 2 and 5 from IKEv1 policies and removed esp-3des, esp-des and esp-md5-hmac from IKEv1 transform sets. If your config still uses them, an upgrade breaks it. And it was weak anyway.
4. MS-CHAPv2 inside. It’s acceptable only because IPsec wraps it. Microsoft’s advisory recommends L2TP, IKEv2 or SSTP precisely as the wrapper.

Is that a dealbreaker? Not for a branch with a few old devices that can’t run anything newer. For anything you’re building today, it is.

Worked Example: What Does L2TP/IPsec Cost on the Wire?

Every tunnel adds headers. L2TP/IPsec adds more than most, because it stacks three tunnels: IPsec, then UDP and L2TP, then PPP. Here’s one full-size packet from a Windows client behind NAT, using AES-CBC with HMAC-SHA1-96, the combination an ASA running 9.15 or later still accepts for IKEv1. Header sizes come straight from the RFCs (listed under the table).

Outer IPv4 header .................. 20
UDP header (NAT-T, port 4500) ....... 8
ESP header (SPI + sequence) ......... 8
AES-CBC IV ......................... 16
  --- encrypted from here ---
  UDP header (port 1701) ............ 8
  L2TP data header .................. 6
  PPP address/control + protocol .... 4
  Your IP packet ................. 1404
  ESP padding ....................... 0
  Pad length + next header .......... 2
  --- encrypted to here ---
ESP ICV (HMAC-SHA1-96) ............. 12
                                   ----
On the wire                        1488

So the biggest IP packet your laptop can send through this tunnel on a normal 1500-byte path is 1404 bytes. Why not 1416, since 1488 leaves 12 bytes spare? Because AES-CBC encrypts in 16-byte blocks. The encrypted part above is exactly 1424 bytes, 89 blocks. Add one more byte to your packet and the padding jumps to 15 bytes, the packet becomes 1504 bytes, and it no longer fits.

Outside in, for the packet above: IPsec 52 bytes (outer IP 20, NAT-T UDP 8, ESP 8, IV 16), TUNNEL 14 (UDP 8 + L2TP 6), PPP 4, then your packet, up to 1404. ESP’s 2-byte trailer is encrypted with it, and the 12-byte ICV follows. 1488 bytes on the wire.

Now compare it with the alternatives on the same 1500-byte IPv4 path:

Sizes: IPv4 20 (RFC 791), UDP 8 (RFC 768), NAT-T 8 (RFC 3948), ESP header 8 and trailer 2 (RFC 4303), AES-CBC IV and block 16 (RFC 3602), HMAC-SHA1-96 ICV 12 (RFC 2404), AES-GCM IV 8, ICV 16, 4-byte alignment (RFC 4106), L2TP data header 6 at minimum (RFC 2661), WireGuard data header 16 plus a 16-byte Poly1305 tag (WireGuard paper, section 5.4.6). MSS assumes 40 bytes of IPv4 and TCP headers with no options.

Three things jump out:

• L2TP’s own cost is exactly 18 bytes per packet: UDP 8 + L2TP 6 + PPP 4. Same cipher, same NAT, plain IPsec tunnel mode gets 1422. L2TP/IPsec gets 1404. That’s the whole difference.
• NAT-T costs 16 bytes of usable size here, not 8. The NAT-T header is 8 bytes, but it pushes the packet across a 16-byte block boundary. Block ciphers do that.
• SHA-256 instead of SHA-1 changes nothing in this case. Its 16-byte ICV is 4 bytes bigger, but those 4 bytes fit inside the padding slack, so the answer stays 1404. We checked it.

Two honest caveats. Some implementations set the optional Length field in L2TP data messages, which makes the header 8 bytes and the answer 1402. And if PPP negotiates address/control field compression, PPP drops to 2 bytes and the answer goes up to 1406. Run the numbers for your own stack. The method doesn’t change.

Here’s a cross-check that the method’s right. Do the WireGuard sum with an IPv6 outer header (40 bytes instead of 20) and you get 1500 – 40 – 8 – 32 = 1420. That’s the MTU on the example wg0 interface in the WireGuard paper.

What breaks if the MTU is wrong?

Say you copy a tunnel MTU of 1420 from a guide. From the office, with no NAT in the path, a full 1420-byte packet becomes 1496 bytes on the wire. Fits. From a hotel or home network behind NAT, the same packet becomes 1504 bytes. Four bytes too big.

Same laptop, same setting, one change. It works in the office and breaks at the hotel.

Same 1420-byte packet, same 1500-byte path. In the office it’s 1496 bytes on the wire and fits. Behind hotel NAT, NAT-T’s 8-byte UDP header makes it 1504, and it’s dropped. A tunnel MTU of 1404, or a TCP MSS clamp of 1364, fits both.

If the packet has DF set, it’s dropped, and the sender only learns why if the ICMP “fragmentation needed” message makes it back. When that ICMP gets filtered, you get the classic path MTU black hole that RFC 2923 describes: pings and small pages work, big downloads and HTTPS sessions stall. The fix is boring and reliable: clamp TCP MSS to 1364 or lower on the device that does MSS clamping, or set the tunnel MTU to 1404 or lower.

L2TP vs Other VPN Protocols

Here’s the full comparison. The “largest inner packet” column comes from the worked example above, behind NAT, on a 1500-byte IPv4 path. We only computed it where the header sizes are fixed by a standard.

The Windows column comes from Microsoft’s Add-VpnConnection reference: the built-in tunnel types are Pptp, L2tp, Sstp, Ikev2 and Automatic. OpenVPN and WireGuard aren’t on that list, so they need their own client.

L2TP vs PPTP: which is better?

L2TP/IPsec, easily. PPTP (RFC 2637) runs its control channel on TCP 1723, which is the PPTP port you’ll see in firewall rules, and carries data in an enhanced version of GRE, IP protocol 47. GRE has no ports, so NAT devices need a special helper to track it. Its encryption, MPPE, takes its keys from the MS-CHAP login, and PPTP with MS-CHAPv2 is exactly the combination Microsoft’s 2012 advisory is about. It says “Only VPN solutions that rely on PPTP in combination with MS-CHAP v2 as the sole authentication method are vulnerable”.

Microsoft’s current RRAS guide is blunter: “We don’t recommend that you use PPTP, due to its lack of security features.” L2TP and PPTP both carry PPP. The difference is that L2TP gets wrapped in IPsec and PPTP doesn’t get wrapped in anything.

L2TP vs IKEv2: why IKEv2 replaces it

IKEv2 is IPsec without the L2TP and PPP layers. That gives you four practical wins:

• 18 fewer bytes per packet with the same cipher (1422 vs 1404 in the example).
• A shorter handshake. IKEv1 Main Mode takes six messages and Quick Mode three more. IKEv2’s initial exchange normally takes four (RFC 7296).
• Mobility. MOBIKE (RFC 4555, June 2006) lets a client change its IP address, Wi-Fi to cellular, without rebuilding the SA.
• It’s the current standard. IKEv1 is Historic. IKEv2 isn’t.

Microsoft’s Windows Server 2025 still accepts IKEv2 by default on new RRAS setups. It no longer accepts L2TP by default. On Cisco, IKEv2 is the basis of FlexVPN and one of AnyConnect’s two transports (the other is SSL), and both are CCIE Security lab topics.

L2TP vs OpenVPN: which should you use?

OpenVPN if you can install a client. L2TP/IPsec only if you can’t.

OpenVPN uses a TLS session for authentication and key exchange, and its transport can be UDP or TCP. That TCP option is its party trick: run it on a port the network already allows and it gets through firewalls that block UDP 500 and 4500 cold. L2TP/IPsec can’t do that. Block UDP 500/4500 and ESP, and it’s dead.

What L2TP/IPsec has going for it is the built-in client. There’s nothing to install on Windows. That’s the main reason it’s still around. Is L2TP/IPsec faster than OpenVPN? There’s no honest single answer, because OpenVPN’s overhead depends on its cipher and transport, and CPU often matters more than headers. Anyone quoting a fixed percentage is guessing.

L2TP vs WireGuard: is WireGuard better?

For new builds, yes. WireGuard has fixed cryptography, Curve25519 for key exchange and ChaCha20Poly1305 for the packets, so there are no proposals to mismatch and no 3DES to forget about. Its data packets carry a 16-byte header and a 16-byte tag, so on IPv4 it carries a 1440-byte inner packet where L2TP/IPsec behind NAT carries 1404. That’s 36 bytes more payload in every full-size packet.

The trade-off is the client. WireGuard isn’t a built-in Windows tunnel type, and it has no RFC. If you need a native client on locked-down machines, IKEv2 is the answer, not WireGuard.

SSTP vs L2TP: what’s the difference?

SSTP is Microsoft’s Secure Socket Tunneling Protocol. Microsoft’s spec describes it as a way to “transport data-link layer (L2) frames on a Hypertext Transfer Protocol over Secure Sockets Layer (HTTPS) connection.” So, like L2TP, it tunnels Layer 2 frames. It just does it inside HTTPS on TCP 443 instead of inside IPsec.

That makes it the one to pick when UDP 500/4500 is blocked and every client runs Windows. Microsoft’s RRAS guide offers it as the alternative to IKEv2, and Windows Server 2025 still accepts it by default.

L2TP vs GRE: aren’t they the same thing?

Close cousins, different layers. GRE (RFC 2784) wraps network-layer packets directly in IP protocol 47 with a 4-byte base header, and it carries multicast, so routing protocols run over it. L2TP wraps a Layer 2 PPP session in UDP. Neither encrypts.

Both end up inside IPsec when you need privacy. GRE over IPsec, with multipoint GRE and NHRP added, is the foundation of DMVPN, which is very much a CCIE topic. PPTP, for the record, uses an enhanced GRE header for its data.

How Do You Set Up an L2TP Server on a Cisco ASA?

You use an ASA, not an FTD. Cisco’s FTD remote-access guide says the only supported client is Cisco’s own, and “No other clients or native VPNs are supported” (FMC 7.0 configuration guide). So the built-in Windows L2TP client can’t connect to FTD at all. If you’re moving off ASA, that’s one more reason to retire L2TP first. Our Cisco ASA end-of-life guide and FTD guide cover the migration side.

The config below follows Cisco’s TAC guide 200340, which was written for ASA 9.4(1) and Windows 8. We’ve changed its crypto to values that ASA 9.15(1) and later still accept, because the original’s encryption 3des, group 2 and esp-3des were all removed in 9.15(1).

The setup the config below is written for. A Windows L2TP/IPsec client behind a NAT router connects to the ASA’s outside address, 203.0.113.10. The tunnel ends at the ASA, which hands the client an address from the 10.10.50.0/24 pool and lets it reach the inside LAN, 10.10.1.0/24.

! Phase 1: IKEv1 is the only option for L2TP over IPsec on ASA
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 14
 lifetime 86400
!
! Phase 2: transport mode, because the Windows client uses it
crypto ipsec ikev1 transform-set L2TP-AES256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec ikev1 transform-set L2TP-AES256-SHA mode transport
!
! Clients have unknown addresses, so use a dynamic map
crypto dynamic-map L2TP-DYN 10 set ikev1 transform-set L2TP-AES256-SHA
crypto map OUTSIDE-MAP 65535 ipsec-isakmp dynamic L2TP-DYN
crypto map OUTSIDE-MAP interface outside
crypto ikev1 enable outside
!
ip local pool L2TP-POOL 10.10.50.10-10.10.50.200 mask 255.255.255.0
!
group-policy L2TP-GP internal
group-policy L2TP-GP attributes
 vpn-tunnel-protocol l2tp-ipsec
 dns-server value 10.10.1.53
!
! Local users who log in with MS-CHAP need mschap on the end
username vpnuser1 password <strong-password> mschap
!
! PSK clients always land in DefaultRAGroup
tunnel-group DefaultRAGroup general-attributes
 address-pool L2TP-POOL
 default-group-policy L2TP-GP
tunnel-group DefaultRAGroup ipsec-attributes
 ikev1 pre-shared-key <long-random-psk>
tunnel-group DefaultRAGroup ppp-attributes
 no authentication chap
 authentication ms-chap-v2
!
! Don't NAT traffic headed back to VPN clients
object network L2TP-POOL-NET
 subnet 10.10.50.0 255.255.255.0
nat (inside,outside) source static any any destination static L2TP-POOL-NET L2TP-POOL-NET no-proxy-arp route-lookup

A few lines deserve a second look:

• mode transport is the one people forget. The ASA’s default is tunnel mode, and the Windows client won’t agree to it.
• group 14 and hash sha aren’t really choices. In Cisco’s ASA 9.22 VPN configuration guide, they’re the only DH group and the only hash an IKEv1 policy accepts. That’s IKEv1 frozen in place.
• no authentication chap comes straight from Cisco’s guide: CHAP is on by default and isn’t supported when the ASA authenticates against its local database.
• The NAT rule is the usual “VPN works, can’t reach anything inside” fix. Keep the Cisco ASA commands PDF open while you build it.

What do you configure on the Windows client?

Two PowerShell commands, both from Microsoft’s VPN client module. The second one pins the client’s proposals to match the ASA, so you aren’t relying on whatever defaults that Windows build happens to offer:

Add-VpnConnection -Name "Lab-L2TP" -ServerAddress "203.0.113.10" -TunnelType L2tp -L2tpPsk "<long-random-psk>" -AuthenticationMethod MSChapv2 -EncryptionLevel Required -Force

Set-VpnConnectionIPsecConfiguration -ConnectionName "Lab-L2TP" -AuthenticationTransformConstants SHA196 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA1 -DHGroup Group14 -PfsGroup None -Force

Microsoft’s cmdlet reference describes CipherTransformConstants and AuthenticationTransformConstants as the transforms “in the IPsec policy”, so they pair with the ASA transform set (esp-aes-256 esp-sha-hmac). EncryptionMethod, IntegrityCheckMethod and DHGroup pair with the phase 1 policy (encryption aes-256, hash sha, group 14). PfsGroup None matches a dynamic map with no PFS set. The same reference says these settings apply only to IKEv2 and L2TP connections.

The ASA lines follow Cisco’s command reference and the Windows lines follow Microsoft’s. Proposals have to match on both ends, so if phase 1 fails, debug crypto ikev1 on the ASA shows what the client offered. Cisco’s own sample debug in guide 200340 shows the “Mismatched attribute” lines you’ll be looking for. A few of them are normal even on a working connection, because the client offers several proposals and the ASA turns down all but one. What matters is whether a line saying a proposal is “acceptable” follows.

Want to build this yourself? An ASAv node and a Windows VM in EVE-NG are enough. Start with our EVE-NG install guide, and our home lab guide covers sizing.

How do you verify the L2TP connection?

Three commands, all from Cisco’s guide:

• show crypto ikev1 sa shows phase 1.
• show crypto ipsec sa shows phase 2 and what it protects.
• show vpn-sessiondb detail ra-ikev1-ipsec filter protocol l2tpOverIpSec shows the logged-in L2TP user and the address they got.

Here’s a representative show crypto ipsec sa excerpt for this lab, with the client connected without NAT. It’s modelled on the output format in Cisco’s guide, not captured from a live device:

ciscoasa# show crypto ipsec sa
interface: outside
    Crypto map tag: L2TP-DYN, seq num: 10, local addr: 203.0.113.10

      local ident (addr/mask/prot/port): (203.0.113.10/255.255.255.255/17/1701)
      remote ident (addr/mask/prot/port): (198.51.100.25/255.255.255.255/17/1701)
      current_peer: 198.51.100.25, username: vpnuser1
      dynamic allocated peer ip: 10.10.50.10
      ...
    inbound esp sas:
      spi: 0x...
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={RA, Transport, IKEv1, }

What to look for:

• 17/1701 in both idents. Protocol 17 is UDP, port 1701 is L2TP. The SA protects L2TP and nothing else, exactly as RFC 3193 intends.
• Transport in the settings line. If it says Tunnel, your mode transport line didn’t take.
• esp-aes-256 esp-sha-hmac. The client accepted your proposal, not some fallback.

Why Does “The L2TP Connection Attempt Failed”?

Because one of the two logins failed, or the packets never arrived. The Windows error code tells you which. Cisco’s guide maps the common ones, and Microsoft’s docs fill in the NAT case:

Server behind NAT (error 809). Windows won’t build IPsec SAs to a server behind a NAT device by default. Microsoft’s fix (KB 926179 on Microsoft Learn) is a DWORD called AssumeUDPEncapsulationContextOnSendRule under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent. Set it to 1 when only the server is behind NAT, or 2 when both the server and the client are, then restart. It’s a registry edit, so back up first.

WAN Miniport (L2TP). That’s the virtual adapter Windows uses for its built-in L2TP client, and you’ll find it in Device Manager under Network adapters. When it breaks, Microsoft’s error 720 article says to uninstall every adapter whose name starts with “WAN Miniport”, then choose Action > Scan for hardware changes, which reinstalls them.

Connects, then stalls on big transfers? That’s not an error code. It’s the MTU problem from the worked example. Clamp MSS.

Is L2TP Deprecated in 2026?

Not formally, but everything around it is being retired:

• The IETF deprecated IKEv1 in RFC 9395 (April 2023). L2TP/IPsec on ASA can only use IKEv1.
• Microsoft: beginning with Windows Server 2025, new RRAS setups don’t accept PPTP or L2TP connections by default. You can still turn them on, in-place upgrades keep them, and the change doesn’t affect Windows client operating systems. SSTP and IKEv2 stay on.
• Cisco: FTD doesn’t accept native clients at all, ASA 9.15(1) removed the 3DES and DH group 2 that Cisco’s own L2TP example was built on, and L2TP isn’t on the Cisco exam blueprints (next section).

So L2TP/IPsec isn’t going to stop working on your Windows 11 laptop tomorrow. But the vendors have moved on, and the server side is quietly closing. If you inherited one, plan the move to IKEv2 now rather than during an outage.

Which Cisco Exams Test L2TP?

None of them. We searched the latest blueprint PDF we could pull from Cisco for each exam below, for both “L2TP” and “PPTP”, and got zero hits in every one:

Sources: Cisco’s exam-topic PDFs, fetched 2026-10-19. Cisco’s CCIE Security page lists lab v6.1 and links the SCOR v2 topics.

So why learn L2TP at all? Because it shows every idea those blueprints do test, in one place. Transport vs tunnel mode. NAT-T and why UDP 4500 exists. PSK vs certificate authentication. What encapsulation costs in MTU. That’s SCOR topic 1.5, and it’s the theory under every FlexVPN and AnyConnect lab you’ll build. If you’re on the CompTIA side instead, our Security+ practice test is a good check of the VPN basics.

Practise the Protocols That Replaced It

Reading about IKEv2 doesn’t teach you to debug it. Building it does.

Our CCIE Security workbook covers the VPN topics of the v6.1 lab on EVE-NG topologies: site-to-site IPsec, IKEv2, DMVPN, GETVPN and FlexVPN, a full AnyConnect rollout with IKEv2 remote access and certificate authentication, and VPN high availability. That’s everything L2TP/IPsec used to do, done the way the lab expects.

On Fortinet instead? The FortiGate NSE4 workbook has dial-up IPsec, IKEv2 with certificates and ADVPN labs, and our FortiGate overview covers the firewall’s VPN features.

Frequently Asked Questions

Is L2TP a VPN?

Not on its own. L2TP builds a tunnel but doesn’t encrypt it, so by itself it’s a tunnel, not a private network. Pair it with IPsec and you get L2TP/IPsec, which is a real VPN. When a device or a provider lists “L2TP VPN”, it usually means L2TP/IPsec.

What port does L2TP use?

L2TP uses UDP port 1701. L2TP/IPsec also needs UDP 500 for IKE, UDP 4500 for NAT traversal and IP protocol 50 for ESP. Only 500, 4500 and ESP need opening at the edge, because port 1701 travels inside the encrypted ESP packets.

Does L2TP encrypt traffic?

No. RFC 3193 says L2TP and PPP security don’t meet L2TP’s own security requirements, which is why IPsec ESP is mandatory in L2TP/IPsec. If you can read UDP 1701 traffic in a capture, it isn’t encrypted.

Is L2TP faster than OpenVPN?

There’s no single answer. L2TP/IPsec’s header cost is fixed and easy to count: a full-size packet behind NAT with AES-CBC carries a 1404-byte inner packet. OpenVPN’s depends on its cipher and on UDP or TCP transport, and CPU speed often matters more than headers. Test on your own hardware.

Should L2TP passthrough be on or off?

Leave it on if anyone behind the router uses an L2TP VPN. Otherwise it doesn’t matter. Passthrough only affects L2TP and IPsec VPN traffic, so turning it off won’t speed up or slow down anything else, gaming included.

What is WAN Miniport (L2TP)?

It’s the virtual network adapter Windows uses for its built-in L2TP VPN client. You’ll see it in Device Manager under Network adapters. If L2TP connections fail with error 720, Microsoft’s fix is to uninstall the WAN Miniport adapters and scan for hardware changes so Windows reinstalls them.

What’s the difference between L2TP and L2TPv3?

L2TP (version 2, RFC 2661) carries PPP sessions over UDP 1701 and is what VPNs use. L2TPv3 (RFC 3931, 2005) carries other Layer 2 traffic too and can run straight over IP as protocol 115. It’s used for carrier pseudowires, not remote-access VPNs.

Can a Cisco FTD terminate L2TP/IPsec?

No. Cisco’s FTD remote-access documentation says Cisco’s own client is the only one supported and that no other clients or native VPNs are. For native Windows L2TP clients you need an ASA, and the better long-term move is IKEv2 with Cisco’s client.