Windows VPN Error 720: Address Pool or Client Binding?
Error 720 means the connection was never given a usable address. Separate one-host failures from many-host failures before reinstalling an adapter.
Error 720 appears after the credentials are accepted, which is why it sends people back to the password field. The connection reached the point of negotiating an address and did not get one. Two very different faults produce that same dialog: the server had nothing to hand out, or this particular client could not complete the negotiation. Separating those two before touching anything is most of the repair, and the split is documented in Microsoft's error 720 troubleshooting page.
What the Dialog Leaves Out
The message describes a failure in PPP negotiation, and it is deliberately vague because the client cannot see why the server declined. It is not a credential error, and it is not a statement about the tunnel's encryption. It means the address or the negotiation parameters were not delivered.
On the server side, the usual cause is allocation: an RRAS static pool with no free addresses, or a DHCP configuration whose scope is exhausted or unreachable, produces exactly this symptom for every client that tries. On the client side, the usual cause is a binding. The WAN Miniport that carries PPP has to be bound to the right components, and a disabled binding or an inserted network filter can stop the negotiation without any visible device problem. The two families need different evidence, and the fastest way to choose between them is to count how many clients are affected.
Split the Population Before the Pool
Count the affected clients before reading any configuration. A fault that hits everyone at once is a server condition, and a fault that follows one machine across networks is a client condition. That count costs one message in a chat channel and saves an afternoon.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
Then correlate one failing attempt with the server's own record, because RRAS logs an event when it cannot allocate and that event names the failure rather than the symptom. If the failure follows a specific client, the server log will show nothing for that attempt, which is itself informative. Absence of an allocation error narrows the problem to the negotiation on that client and tells you which commands to run next.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Read the Server's Allocation State
On the RRAS side, confirm which allocation method is actually configured rather than which one the documentation assumes. A static pool and a DHCP-relayed configuration fail in different ways, and the fix belongs to whichever is in use. For a static pool, count free addresses and look for per-user assignments that hold a lease nobody remembers making, since a pool that looks large can be fully committed. For DHCP, check that the relay reaches a server and that the scope has free leases.
A scope exhausted by ordinary clients produces the same 720 as a misconfigured pool, and the RRAS console will look perfectly healthy in both cases. Resist the inherited workaround of splitting a pool into smaller ranges: the original advice described one administrator's result, and it does not repair an allocation failure that the server's own events can name directly.
Read the Client's Bindings Without Breaking Them
If the evidence points at one client, inspect the hidden adapter rather than reinstalling the stack. The first command lists the WAN Miniport interfaces and their names; the second takes the name it returned, not a name copied from a guide.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsRead the list for the address-resolution binding and for third-party filters. A disabled binding is a targeted repair, while a filter's presence is a question for whoever owns that software rather than permission to disable a security product. Deleting every adapter is the one move that destroys the evidence you would need if the fault returns.
After the correction, retry the same profile and then repeat the two-client case if that was the original symptom, because a successful first connection hides the allocation problem a second client exposes. Keep the note to four fields: which client, which binding, which event, and what changed. Change one layer per attempt as well, since a client fix and a pool change applied together cannot be attributed, and the next failure will look new when it is the same one.