Definition
L2TP (Layer 2 Tunneling Protocol) is a standard protocol defined by IETF for establishing virtual point-to-point connections over IP networks and is the core of private network VPDNs. L2TP encapsulates PPP frames in UDP packets (UDP 1701) to create tunnels over public networks. L2TP itself does not provide encryption and is usually combined with IPSec (L2TP over IPSec) for end-to-end security, and works with RADIUS to complete access authentication.
Technical Principles and Architecture
L2TP consists of LAC (L2TP Access Concentrator) and LNS (L2TP Network Server). The LAC is deployed on the operator side (such as PGW, BRAS) and receives user PPP connections; the LNS is deployed on the enterprise side, terminates the tunnel, and assigns internal IPs to users. After dialing, the LAC and LNS establish an L2TP tunnel, and PPP frames are transmitted through the tunnel; when combined with IPSec, the entire tunnel is encrypted.
Cooperation with IPSec
L2TP over IPSec: First establish the IPSec SA, then carry L2TP within the IPSec tunnel. IPSec provides encryption and integrity , while L2TP provides multi-protocol (PPP) and user sessions. NAT-T (UDP 4500) is required for traversal in NAT environments.
Typical Use Cases
- VPDN private network access, secure backhaul for IoT devices
- Remote office VPN, enterprise branch interconnection
SimtoLink's VPDN solution uses L2TP+IPSec to ensure secure transmission of IoT data from the public network to the enterprise intranet.
L2TP is one of the core technologies of the SimtoLink VPDN private network solution. When IoT devices access via a carrier network, L2TP establishes a secure tunnel from the LAC to the enterprise LNS, combined with IPSec for end-to-end encryption. SimtoLink can provide customers with L2TP+IPSec VPDN access services to ensure secure transmission of IoT data from the public network to the enterprise intranet.
Control Connection and Session Layers
L2TP first opens a control connection between the access concentrator (LAC) and the enterprise LNS, then carries one or more sessions on that connection. The control connection keeps the tunnel alive, negotiates parameters, and tears the tunnel down. A session is one user’s PPP context, including the authentication result and the private address about to be assigned. A live control connection only means that UDP 1701 is reachable at both ends and the tunnel identifiers match. If the session is rejected, the device still looks like a dial-up timeout, or it receives an address from the wrong subnet. “Attached, PDP active” on an IoT SIM stops at the operator’s packet core. It does not mean the LNS has accepted the session.
Traffic is split into control messages and data messages. Control messages must be delivered reliably: they carry sequence numbers and are retransmitted. Data messages carry PPP frames and are not reliable by default; a higher layer has to recover a loss. When the tunnel is unstable, check the control channel for a Hello timeout before asking whether an intermediate device is dropping data-channel packets. A capture that shows only the inner IP, with no L2TP header, was usually taken after the tunnel had already been terminated.
Four Items to Align Before Opening a Private Network
An L2TP virtual private network needs four things at the same time. The operator LAC must already send that APN toward the chosen LNS. The enterprise firewall must allow UDP 1701 from the LAC’s public address, and UDP 500 and 4500 as well when IPSec is added. The tunnel password or certificate, the host name, and the tunnel identifier must match at both ends. The LNS address pool must not overlap the enterprise intranet, and the return route must point into this tunnel. Miss any one of them and the symptom looks like “the SIM is active, but the intranet is unreachable.” If a firewall allows application ports but not the tunnel ports, the LNS may not even record a negotiation.
This tunnel pulls cellular devices into an enterprise private network. It is not a way to accelerate public-internet access, and it does not replace application-layer encryption. The protocol itself neither encrypts nor checks payload integrity. Across an untrusted network it has to be wrapped in IPSec, or the application has to protect the payload end to end. As the device count grows, also confirm the LNS session capacity and the QoS marking, so every device is not forced into one tunnel with no priority, slowing the others down.
The Tunnel Looks Up, but Service Still Fails
A common mistake is to treat “tunnel up” as “the service is usable.” After the control connection is established, RADIUS can still reject PPP authentication, or the address pool can run out, and the device keeps redialing. Another case is overlapping addresses: an address handed out by the LNS falls inside an existing enterprise subnet, return packets are routed to some other intranet host, and requests leave with no response. Encapsulation overhead is easy to overlook. Stack PPP, L2TP, and IPSec, and the useful payload is often under 1500 bytes. If the endpoint still sends full-size packets and fragmentation is not allowed, large packets vanish on the way while small probes succeed.
The direction can also be reversed. Configure the LNS as the dial initiator, or put the wrong LNS domain on the LAC, and the enterprise side never sees a tunnel. Separate three layers when troubleshooting: no control connection, a control connection without a session, and a session without a return path. Swapping SIMs and retesting radio coverage will not explain those. Where address translation sits on the path and NAT-T is not enabled, negotiation can finish and then every data packet is lost, because the security association cannot match the rewritten outer port.
Address translation inside the tunnel and outside it produce completely different results. Inside, the address the device sees is not the address the server sees. An access rule written for the wrong side lets only a few hosts through. Outside, the security association must match the translated port, or the handshake completes and the service packets do not line up. Record the external address, the translated port, and the inner assigned address on the same line. License sessions for how many devices are online at once, not for how many SIMs were issued. Half-open sessions left after a drop fill the license, new dial attempts are rejected, and it still looks like unstable radio.
A capture taken after the tunnel is terminated shows only inner addresses. It cannot show whether the outer port was rewritten. Capture once outside the firewall and once inside the LNS, and compare the identifier of the same session. A record only on the inside means the packet never reached the enterprise. Records on both sides, with the service still failing, point next to the address pool and the return route.