L2TP client runs without IPsec

What the audit found

Your router has an L2TP client interface whose use-ipsec option is not switched on. L2TP is a tunnelling protocol, not an encryption protocol: on its own it wraps your packets in a new header and sends them to the other end unchanged. IPsec is the layer that provides the encryption, and it has been left out.

The audit reports this as medium for any active L2TP client without IPsec. The severity does not depend on your firewall, because the exposure is on the path between the two tunnel endpoints, not at your router.

Why it matters

People set up an L2TP tunnel because they want a private link — to a branch office, a data centre, a cloud VPS, or a provider's network. Without IPsec, the "private" part is an illusion. Every packet that goes into the tunnel travels across the internet as readable L2TP-encapsulated traffic. Anyone able to capture it on the way — at the ISP, on a compromised router in between, on a shared uplink — sees the contents: file transfers, database queries, internal web traffic, and the PPP authentication exchange at the start.

That last point is why the finding matters even for tunnels that carry nothing sensitive. The PPP login uses a username and password from the server's secrets list. With plain L2TP, PAP sends them in cleartext; CHAP and MS-CHAPv2 are somewhat better but have known weaknesses, and MPPE — the only encryption plain L2TP can fall back on — is the same broken scheme as PPTP. A captured tunnel therefore leaks credentials that are often reused elsewhere.

L2TP/IPsec is a well-supported combination on every platform, and MikroTik's implementation sets it up with a single option. There is no good reason to run the tunnel without it.

What it looks like in Winbox

Open PPP → Interface and find the row of type l2tp-client (or Interfaces and look for the L2TP client). Double-click it. On the Dial Out tab, the Use IPsec box is unticked and the IPsec Secret field is empty. Under IP → IPsec → Active Peers there is no entry for the remote address, confirming that no encrypted association exists.

How to fix it

The fix lives in the L2TP client interface itself: tick Use IPsec on its Dial Out tab and enter the pre-shared secret agreed with the far end in the IPsec Secret field. The client then establishes an IPsec association first and starts L2TP inside it, so the PPP login and everything after it travel encrypted. Each L2TP client needs the change.

The change only works if the server side also has IPsec enabled with the same secret. If the far end is another MikroTik, its L2TP server should have use-ipsec set to required and the same secret; if the server offers IPsec only optionally, the tunnel still comes up encrypted as long as your client asks for it, which it now will. Both ends must allow UDP 500, UDP 4500 and the ESP protocol through their input chains, in addition to UDP 1701. On the client side an input chain that ends with a drop for WAN traffic is fine — the client initiates, and replies are established or related.

If you cannot get IPsec working with the far end, replace the tunnel with WireGuard on RouterOS 7 rather than leaving it unencrypted. The change cannot lock you out of the router unless you manage it through that very tunnel; in that case use Safe Mode and have another path ready.

Afterwards, wait for the interface to reconnect: IP → IPsec → Active Peers must show an entry for the remote address, the L2TP interface should show Running, and traffic through the tunnel should work as before. Then re-run the audit; the finding disappears once every L2TP client has IPsec enabled.

The full MKRouterKit report gives the exact commands for your configuration — with your interface names and subnets filled in, in the order that will not lock you out.

FAQ

The tunnel goes to my own server in a data centre. Does anyone really see it?

The traffic crosses at least two ISPs and any number of routers between the two sites. You do not control those, and neither does your provider fully. Assume any unencrypted link across the internet can be captured. It costs nothing to enable IPsec.

Will IPsec slow the tunnel down?

On modern MikroTik hardware with hardware encryption, AES throughput is well above what most L2TP links carry. On small older devices you may see lower peak throughput than plain L2TP, but that is a trade you should make. If speed genuinely matters, WireGuard is faster than L2TP/IPsec on the same hardware.

The far end is a third-party provider that only offers plain L2TP. What now?

Then everything you send through that tunnel is visible to that provider and to everyone in between. Either ask them for L2TP/IPsec, IKEv2 or WireGuard, or treat the tunnel as an untrusted link and only carry traffic over it that is itself encrypted (HTTPS, SSH).