PPTP a través de un punto de acceso: TCP 1723 es solo la mitad

Recorre las comprobaciones en orden: si se abre la conexión de control, si GRE sobrevive a la ruta, si el servidor acepta la llamada y si la autenticación se completa. Un cliente PPTP necesita tanto una sesión TCP en 1723 como una ruta GRE que transporte los datos, y un punto de acceso puede dejar pasar una y descartar la otra. Hacerlo en orden te dice qué frontera investigar en lugar de adivinar. Los números de error de Windows no lo hacen por ti.

GRE es el protocolo IP 47. No es el puerto 47 de TCP ni de UDP, y esa distinción explica la mayor parte de la confusión sobre los cortafuegos.

Dos rutas, una conexión

La conexión de control es una sesión TCP normal al puerto de destino 1723, que la mayoría de las redes permite sin objeciones. La ruta de datos es GRE, protocolo 47, y un cortafuegos que permite lo primero puede ignorar por completo lo segundo. Esa combinación produce un cliente que parece arrancar y luego no transporta nada, un síntoma mucho menos informativo que una conexión rechazada. Prueba ambas rutas por separado antes de concluir nada sobre el operador.

La traducción añade su propio requisito. Las pasarelas que comparten puertos suelen necesitar un ALG que entienda PPTP para reescribir los identificadores de llamada junto con las direcciones, y una sin él puede estropear la sesión de formas que parecen pérdida de paquetes. Ese comportamiento es habitual pero depende de la implementación, así que trata cualquier límite de un fabricante como un ejemplo y no como una propiedad de todos los puntos de acceso.

El punto de acceso añade dos fronteras más

El tráfico del cliente suele atravesar el NAT de compartición del propio teléfono y después una traducción de nivel de operador antes de llegar al servidor. Una regla en el router de la oficina no puede reparar un dispositivo intermedio que pertenece a otra persona, y por eso el reenvío de puertos en el lado de casa rara vez ayuda. Un cliente saliente tampoco necesita un puerto de entrada abierto; las respuestas a una conexión traducida vuelven por el estado que creó la pasarela. Un servidor alojado detrás de NAT tiene un conjunto de requisitos completamente distinto.

Un elemento de menú etiquetado como PPTP passthrough, cuando existe, determina cómo maneja ese dispositivo este protocolo. No es la misma función que alojar una VPN en el teléfono o reenviar cada protocolo sin condiciones, y activarlo no es un permiso general para dejar pasar GRE.

Lee el 807 como una interrupción, no como un veredicto

Windows informa del 807 como una conexión interrumpida, lo que describe el resultado y no una causa. Su tabla de errores trata el 806 por separado como la categoría relacionada con GRE, y esa diferencia merece conocerse antes de construir una teoría. Ninguno de los dos números revela si el operador filtró el protocolo 47, si el servidor se quedó sin capacidad o si las credenciales eran correctas. El error dice que la sesión terminó; la ruta dice dónde.

Una prueba de navegador que funciona en el punto de acceso solo demuestra que una ruta de aplicación normal funciona. No dice nada sobre GRE.

Aísla la etapa que falló

Mantén fijos el portátil, el servidor y el perfil, y cambia solo la red de acceso por otra aprobada. Si el resultado cambia, captura los intercambios TCP y GRE en las fronteras que controlas y encuentra la etapa más temprana que nunca ocurre: establecimiento del control, preparación de la llamada, entrega de datos o autenticación PPP. Cada una deja una firma distinta en una captura. Comparar una red que funciona con una que falla es mucho más informativo que releer el texto del error.

Todo esto diagnostica un despliegue que ya existe. No es un argumento para levantar un servicio PPTP nuevo, y el protocolo no se puede sortear negociando: instalar un cliente distinto no hace que un servidor sin cambios hable otra cosa.

Para el acceso continuo, acuerda una migración compatible con quien sea dueño de la VPN. La lista de comprobación termina con una decisión en lugar de con un apaño.