Falta el passthrough de PPTP: corrige el error 807 de Windows VPN

Reenviar el TCP 1723 a menudo abre la primera parte de PPTP y deja el resto roto, así que Windows sigue devolviendo el error 807 en el intento. El siguiente impulso es añadir una regla para el puerto 47, y justo ese paso es el que desperdicia una tarde: GRE es un número de protocolo en la cabecera IP, no un puerto que una tabla de reenvío pueda emparejar. Hasta que el router deje pasar el protocolo 47 y lo ate a la misma llamada, el túnel no puede arrancar. Las secciones siguientes separan los dos canales y después los prueban uno a uno.

Una tabla de puertos no tiene fila para un número de protocolo

PPTP usa dos conversaciones que fallan de maneras distintas. La de TCP 1723 inicia la llamada, entrega la información del enlace y la cierra cuando el usuario se desconecta. El lado de la carga útil corre dentro de GRE, que la cabecera IP etiqueta con el número de protocolo 47, y dentro de ese túnel PPP negocia el enlace mientras MS-CHAPv2 comprueba las credenciales.

Como GRE no lleva cabecera de transporte, no expone ningún puerto, así que una regla escrita para puertos no tiene nada que emparejar. Un router que reenvía el 1723 crea una asignación para esa sesión TCP y se detiene ahí. El firmware que gestiona la segunda mitad llama a la función passthrough de PPTP o PPTP ALG, y algunos firmwares no ofrecen ninguna de las dos y nunca mencionan el hueco. La etiqueta de la casilla importa menos que si el protocolo 47 se reconoce o no.

Qué informa Windows cuando muere la ruta de datos

El error 807 dice que la conexión no se pudo completar, lo que en la práctica significa que la llamada llegó al servidor y el canal de datos no se levantó. Es un veredicto sobre el transporte, no sobre la cuenta. El error 691 es el que apunta a las credenciales o a un desajuste del protocolo de autenticación, así que te envía a otro sitio por completo.

Trabaja el transporte antes de tocar la contraseña. Cambiar las credenciales para perseguir el 807 deja el fallo real en su sitio y hace que el siguiente intento sea más difícil de leer.

Por qué un segundo cliente rompe un túnel que funciona

Sin puertos que los distingan, un dispositivo NAT no puede separar dos clientes PPTP como separa dos sesiones HTTPS. Por eso muchos equipos domésticos permiten una sola llamada PPTP y la siguen por dirección de origen. Un portátil que funcionaba solo deja de completar en cuanto un segundo equipo marca, y desde el lado del cliente el fallo parece aleatorio. Ese patrón pertenece al firmware, y ningún cambio de perfil lo alterará.

Observa la tabla de conexiones mientras ambos clientes marcan. Si solo el primer equipo tiene alguna vez una asignación, el router ha llegado al límite de lo que admite y ningún ajuste del cliente lo moverá.

Demuestra qué mitad está fallando

Confirma que el TCP 1723 llega antes de cambiar nada en el router, porque esa respuesta decide qué mitad estás probando. Ejecuta estos comandos desde el cliente Windows contra tu propio nombre de servidor. El primero imprime si el puerto respondió, y el segundo marca sin diálogo, lo que hace comparables los intentos repetidos.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Un resultado verdadero en la prueba del puerto significa que el canal de control está abierto y que GRE es el sospechoso restante. Un resultado falso significa que el enrutamiento, un filtro o el reenvío están rotos, y ningún cambio en GRE lo salvará. El lado de datos debe vigilarse donde pueda verse, en el servidor o en el router.

tcpdump -ni any proto 47

El equivalente en Wireshark es el filtro de visualización ip proto 47, que es más fácil de pasar a alguien que no está cómodo en una línea de comandos. Un GRE que llega sin que salga nada en respuesta significa que hay que arreglar la ruta de vuelta.

Qué arregla realmente el error

Donde el router expone el ajuste, activa el passthrough de PPTP o permite el protocolo 47 de forma explícita en firmware que acepte reglas. En RouterOS la regla de reenvío empareja el protocolo directamente, algo que un reenvío basado en puertos nunca podría hacer. El firmware de consumo suele esconder la misma decisión tras una casilla, a veces en los ajustes de seguridad y no en el reenvío de puertos. Si no existe tal control, nada en el cliente lo compensará.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Sustituir PPTP es la otra opción y a menudo la más barata. Un router que termina la VPN él mismo evita el doble NAT para los clientes entrantes, y un protocolo que un NAT basado en puertos ya maneja no necesita ningún passthrough: OpenVPN sobre UDP, SSTP sobre TCP 443 o L2TP/IPsec con NAT-T que envuelve ESP en UDP 4500. PPTP también depende de MS-CHAPv2, cuyas debilidades documentadas lo convierten en una mala elección para un despliegue nuevo incluso después de que el error desaparezca.

Anota qué regla marcó la diferencia, porque el mismo sitio encontrará el mismo límite cuando el segundo usuario pida acceso. Una corrección a nivel de protocolo pertenece a las notas de red, donde mirará el siguiente ingeniero.