L2TP/IPsec fails when the IKEEXT service is disabled

One laptop reaches an IKEv2 gateway but fails against an L2TP/IPsec one, and the error arrives before any user name is sent. The profile is usually the first suspect and usually the wrong one. Windows runs IPsec keying in a service, and while that service is disabled the built-in client has no stack to negotiate with. Confirm the service before touching a single profile field, then find out what disabled it.

The service behind the failure

IKE and AuthIP IPsec Keying Modules, shown as IKEEXT in the service list, performs the key exchange and holds the UDP 500 and 4500 sockets on Windows. Disable it and L2TP/IPsec and IKEv2 both lose their negotiator, while PPTP and SSTP can keep working because they do not depend on it. That split is why a user can report one VPN type working and another dead on the same machine. The service is part of the operating system, so no profile setting can stand in for it.

Freeing those two ports is the side effect that produces bad advice. A tool or a forum post notices that 500 and 4500 are occupied, stops the service to release them, and silently removes IPsec from the host. The two effects are one action, so any guide that recommends clearing the ports is describing a trade rather than a repair.

Put the service back without guessing

Ask the service manager two questions: what is the startup type, and what is the current state. The first tells you whether the service will return after a reboot; the second tells you whether it is running now. Run both queries from an elevated prompt so the same shell can change the setting afterward.

sc qc ikeext
sc query ikeext

A startup type of Disabled explains the whole symptom, and the fix is to set it back to Automatic and start it. In the Services console the entry appears under its display name, IKE and AuthIP IPsec Keying Modules, so searching for IKEEXT in that list finds nothing. Reboot if the service was started after a failed connection had already run, because a stack initialised in that order can fail in ways that look unrelated.

sc config ikeext start= auto
net start ikeext

What switches it back off

Some third-party VPN suites ship their own IPsec implementation and disable IKEEXT during installation, after which the Windows client stops working. Removing the other product has restored L2TP/IPsec on machines where profile edits achieved nothing, and so has reinstalling it without the conflicting component. The service was disabled at install time, not toggled by the user.

Group Policy can pin the startup type as well, in which case a local change is reverted at the next refresh and the administrator who owns the policy has to change it. Record the startup type before a reboot, after a reboot and after the other product updates, with the date each time. A value that keeps returning to Disabled identifies its owner by the pattern, not by guesswork.

Read the stage, then the log

With the service running, the stage of the failure decides where to look next. A stall during IKE usually means UDP 500 or 4500 never reached the server, or the server sits behind NAT without the matching encapsulation setting. Reaching the credential prompt and failing there is a PPP authentication problem, not an IPsec one. A tunnel that comes up and reaches nothing is a routing or split-tunnel fault, and only the first of those three lives in the VPN profile.

Certificate profiles add a stage of their own. The client has to trust the issuing authority and the certificate has to name the server being validated; when either condition fails, the dialog still reports an initial-negotiation error, so the event log is where the real reason appears. Read the log entry before editing the profile, because the dialog compresses several distinct failures into one sentence. An expired certificate produces the same dialog as a disabled service did, which is why the log entry matters.

Capture the failing stage, the error text and the timestamp for each attempt. Those three fields separate a reachability problem from an authentication problem from a routing problem, and they make the next change a decision instead of a guess.

What a local repair cannot prove

Restoring the service fixes the half of the path that lives on the laptop. A working service proves only the local half: the far end must still accept the chosen proposal, the supplied credentials and the source address the packet arrives from. Nothing done on the laptop compensates for a firewall that discards UDP 500 before it reaches the peer. A successful service state is a precondition, not evidence that the tunnel will come up.

Disabling IKEEXT to release the ports is defensible only if you accept that Windows IPsec VPNs stop working. It resolves a port conflict by removing the feature that needed the port, which is rarely the trade the user intended. Before changing anything, confirm the service is present, set to Automatic and running, that no second IPsec stack is installed, and that the pre-shared key or certificate chain matches the gateway.

• IKEEXT is present, set to Automatic, and running before the client connects.
• Nothing else is holding UDP 500 or 4500.
• No second IPsec stack remains from an old client.
• The key or certificate chain matches the gateway configuration.
• The failing stage was recorded before the profile was edited.