Weak IPsec pre-shared key

What the audit found

The export contains an IPsec pre-shared key — either the IPsec Secret of the L2TP server or the Secret of an IPsec identity or peer — that is weak: too short, a common word, a name, digits only, or a predictable variation of one of those. The finding names the specific weakness it found. If several keys are affected, the title says how many.

The audit can only check keys that appear in the export, which means the file was created with the show-sensitive option or on RouterOS 6. Delete that file when you are done with it.

Why it matters

A pre-shared key is the password of your VPN. Unlike a user's PPP password, which is checked after the tunnel is already encrypted, the pre-shared key is what establishes the encryption in the first place. That makes it the more sensitive of the two.

With L2TP/IPsec and IKEv1 in aggressive mode, the initial handshake between a client and your router can be captured by anyone on the path — the café WiFi, a compromised hotel network, an ISP. That capture contains enough material for an attacker to test pre-shared keys offline, at millions of guesses per second, without ever contacting your router again and without any log entry to warn you. A short or dictionary-based key falls within minutes. A long random one does not fall at all.

Once the key is known, the attacker does not just decrypt the captured session. They can impersonate your router to your users (a man-in-the-middle), receive their PPP login, and read or alter everything they send through the VPN. Every remote worker becomes a way in, and the compromise is invisible from the router's side because the connections look normal.

Note that in RouterOS the same key is usually shared by all users of an L2TP/IPsec server, so one weak key affects every one of them.

What it looks like in Winbox

For L2TP/IPsec: open PPP → Interface → L2TP Server and look at the IPsec Secret field. For plain IPsec (site-to-site tunnels or IKEv2 with a pre-shared key): open IP → IPsec → Identities and check the Secret column of each identity, or IP → IPsec → Peers on older versions.

Winbox masks the value; an export made with the show-sensitive option shows it.

How to fix it

The fix is to replace the key with one that cannot be guessed. A good pre-shared key is 4–5 unrelated words or at least 16 random characters, produced by a password manager or a random generator rather than chosen by hand, and it must not be derived from the old one. Where it goes depends on which VPN uses it: for L2TP/IPsec it is the IPsec Secret field in the L2TP Server dialog under PPP → Interface; for a site-to-site tunnel or an IKEv2 peer it is the Secret of the matching entry under IP → IPsec → Identities. The change takes effect for new connections; existing tunnels are renegotiated on their next rekey or when you restart them.

Plan the rollout, because every client and every remote router that uses this key must be updated at the same time. Do it in a maintenance window and have the new key ready to distribute securely — not by e-mail or chat. For a site-to-site tunnel, change the far end first, then the near end, and expect a brief outage. If you manage either router through the tunnel you are re-keying, switch on Safe Mode first so that a mistyped secret does not strand you.

If you are replacing keys anyway, consider whether the VPN could move to WireGuard (RouterOS 7) or IKEv2 with certificates, both of which use per-peer keys and are not vulnerable to offline guessing of a shared secret.

Afterwards, reconnect a client or bring the tunnel back up and check IP → IPsec → Active Peers for an established state. Then re-run the audit with a fresh sensitive export: 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

Users type this key into their phones. Won't a long random key be impractical?

The key is entered once per device and stored in the VPN profile, so length is not a daily burden. Distribute it through a password manager or a configuration profile rather than reading it out. If that is still unworkable, that is a strong argument for WireGuard, where each device gets its own key pair and no shared secret exists.

Every user already has their own PPP password. Isn't that protection enough?

No. The PPP password is exchanged inside the IPsec tunnel, so it is only as safe as the pre-shared key that set the tunnel up. If the key is guessed, an attacker can capture the PPP login as well. The two secrets protect different layers and both need to be strong.

Does the audit see the key on RouterOS 7?

Only if the export was made with the show-sensitive option. A plain export on RouterOS 7 hides secrets, and the audit then lists password strength as something it could not check. Either way, remove the sensitive export from your computer once the audit is done.