# How L2TP Data SIMs Work: Tunnels, Sessions and RADIUS

An L2TP data SIM delivers mobile data to your own network the way wholesale broadband does: each SIM's session is carried over L2TP to your LNS, where your RADIUS authenticates and addresses it. This guide sets out how that works at the protocol level, and what to settle before the first tunnel comes up.

23 October 2026

[IoT & Mobile Data](https://netavo.com/insights)

## The path of a SIM's session

![Diagram of a device's SIM attaching to a mobile network, Netavo's mobile core carrying its session as a PPP session inside L2TP tunnels from more than one LAC, the tunnels reaching your LNS over a private interconnect, inside IPsec or over the internet, and your RADIUS authenticating the SIM and assigning its address](https://netavo.com/images/diagrams/l2tp-data-sims.svg)

The LAC is on the provider's side of the boundary; the LNS and RADIUS are on yours.

## The LAC, the LNS and the boundary between them

L2TP, the Layer 2 Tunnelling Protocol, carries PPP sessions from the network that collects them to the network that terminates them. The collecting side runs an L2TP Access Concentrator, the **LAC**. The terminating side runs an L2TP Network Server, the **LNS**.

In wholesale broadband the LAC belongs to the access network, and the LNS belongs to the ISP that owns the subscriber. An L2TP data SIM uses the same division. The mobile networks and the provider's mobile core collect the SIM's data session; the provider's LAC tunnels it to the customer; the customer's LNS terminates it.

Everything to the left of that boundary, the radio networks, roaming, the SIM's subscription and the tunnels, is the provider's. Everything to the right, authentication, addressing, routing and policy, is the customer's. That is the point of the arrangement: a SIM becomes one more subscriber on a network the customer already runs, under rules the customer already sets.

## Tunnels and sessions

L2TP has two layers of state. A **tunnel** is a control connection between one LAC and one LNS. A **session** is one PPP connection carried inside a tunnel. One tunnel carries many sessions, so a fleet of thousands of SIMs needs only a handful of tunnels.

L2TPv2 runs over UDP, on port 1701 by default. A tunnel is set up with a three-message exchange (SCCRQ, SCCRP and SCCCN), in which the two ends can authenticate each other with a shared tunnel secret. Each new session is then set up inside the tunnel with a further three messages (ICRQ, ICRP and ICCN). Hello messages keep an idle tunnel alive and let each end notice when the other has gone.

For a data SIM, a new session appears each time the SIM opens a data connection, and closes when it disconnects. To the LNS, that looks exactly like a broadband subscriber connecting and disconnecting.

## What each message does

| Message | Direction | Purpose |
| --- | --- | --- |
| SCCRQ / SCCRP / SCCCN | LAC and LNS | Open the tunnel's control connection, optionally authenticated with the shared tunnel secret |
| HELLO | Either way | Keep the tunnel alive and detect a peer that has gone |
| ICRQ / ICRP / ICCN | LAC to LNS | Open one session for one SIM inside the tunnel |
| CDN | Either way | Close one session, with a result code saying why |
| StopCCN | Either way | Close the tunnel and every session in it |

## PPP inside the session

Each session carries PPP. Once it is up, the SIM's session and the LNS negotiate the link with LCP, including the maximum receive unit, then authenticate, then configure the network layer: IPCP for IPv4, and IPv6CP followed by DHCPv6 where IPv6 is in use.

Because the LAC has already seen the start of the PPP negotiation, it can pass what it learned to the LNS in the session set-up messages, so the LNS can authenticate without starting PPP again. Whether that proxy information is used, or the LNS renegotiates from scratch, is a setting on the LNS; both work.

## RADIUS decides who connects and with what address

When a session reaches the LNS, the LNS asks RADIUS whether it may connect. An **Access-Request** carries the session's identity. An **Access-Accept** carries the answer, and with it whatever the LNS should apply: typically a **Framed-IP-Address** for a fixed address, a **Framed-Pool** to take one from a pool, **Framed-Route** for a subnet behind the device, and any filter or rate policy the LNS understands. An **Access-Reject** refuses the session.

Once a session is up, the LNS sends RADIUS **accounting** : a Start when it opens, Interim-Updates while it runs, and a Stop when it closes, each with the octets carried. That gives a per-SIM usage record in the same system that already holds your broadband subscribers' usage.

With Netavo L2TP data SIMs, this RADIUS is yours. You decide which SIMs may connect, which address each gets, and what policy applies, and you can refuse a SIM without asking anyone.

## RADIUS attributes most often used

| Attribute | Sent in | Used for |
| --- | --- | --- |
| User-Name | Access-Request | Identifying the session being authenticated |
| Framed-IP-Address | Access-Accept | A static address for the SIM, or one chosen from a pool |
| Framed-Pool | Access-Accept | Naming the LNS address pool to assign from |
| Framed-Route | Access-Accept | A subnet routed to the SIM, for a router with a LAN behind it |
| Session-Timeout | Access-Accept | Forcing a session to reconnect after a set time |
| Acct-Status-Type | Accounting-Request | Start, Interim-Update or Stop |
| Acct-Input-Octets / Acct-Output-Octets | Accounting-Request | Data carried in each direction, for usage and billing |

## Static addresses that survive anything

Because the address comes from your RADIUS and not from the provider, it belongs to the SIM's identity and not to the path the session took. A SIM that reconnects through a different tunnel, a different LAC, or after its device has moved to a different mobile network, receives the same address again.

That makes inbound access simple. A device with a known, fixed address on your own network can be reached by your systems directly, with no port forwarding, no dynamic DNS and no VPN client on the device.

## MTU and the overhead of the tunnel

Every packet carried for a SIM is wrapped in PPP, L2TP, UDP and an outer IP header before it crosses to your LNS. Over IPv4 that adds roughly 40 bytes: 20 for the outer IP header, 8 for UDP, 8 to 12 for L2TP and 2 for PPP. Carrying the tunnel inside IPsec adds the ESP overhead on top, typically another 50 to 70 bytes depending on the cipher.

If the path between the LAC and your LNS carries 1500-byte packets, the SIM's sessions cannot also carry 1500-byte packets without fragmentation. The usual answer is to negotiate a lower MRU in LCP, such as 1460, and to clamp TCP MSS on the LNS so TCP connections never send segments that need fragmenting. A private interconnect that carries larger frames removes the problem for the tunnel itself.

Symptoms of an MTU mismatch are distinctive: a SIM connects and small requests work, but large downloads or TLS handshakes stall. It is worth testing with full-size packets before a fleet goes live.

## Three ways for tunnels to reach the LNS

| Transport | Encrypted in transit | Points to settle |
| --- | --- | --- |
| Private interconnect (on-net NNI) | Not exposed to the internet | Cross-connect location, VLAN, and addressing for the tunnel endpoints |
| L2TP inside IPsec | Yes, by IPsec | IPsec peers and proposals, and the extra MTU overhead |
| Over the internet | No; L2TP itself does not encrypt | Firewalling UDP 1701 to the provider's LAC addresses, and the tunnel secret |

## Resilience on both sides

On the provider's side, tunnels from more than one LAC mean the loss of one LAC does not take the fleet down: sessions that drop reconnect through a tunnel that is still up. Netavo delivers L2TP data SIM tunnels from more than one LAC for this reason.

On your side, the LNS can be made resilient the same way: more than one LNS, each reachable by the tunnels, with RADIUS reachable from both. Because addressing comes from RADIUS, a SIM that reconnects to a different LNS can still receive the same address, provided both LNSs can route it.

## Before the first tunnel comes up

Most L2TP problems are agreements that were never written down. Settle these with your provider first:

- **Tunnel endpoints:** the LAC addresses tunnels will come from, and the LNS addresses they should reach.
- **Tunnel authentication:** whether a tunnel secret is used, and how it is exchanged.
- **Transport:** private interconnect, IPsec or the internet, and the MTU that results.
- **Session identity:** what the LNS will see in User-Name for each SIM, so RADIUS can recognise it.
- **Addressing:** static per SIM or from a pool, IPv4 and IPv6, and any routed subnets behind devices.
- **Resilience:** how many LACs and LNSs, and how sessions should behave when one fails.
- **Accounting:** the interim-update interval, and where usage records are kept.
- **Testing:** a handful of SIMs through every path, with full-size packets, before the fleet.

## Common questions

### What is the difference between a LAC and an LNS?

The LAC, the L2TP Access Concentrator, collects PPP sessions and tunnels them over L2TP. The LNS, the L2TP Network Server, receives the tunnels and terminates each session, authenticating it against RADIUS and assigning its address.

### Which L2TP version do data SIMs use?

Delivery of PPP sessions to an LNS uses L2TPv2, defined in RFC 2661, running over UDP on port 1701 by default.

### Does L2TP encrypt data SIM traffic?

No. L2TP carries sessions but does not encrypt them. Where traffic must be encrypted in transit, the tunnels are carried inside IPsec or over a private interconnect.

### Why do large downloads stall on an L2TP SIM when small ones work?

Usually an MTU mismatch. The tunnel adds around 40 bytes per packet over IPv4, more inside IPsec, so the session MRU should be lowered and TCP MSS clamped on the LNS.

### Can a data SIM keep the same IP address over L2TP?

Yes. The address is assigned by your RADIUS for the SIM's identity, so the SIM receives the same address whichever tunnel, LAC or mobile network it connects through.

### How is usage measured for L2TP data SIMs?

The LNS sends RADIUS accounting for each session, with Start, Interim-Update and Stop records carrying the octets carried in each direction.

## Related services and sectors

### [L2TP Data SIMs: Mobile Data Delivered to Your LNS](https://netavo.com/services/l2tp-data-sims)

Mobile data SIMs tunnelled over L2TP to your own LNS, authenticated and addressed by your RADIUS, like a broadband subscriber.

### [IoT & Mobile Data](https://netavo.com/services/iot)

Global multi-network SIMs on our own mobile core, with internet access or a private network for device fleets.

### [ISP BNG & CGNAT Systems](https://netavo.com/services/bng)

Netavo BNG, a carrier-grade x86-based BNG and CGNAT platform for internet service providers.

### [ISPs & Network Operators](https://netavo.com/sectors/isps-and-network-operators)

Wholesale broadband, transit, backhaul and addressing for UK ISPs and altnets, with Netavo BNG software for subscriber termination and CGNAT.

### [Industrial IoT & Remote Assets](https://netavo.com/sectors/industrial-iot-and-remote-assets)

Connect unattended industrial equipment to central systems with multi-network SIMs, private networking and data pooled across a device fleet.

## Discuss L2TP data SIMs

Tell us about your LNS and RADIUS and how the tunnels should reach you. An engineer will work through the design with you.

[Work with us](https://netavo.com/work-with-us)

Source: https://netavo.com/insights/l2tp-data-sims-explained