Self-Hosted L2TP/IPsec VPN Server: xl2tpd vs accel-ppp vs Linux L2TPv3 (2026)

Layer 2 Tunneling Protocol (L2TP) combined with IPsec encryption remains one of the most widely supported VPN protocols across platforms — natively available on Windows, macOS, iOS, Android, and Linux without installing third-party clients. While WireGuard and OpenVPN dominate modern VPN deployments, L2TP/IPsec fills a specific niche: maximum client compatibility with reasonable security. In this guide, we compare three self-hosted L2TP server implementations: xl2tpd, accel-ppp, and the Linux kernel L2TPv3 module.

Why L2TP/IPsec Still Matters

Despite being superseded by modern protocols, L2TP/IPsec is still the default VPN choice for many enterprise environments because every major OS includes a built-in L2TP client. No software installation is needed on the client side — users simply configure a VPN connection in their OS network settings. This makes L2TP/IPsec ideal for:

• Corporate remote access where IT cannot mandate client software installation
• Mobile device management with minimal configuration overhead
• Legacy systems that only support L2TP/IPsec
• Temporary or guest VPN access without client distribution

The security model relies on IPsec (typically IKEv2 with ESP) for encryption and authentication, while L2TP provides the tunnel encapsulation. The combination is considered secure when configured with strong ciphers (AES-256, SHA-256, 2048-bit+ DH groups).

xl2tpd — The Standard L2TP Daemon

xl2tpd (xelerance/xl2tpd) is the most widely deployed open-source L2TP server, a fork of the original l2tpd project by Xelerance, with 563+ GitHub stars. It handles the L2TP tunnel and session management, while IPsec is provided by a separate daemon (Libreswan, StrongSwan, or Openswan).

Key Features

• L2TPv2 protocol support
• Multiple simultaneous tunnels and sessions
• PAP/CHAP authentication
• Integration with pppd for PPP session management
• RADIUS accounting support
• IPv4 and IPv6 passthrough
• Compatible with all major IPsec implementations
• Well-documented and battle-tested

Installation with Libreswan

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

# Debian/Ubuntu
apt install xl2tpd libnss3-tools
apt install libreswan

# Configure IPsec (Libreswan)
cat > /etc/ipsec.conf << 'IPSEC'
config setup
    protostack=netkey
    uniqueids=no

conn l2tp-ipsec
    keyingtries=0
    rekey=no
    left=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    ike=aes256-sha2;modp2048
    phase2alg=aes256-sha1
    type=transport
    authby=secret
    auto=add
IPSEC

# PSK for authentication
echo 'PSK "your-strong-pre-shared-key"' > /etc/ipsec.secrets

# Configure xl2tpd
cat > /etc/xl2tpd/xl2tpd.conf << 'XL2TPD'
[global]
listen-addr = 0.0.0.0
port = 1701

[lns default]
ip range = 192.168.42.10-192.168.42.50
local ip = 192.168.42.1
require chap = yes
refuse pap = yes
name = l2tpd
ppp debug = no
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
XL2TPD

# PPP options
cat > /etc/ppp/options.xl2tpd << 'PPP'
require-mschap-v2
ms-dns 8.8.8.8
ms-dns 8.8.4.4
proxyarp
mtu 1400
mru 1400
deflate 0
novj
novjccomp
logfile /var/log/xl2tpd.log
PPP

# User credentials
echo 'username l2tpdpassword *' > /etc/ppp/chap-secrets
chmod 600 /etc/ppp/chap-secrets

Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

version: "3.8"
services:
  l2tp-vpn:
    image: hwdsl2/ipsec-vpn-server:latest
    network_mode: host
    privileged: true
    environment:
      - VPN_IPSEC_PSK=your-strong-pre-shared-key
      - VPN_USER=vpnuser
      - VPN_PASSWORD=vpnuserpassword
    volumes:
      - /lib/modules:/lib/modules:ro
    restart: always

accel-ppp — High-Performance Multi-Protocol PPP Server

accel-ppp (accel-ppp/accel-ppp) is a high-performance PPP server supporting PPTP, L2TP, PPPoE, and IPoE protocols, with 320+ GitHub stars. Unlike xl2tpd which relies on pppd, accel-ppp handles PPP natively in a multi-threaded architecture, delivering significantly higher throughput and connection density.

Key Features

• L2TP, PPTP, PPPoE, and IPoE in a single daemon
• Multi-threaded architecture for high concurrency
• Built-in RADIUS client for authentication
• Traffic shaping and bandwidth limiting
• IP address pool management
• VLAN tagging support
• SNMP statistics export
• Built-in web monitoring interface

Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

# /etc/accel-ppp.conf
[modules]
l2tp
ppp_auth_pap
ppp_auth_chap
ppp_auth_mschap_v2
ppp_ipcp
ippool
log_file
radius
net-snmp

[l2tp]
verbose=1
attr-tunnel-vendor=0
single-session=replace
incoming-filter-ip=no

[l2tp-dict]
dictionary=/etc/accel-ppp/l2tp.dictionary

[ppp]
verbose=1
min-mtu=1400
mtu=1400
mru=1400
mppe=require
ipv4=require
ipv6=deny
lcp-echo-interval=60
lcp-echo-timeout=30
lcp-echo-failure=3

[ip-pool]
192.168.42.10-192.168.42.100

[radius]
server=127.0.0.1,1812,secret,auth-only
server=127.0.0.1,1813,secret,acct-only
dae-server=127.0.0.1:3799,secret
verbose=1
timeout=3
req-limit=0

[dns]
dns1=8.8.8.8
dns2=8.8.4.4

[log]
log-file=/var/log/accel-ppp/accel-ppp.log
log-emerg=/var/log/accel-ppp/emerg.log
copy=1
level=5

Docker Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

version: "3.8"
services:
  accel-ppp:
    image: xebd/accel-ppp:latest
    network_mode: host
    cap_add:
      - NET_ADMIN
    volumes:
      - ./accel-ppp.conf:/etc/accel-ppp.conf:ro
    restart: always

Linux Kernel L2TPv3 — Built-in Tunneling

The Linux kernel includes native L2TPv3 support through the l2tp_eth and l2tp_netlink modules. Unlike xl2tpd (which implements L2TPv2 in userspace), the kernel L2TPv3 module provides L2TP tunneling at the kernel level with minimal overhead. It is configured using the ip l2tp command from iproute2.

Key Features

• Kernel-space performance (no context switching)
• L2TPv3 protocol (successor to L2TPv2)
• Ethernet and IP encapsulation modes
• Configurable via iproute2 (ip l2tp commands)
• No additional daemon required for tunnel management
• Compatible with any userspace L2TPv3 peer
• Integrated with Linux networking stack

Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Enable kernel modules
modprobe l2tp_core
modprobe l2tp_eth
modprobe l2tp_netlink

# Create L2TPv3 tunnel (static, no signaling protocol)
ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1     local 10.0.0.1 remote 10.0.0.2     encap udp udp_sport 5000 udp_dport 5000

# Create L2TPv3 session
ip l2tp add session tunnel_id 1 session_id 10     peer_session_id 20

# This creates a netdev (l2tpeth0) that can be configured
ip link set l2tpeth0 up
ip addr add 192.168.100.1/24 dev l2tpeth0

Key Difference from xl2tpd

The kernel L2TPv3 module does not implement the L2TP Control Connection Protocol (L2TPv2 signaling). It provides raw L2TPv3 tunnels that must be set up statically or managed by a custom control daemon. For dynamic L2TPv2 connections (what most VPN clients expect), you still need xl2tpd or accel-ppp.

Comparison Table

Why Self-Host Your L2TP VPN Server?

Self-hosted L2TP/IPsec gives you complete control over remote access infrastructure without per-user licensing fees. Commercial VPN appliances and cloud VPN services charge per concurrent connection — with xl2tpd or accel-ppp, you can serve hundreds of users on a single $5/month VPS.

For organizations that need maximum client compatibility, L2TP/IPsec remains the most universally supported VPN protocol. Every major operating system includes a native L2TP client, meaning zero client deployment overhead. This is particularly valuable for BYOD environments, guest access, and temporary contractors.

Running L2TP behind a properly configured nftables firewall adds network-level access control, while pairing with a strong IPsec implementation like Libreswan ensures encrypted transport. For additional access management, consider integrating with a self-hosted auth platform for centralized identity management across all remote access services.

Choosing the Right L2TP Server

• xl2tpd is the standard choice for traditional L2TP/IPsec VPN deployments. Its compatibility with pppd, Libreswan, and RADIUS makes it the most documented and widely used option.
• accel-ppp is ideal for ISP-scale deployments or when you need multi-protocol support (L2TP + PPPoE + PPTP) with high performance and built-in RADIUS.
• Linux kernel L2TPv3 is best for static point-to-point tunnels between known endpoints where maximum performance and minimal overhead are required. Not suitable for dynamic remote access VPNs.

FAQ

Is L2TP/IPsec still secure in 2026?

When configured with strong ciphers (AES-256-GCM, SHA-256, 2048-bit+ DH groups), L2TP/IPsec provides adequate security for most use cases. However, the NSA has historically been suspected of weakening L2TP implementations. For maximum security, prefer WireGuard or OpenVPN. L2TP/IPsec is best used when client compatibility is the primary requirement.

Why does L2TP need IPsec?

L2TP provides tunneling but no encryption. IPsec provides the encryption, authentication, and integrity protection for the tunneled traffic. The two protocols are always used together — L2TP without IPsec sends data in plaintext.

Can xl2tpd handle IPv6 traffic?

xl2tpd can carry IPv6 traffic within the PPP session, but the L2TP control connection itself is IPv4-only. For full IPv6 L2TP support, consider accel-ppp or the kernel L2TPv3 module.

What port does L2TP/IPsec use?

L2TP uses UDP port 1701 for tunnel control. IPsec uses UDP port 500 (IKE key exchange) and UDP port 4500 (NAT traversal). These ports must be open on your firewall.

How many concurrent users can xl2tpd support?

xl2tpd with pppd typically handles 500-1,000 concurrent connections on a modern server. The bottleneck is usually pppd (one process per connection). accel-ppp, being multi-threaded, can handle 10,000+ connections on the same hardware.

Can I use certificates instead of PSK for L2TP/IPsec?

Yes, Libreswan and StrongSwan both support certificate-based IPsec authentication. Replace the PSK in /etc/ipsec.secrets with certificate references. This provides stronger authentication, especially for large deployments.