Run L2TP Without IPsec on Linux: xl2tpd, pppd and NAT

Plain L2TP is PPP in an envelope, and nothing else. It carries your frames; it does not encrypt them and it does not prove who sits at the other end, which is the reason nearly every deployment slides IPsec underneath it. Honest reasons to run the bare version still exist: a lab bench, a migration step, or a link that is already inside another protected path.

If you go ahead, put that caveat in the design note and keep it there. What follows is the operational path I use on Debian and RHEL-family hosts: which file owns what, the MTU that prevents the classic stall, and the forwarding rules that make the tunnel worth having.

Three files split the work

xl2tpd terminates the control connection and hands each session to a PPP daemon, so configuration is spread across two programs that never read each other's files. The listener lives in /etc/xl2tpd/xl2tpd.conf, inside a [lns default] section that names the address pool with ip range, the server end with local ip, and the hand-off to PPP with pppoptfile. Turn on require authentication = yes, leave length bit and flow bit enabled, and choose a pool that nothing else on the host already uses.

PPP policy belongs in whatever file that option names, normally /etc/ppp/options.xl2tpd: auth, refusals for pap, chap and mschap, require-mschap-v2, an MTU and MRU of 1460, and a DNS address the client can reach after the link is up. Credentials are a third file again, /etc/ppp/chap-secrets, where the second field has to match the LNS section name and the fourth field may pin a specific address from the pool.

Why the tunnel connects and then stalls

A 1500-byte Ethernet frame does not fit inside a path that already spends bytes on its own headers. The outer IPv4 header costs 20, UDP costs 8, and the L2TP header about 12, which leaves 1460 for PPP and its payload. Advertising that smaller figure in PPP is what keeps large packets from being fragmented or dropped silently somewhere in the middle.

The symptom is a tunnel that looks healthy until real traffic arrives: pings and control messages pass, a file copy hangs, nothing in the log explains it. Lower MTU and MRU together on both ends. Adjusting only the client usually converts a hard stall into an intermittent one, which is worse to diagnose.

One port carries two conversations

UDP 1701 sits under both halves of the protocol, and that single fact breaks more firewall rules than any other part of the setup. A start-control-connection request and its reply come first; the session request and confirmation that follow establish nothing more than the identifier pair. PPP takes over afterwards, with link control, then authentication, then IP control protocol to settle addresses. Each stage has its own vocabulary in the log, and none of them announces itself as an L2TP failure.

Reading a capture in exactly that order tells you which stage failed, and a PPP authentication failure will not be repaired by editing xl2tpd. The shared port explains another common failure: a rule that permits only the first packets of a flow lets the session establish and then blocks the transfer. Permit 1701 for the whole conversation, both directions.

Making the tunnel useful: forwarding and NAT

A session by itself only reaches the server. Client internet access needs forwarding, a NAT rule for the pool on the uplink, and DNS the client can actually query once the link is up. The pool also has to stay clear of the LAN range, or replies addressed to clients get delivered locally instead of being pushed back into the tunnel.

On the server, enable forwarding with sysctl -w net.ipv4.ip_forward=1, translate the pool with iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, then accept outbound tunnel traffic with a FORWARD rule for -i ppp0 -o eth0 and return traffic with the mirror rule plus -m state --state RELATED,ESTABLISHED. Persist those rules across reboots, because a server that comes back without them looks exactly like a broken L2TP configuration.

Reaching the server's own LAN is a different task: add a return route for the pool on the LAN router, or proxy ARP on the server. Hiding clients behind NAT when something inside the LAN must address them directly just schedules a second debugging session for later.

What the bare stack does not do, and how to verify

No part of this stack encrypts the PPP frames, and nothing in it authenticates the far end as the server you actually chose. MS-CHAPv2 does shield the credential exchange from a listener who is only watching, yet an attacker positioned in the path can still interfere with the session. The Windows native client offers L2TP only in combination with IPsec, so budget for Linux, router firmware and third-party clients as your peers. Treat the bare configuration as a diagnostic stepping stone, never as the place to stop.

Verify in a fixed order: run xl2tpd -D in the foreground, watch the journal for the PPP stage, read the assigned address from ip addr on both ends, then capture UDP 1701 to confirm that data flows after the session is up. If all four line up and traffic still fails, the fault is routing, NAT or MTU rather than L2TP itself.