Error 720 de VPN en Windows: ¿grupo de direcciones o enlace del cliente?
El error 720 significa que la conexión nunca recibió una dirección utilizable. Separe los fallos de un solo host de los fallos de muchos hosts antes de reinstalar un adaptador.
El error 720 aparece después de aceptar las credenciales, y por eso devuelve a la gente al campo de la contraseña. La conexión llegó al punto en que se negocia una dirección y no obtuvo ninguna. Dos fallos muy distintos producen ese mismo cuadro de diálogo: el servidor no tenía nada que repartir, o este cliente concreto no pudo completar la negociación. Separar esos dos antes de tocar nada es la mayor parte de la reparación, y la distinción está documentada en la página de solución de problemas de Microsoft sobre el error 720.
Lo que el cuadro de diálogo omite
El mensaje describe un fallo en la negociación PPP, y es deliberadamente vago porque el cliente no puede ver por qué rechazó el servidor. No es un error de credenciales, ni una afirmación sobre el cifrado del túnel. Significa que no se entregaron la dirección ni los parámetros de negociación.
Del lado del servidor, la causa habitual es la asignación: un grupo estático de RRAS sin direcciones libres, o una configuración DHCP cuyo ámbito está agotado o es inalcanzable, produce exactamente este síntoma en todos los clientes que lo intentan. Del lado del cliente, la causa habitual es un enlace. El WAN Miniport que transporta PPP debe estar enlazado con los componentes correctos, y un enlace deshabilitado o un filtro de red insertado puede detener la negociación sin ningún problema visible en el dispositivo. Las dos familias necesitan pruebas distintas, y la forma más rápida de elegir entre ellas es contar cuántos clientes están afectados.
Separe la población antes del grupo
Cuente los clientes afectados antes de leer cualquier configuración. Un fallo que golpea a todos a la vez es una condición del servidor, y un fallo que sigue a una máquina entre redes es una condición del cliente. Ese recuento cuesta un mensaje en un canal de chat y ahorra una tarde.
| 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 |
Después relacione un intento fallido con el propio registro del servidor, porque RRAS registra un evento cuando no puede asignar y ese evento nombra el fallo en lugar del síntoma. Si el fallo sigue a un cliente concreto, el registro del servidor no mostrará nada para ese intento, lo cual es informativo en sí mismo. La ausencia de un error de asignación reduce el problema a la negociación de ese cliente y le dice qué comandos ejecutar después.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Lea el estado de asignación del servidor
Del lado de RRAS, confirme qué método de asignación está configurado realmente y no cuál supone la documentación. Un grupo estático y una configuración retransmitida por DHCP fallan de formas distintas, y la solución corresponde al que esté en uso. En un grupo estático, cuente las direcciones libres y busque asignaciones por usuario que mantengan una concesión que nadie recuerda haber hecho, porque un grupo que parece grande puede estar totalmente comprometido. En DHCP, compruebe que el retransmisor llega a un servidor y que el ámbito tiene concesiones libres.
Un ámbito agotado por clientes normales produce el mismo 720 que un grupo mal configurado, y la consola de RRAS se verá perfectamente sana en ambos casos. Resista el remedio heredado de dividir un grupo en rangos más pequeños: el consejo original describía el resultado de un administrador, y no repara un fallo de asignación que los propios eventos del servidor pueden nombrar directamente.
Lea los enlaces del cliente sin romperlos
Si las pruebas apuntan a un cliente, inspeccione el adaptador oculto en lugar de reinstalar la pila. El primer comando enumera las interfaces WAN Miniport y sus nombres; el segundo toma el nombre que devolvió, no un nombre copiado de una guía.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLea la lista en busca del enlace de resolución de direcciones y de filtros de terceros. Un enlace deshabilitado es una reparación dirigida, mientras que la presencia de un filtro es una pregunta para el propietario de ese software y no un permiso para desactivar un producto de seguridad. Borrar todos los adaptadores es el único movimiento que destruye las pruebas que necesitaría si el fallo vuelve.
Tras la corrección, reintente el mismo perfil y luego repita el caso de dos clientes si ese era el síntoma original, porque una primera conexión correcta oculta el problema de asignación que expone un segundo cliente. Mantenga la nota en cuatro campos: qué cliente, qué enlace, qué evento y qué cambió. Cambie también una capa por intento, ya que una corrección del cliente y un cambio del grupo aplicados juntos no se pueden atribuir, y el siguiente fallo parecerá nuevo cuando sea el mismo.