L2TP server does not require IPsec

What the audit found

The L2TP server under PPP → L2TP Server is enabled, but its Use IPsec setting is not required. It is either no (IPsec is not used at all) or yes (IPsec is offered, but not enforced).

The distinction matters more than it looks. With Use IPsec at yes a client that sets up IPsec first gets an encrypted tunnel — but a client that simply connects with plain L2TP is also accepted. Only required refuses unprotected connections. The audit rates the finding high when IPsec is off entirely and medium when it is optional.

Why it matters

L2TP is a tunnelling protocol, not an encryption protocol. On its own it wraps PPP frames in UDP and sends them across the internet as they are. The "L2TP/IPsec" VPN that operating systems offer is really two layers: IPsec provides the encryption and authentication, and L2TP runs inside it. Remove the IPsec layer and what is left is a tunnel anyone on the path can read.

Consider a staff member connecting from a hotel or café. Their laptop is configured for L2TP/IPsec, but a mistake in the client profile — or a deliberate downgrade by someone controlling the local network — means the IPsec part never happens. With Use IPsec at yes your router accepts the connection anyway. The PPP login goes across the wireless network protected at best by MS-CHAPv2 and MPPE, which have been broken since 2012, and everything they access on the internal network afterwards is exposed to whoever is capturing traffic on that café network.

The same applies to the credentials. A captured L2TP session without IPsec gives an attacker the VPN username and enough material to recover the password offline. That password is a key to your internal network.

Setting required costs nothing for correctly configured clients and simply rejects the ones that would have connected insecurely.

What it looks like in Winbox

Open PPP → Interface and click the L2TP Server button. In the dialog, Enabled is ticked and the Use IPsec dropdown shows no or yes rather than required. When it is yes or required, the IPsec Secret field holds the pre-shared key clients must present.

How to fix it

The fix has two parts, both in the L2TP Server dialog under PPP → Interface: set Use IPsec to required, and set a strong IPsec Secret. The first makes the router reject any L2TP connection that is not wrapped in IPsec. The second is the pre-shared key every client uses for the IPsec phase; it should be a long random string from a password manager rather than a word, because with L2TP/IPsec a captured handshake lets an attacker test pre-shared keys offline. Distribute the new secret to your users together with their existing PPP credentials, and not by e-mail or chat.

Do this in a maintenance window if you have many remote users: every client that previously connected without IPsec will be refused until its profile is corrected, while clients that already used IPsec will not notice the change unless the secret changed. The change does not touch Winbox or SSH, so Safe Mode is only relevant if you are managing the router through the very L2TP tunnel you are about to change — in that case switch it on.

If you are on RouterOS 7, this is also a good moment to consider WireGuard (WireGuard menu). It is simpler to configure, faster, and does not have the optional-encryption trap that L2TP has. Keep L2TP/IPsec running with required until the migration is complete, then disable the L2TP server.

Afterwards, connect with a client configured for L2TP/IPsec and check IP → IPsec → Active Peers: your client should appear there with an established security association, while a client deliberately configured for plain L2TP should be refused. Then re-run the audit: the finding should disappear.

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

Does Use IPsec at yes not already protect my users?

Only the ones whose clients happen to set up IPsec. yes means "offer IPsec"; a client that does not ask for it is still accepted over plain L2TP. There is no reason to keep it at yes — every mainstream L2TP client supports IPsec, so required breaks nothing that was configured correctly.

My users cannot connect after the change. Why?

Almost always because the client profile has no pre-shared key, or the wrong one. On Windows, check Advanced settings → Use preshared key for authentication; on macOS and iOS it is the Shared Secret field. The PPP username and password stay the same. Also confirm UDP ports 500 and 4500 are allowed through the input chain.

Is a pre-shared key good enough, or do I need certificates?

A long random pre-shared key is adequate for L2TP/IPsec and is what almost every deployment uses. Certificates are stronger and allow per-user revocation, but for road-warrior access the practical upgrade path is WireGuard or IKEv2, both of which handle per-user keys natively.