IKEv2 vs L2TP/IPsec: which profile does your server run?
One label hides two stacks, three kinds of secret and different behaviour when the address changes. Sort out the layers before comparing the menus.
The two names appear side by side in the same dropdown, which invites a choice between equals. They are not equals. L2TP is a tunnelling protocol with no confidentiality of its own, and the protection in an L2TP/IPsec service comes from the IPsec layer wrapped around it. IKEv2 negotiates an IPsec association directly and has no tunnel-inside-tunnel step. Knowing which stack your server offers decides the profile, the prompts and what happens when the laptop changes networks.
Two stacks, one label in the client
L2TP carries a point-to-point session over UDP to port 1701 and leaves encryption to whoever wraps it. Pair it with IPsec and you get two layers: an IPsec association protecting the path, and an L2TP session inside it carrying the user's link-layer frames and PPP authentication.
IKEv2 creates a control association and then one or more child associations that protect traffic, all in one exchange family on UDP 500 and 4500. There is no inner tunnelling protocol and no PPP negotiation.
Credentials: three secrets living on three layers
This is where most support time disappears. An L2TP/IPsec profile can ask for a pre-shared key for the IPsec layer and a username with password for the PPP session inside, and the two are checked by different components. The shared key belongs to the gateway as a whole, so it identifies no one; it only proves the peer knows a secret.
IKEv2 commonly uses certificates, or EAP with a username and password, and it can use a pre-shared key as well. Those options are not interchangeable with the L2TP pair. A password reset that fixes a rejected EAP login does nothing for an expired client certificate, and no amount of retyping the account password will satisfy a wrong gateway key. When a prompt appears that you did not expect, ask the operator which layer it belongs to before guessing.
| Question | L2TP/IPsec | IKEv2 |
|---|---|---|
| What encrypts the traffic | A wrapping IPsec association | The child association |
| Ports you must permit | UDP 500/4500 and UDP 1701 inside | UDP 500 and 4500 |
| Typical secrets | Gateway PSK plus PPP credentials | Certificate, EAP, or PSK |
| Address change | Tunnel breaks, reconnect needed | Can migrate with MOBIKE |
What MOBIKE changes, and what it does not
IKEv2 can move an association to a new address when both endpoints support MOBIKE, which covers the case of a laptop leaving Wi-Fi for a phone hotspot without tearing down the security association.
It does not keep every application alive across that move. The transport flow still changes address, sockets bound to the old one still break, and a policy that pins traffic to an interface can still drop it. Test the transition you actually perform, whether that is leaving a network, waking from sleep or coming back after a long idle period, and watch the application rather than the Connected label.
Failure shapes that separate them
An L2TP/IPsec profile that reaches the gateway and stops tends to fail on one of two prompts: the shared key, or the PPP credentials. A wrong key usually shows nothing useful in a client log, while a wrong password produces an explicit authentication rejection, and the difference tells you where to look.
An IKEv2 profile fails earlier and more loudly when the identity or certificate is wrong, because the control association never completes. If the association completes and traffic still fails, the problem has moved to the child association, the traffic selectors or the route, and no credential change will help.
Where each still fits
L2TP/IPsec persists because it is present on almost every client and needs no extra software, which matters for a contractor on a device you do not manage. The cost is the extra layer, the shared-secret model and a reconnect after every address change.
IKEv2 fits managed devices better: certificate identity, cleaner mobility, and one association family to reason about. It also fails harder when the client is old, so check the supported authentication method for the platform before designing around it.
Testing the profile you were given
Confirm the mode from the server side first, then pick the client profile that matches it. Test with the exact hostname and credentials issued for that profile, and verify the private resource rather than a public site.
If it connects and nothing loads, the tunnel is working and the route, DNS or traffic selector is not. Changing the protocol at that point restarts the diagnosis instead of advancing it.