L2TP/IPsec error 789, 720 or 691: fix the right stage first

Windows 11 reports a different number for each L2TP/IPsec stage, and that number marks a stage rather than scoring the failure. 789 fails before the PPP link exists, 720 fails while the link is being brought up, and 691 fails after the link is up and the credentials are rejected. The useful decision is not which fix is most popular; it is which stage the code proves you have reached. Read that first, then change one layer per attempt so the next code still tells you something.

Read the code as a stage, not a fault list

An L2TP connection crosses three boundaries in a fixed order. IKE negotiates security associations over UDP 500, NAT traversal moves that traffic to UDP 4500, and only then does the L2TP tunnel carry a PPP session that authenticates the user and assigns an address.

That order is why a changing error code is useful evidence. Going from 789 to 720 means IPsec now negotiates and the failure has moved to link setup. Going from 720 to 691 means the link came up and the gateway rejected the identity. If you apply five fixes at once, you lose that signal and cannot tell which change worked.

789: choose between the path and the local policy

Code 789 is a processing error during initial security negotiations. IPsec never produced a usable association, so the account has not been tested yet. Start with the path and the shared secret, not with the account.

Confirm that UDP 500 and UDP 4500 reach the server and that the pre-shared key matches byte for byte, including case and trailing spaces. If the server sits behind NAT, Windows may also need the documented registry value. Use 1 when the server is behind NAT and 2 when both ends are, then reboot because the policy agent reads the value at start:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

The heavier adapter repair belongs to the other branch. Removing the Wi-Fi device and the WAN miniports, then rescanning for hardware, is justified when the local IPsec stack itself is damaged and other VPN types fail the same way. It is wasted effort when only one L2TP server fails while every other network path works.

720: choose between this adapter and the server pool

Error 720 reports that the connection to the remote computer could not be established, and it appears after IPsec succeeded. The tunnel reached the point of bringing up an interface or obtaining an address, then stopped. That makes it a local adapter question or a server capacity question.

Use blast radius to decide. One Windows machine failing points at a bad WAN miniport, a stopped Remote Access service or a corrupted connection profile. Several clients failing at the same time points at the server: an exhausted address pool, a stopped RRAS service or a pool that no longer matches the client subnet. Fix the side that the pattern implicates before changing the other.

On the single-client branch, remove the WAN miniports once and scan for hardware changes, then reboot and retry. On the server branch, check the pool and the service state rather than the client, because reinstalling a working adapter cannot create an address that the server does not have.

691: choose between the credential and a stopped helper

Code 691 is an authentication rejection, and it is the code most often misread as a wrong password. The tunnel is up, the gateway saw an identity, and it refused the identity. The cause can still sit outside the password field.

Check the domain field first, then the exact characters in the password. A password containing a space, a quote or a shell-special character can be mangled before it reaches the server; on Linux, pppd reports the same rejection as E=691 for an unquoted value or a missing domain. Retype the secret instead of pasting it, and clear any saved credential that may hold an older value.

The branch people miss is a stopped helper service. When a vendor client depends on its own service to pass credentials to the gateway, a disabled or crashed service produces 691 even though the password is correct. Check the vendor service state before resetting the account, especially after a reboot or an update.

To separate the branches, test the same username against another working VPN profile or a RADIUS test account. If that succeeds, the credential is fine and the local client path is suspect. If it fails the same way, the account or the gateway policy is the problem.

Change one layer per attempt

Work from the outside in: reachability and NAT traversal, then the pre-shared key, then the local adapter stack, then the credential, then the server pool and services. That order follows the stages the codes describe and keeps each result attributable to one change.

Keep a short log of the code before and after each attempt, the client build, and whether the server or the client was changed. A sequence such as 789, then 720, then 691 is a map of progress; the same code twice means the last change did not address that stage. Reinstalling Windows erases this map and rarely fixes a failure that lives at the gateway.

When the code stops changing, stop changing things. Capture the current code, the server address, the authentication method and the time of the attempt, then compare that record with a client that works. The difference between the two records is usually smaller than the list of fixes people try by default.