Si los usuarios pueden conectarse sin problemas a la VPN cuando están dentro de la red local, pero la sesión se cae de inmediato al intentar desde Internet, casi siempre el culpable es el cortafuegos perimetral y, en concreto, la falta de reenvío del protocolo GRE que necesita PPTP. A continuación encontrarás un análisis detallado de la causa, las acciones correctivas y una alternativa moderna y segura con L2TP‑IPsec.
Resumen de la pregunta
- Servidor Windows Server con RRAS (Routing & Remote Access Service) y NPS (Network Policy Server).
- VPN montada inicialmente con PPTP.
- Conexiones internas estables; conexiones externas se interrumpen con el mensaje: “The network connection between your computer and the VPN server was interrupted…”.
- En el firewall se reenvían los puertos UDP 1812/1813/1645/1646 (RADIUS) y, por error, también UDP 1701/500/4500.
- La duda: “¿qué puerto o configuración falta para que la VPN funcione desde Internet?”
Causa principal
PPTP usa dos componentes: la sesión de control TCP 1723 y el túnel de datos encapsulado con el GRE (protocolo IP 47). La mayoría de firewalls domésticos y varios gateways empresariales solo gestionan reglas basadas en puertos (TCP/UDP); por tanto, aunque se abra TCP 1723, el tráfico GRE nunca alcanza al servidor y la sesión cae tras el intento de autenticación.
Solución paso a paso
| Paso | Acción | Comentario |
|---|---|---|
| 1 | Comprobar requisitos reales de PPTP | PPTP necesita TCP 1723 (control) + GRE 47 (datos). El reenvío solo por puertos no cubre GRE. |
| 2 | Habilitar GRE o exponer el servidor como DMZ | En la interfaz del firewall busca “PPTP Pass‑Through”, “GRE Forwarding” o “Default/DMZ host”. Al activarlo, ambas partes (TCP 1723 y GRE 47) alcanzan al servidor y la VPN se mantiene conectada. |
| 3 (mejor práctica) | Migrar a L2TP‑IPsec | Si el firewall (por ejemplo un gateway Linux con iptables) no maneja NAT de GRE, abandona PPTP. Abre/reenvía UDP 500 (IKE), UDP 4500 (NAT‑T) y UDP 1701 (L2TP). Configura un certificado o clave pre‑compartida en RRAS y en los clientes. Resultado: conexión estable y cifrado robusto. |
| 4 | Revisar puertos RADIUS | Los puertos UDP 1812/1813 se necesitan solo si los clientes externos contactan directamente al NPS. Si NPS está local al RRAS y no atiende solicitudes RADIUS desde la WAN, no los abras hacia Internet. |
Secuencia típica de éxito luego de las correcciones
- Cliente inicia PPTP y negocia la sesión TCP 1723.
- Servidor responde; el cliente cambia a GRE 47 para el tráfico PPP.
- Se negocian protocolos de autenticación (MS‑CHAP v2, EAP, etc.).
- Cliente recibe dirección IP interna, rutas y DNS del servidor.
- Tráfico de usuario fluye a través del túnel sin cortes.
Puertos y protocolos implicados
Un vistazo rápido a lo que debe o no abrirse:
| VPN / Servicio | Protocolo | Puerto / N.º IP | Propósito |
|---|---|---|---|
| PPTP (control) | TCP | 1723 | Establece y mantiene la sesión de control PPP. |
| PPTP (datos) | IP | 47 (GRE) | Encapsula los paquetes PPP (datos reales). |
| L2TP | UDP | 1701 | Túnel L2 (Layer 2) sin cifrar. |
| IPsec IKE v1/v2 | UDP | 500 | Negociación de seguridad SA. |
| IPsec NAT‑T | UDP | 4500 | Encapsulación de ESP a través de NAT. |
| RADIUS autenticación | UDP | 1812 / 1645 | Sólo si los clientes contactan al NPS. |
| RADIUS contabilidad | UDP | 1813 / 1646 | Opcional para informes de uso. |
Cómo habilitar GRE o PPTP Pass‑Through en firewalls comunes
pfSense (CE y Plus)
- Ve a Firewall → NAT → Outbound.
- Elige “Hybrid Outbound NAT”.
- Añade una regla GRE (protocolo 47) con la IP interna del RRAS.
- Aplica y prueba la conexión.
MikroTik RouterOS
/ip firewall nat
add chain=dstnat protocol=tcp dst-port=1723 action=dst-nat to-addresses=192.168.1.10
add chain=dstnat protocol=gre action=dst-nat to-addresses=192.168.1.10
Cisco ASA
access-list outsideaccessin extended permit tcp any host 203.0.113.10 eq 1723
access-list outsideaccessin extended permit gre any host 203.0.113.10
Firewall de Windows (en la NIC externa del RRAS)
- Habilita las reglas predefinidas:
Routing and Remote Access (GRE‑in)
Routing and Remote Access (PPTP‑in) - En la pestaña Ámbito limita la regla si solo quieres permitir ciertas IP origen.
Alternativa recomendada: L2TP‑IPsec
PPTP fue declarado en desuso por Microsoft desde Windows 10 2004 y no se considera seguro porque:
- MS‑CHAP v2 tiene vulnerabilidades de diccionario.
- GRE carece de integridad y cifrado.
- No es compatible con EAP-TLS.
En cambio, L2TP‑IPsec o IKEv2 ofrecen:
- Cifrado AES 256, autenticación mutua con certificados o PSK.
- Compatibilidad con NAT gracias a UDP 4500 (NAT‑T).
- Mejor soporte en dispositivos móviles (Android/iOS).
Pasos resumidos para migrar
- En RRAS, habilita “L2TP con IPsec”.
- En NPS, crea o ajusta directivas de acceso remoto para EAP‑MSCHAP v2 o EAP‑TLS.
- Genera un certificado de servidor (puede ser autofirmado) y expórtalo con su clave.
- Importa el certificado en
Local Machine → Personal → Certificates. - Asegúrate de que el certificado raíz esté en “Trusted Root Certification Authorities” en los clientes.
- En el firewall, abre/reenvía
UDP 500,UDP 4500yUDP 1701. - Configura el perfil VPN en los clientes especificando “L2TP con IPsec” y la clave pre‑compartida o el certificado raíz.
Buenas prácticas adicionales
- Registrar eventos: revisa
Event Viewer → Custom Views → Server Roles → Network Policy and Access Servicespara errores de autenticación y negociación. - Auditoría de firewall: mantén un log aceptable durante al menos 24 h para identificar bloqueos intermitentes.
- Segmentación de red: coloca el servidor RRAS en una zona DMZ interna y filtra el acceso solo a puertos necesarios hacia LAN.
- Bloqueo de fuerza bruta: establece límites de intentos fallidos y habilita account lockout o Smart Lockout en Azure/Active Directory si aplica.
- Actualizaciones KB: instala parches de seguridad de RRAS y NPS, especialmente los que corrigen CVE de spoofing en IKE y vulnerabilidades RADIUS.
Verificación paso a paso (PowerShell)
Comprobación de puertos expuestos
Test-NetConnection -ComputerName vpn.midominio.com -Port 1723
Comprobación de protocolo GRE
GRE no usa puertos; usa IP 47, por lo que no es detectable con Test-NetConnection. Sin embargo, puedes monitorizar con Wireshark en el servidor:
ip proto 47 and host <IP pública cliente>
Diagnóstico de negociación L2TP‑IPsec
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\Parameters" -Name "NegotiateDH2048_AES256" -Value 1 -Type DWORD
Con ello activas IKE fuerte (DH 2048 y AES 256) en servidores antiguos.
Ejemplo de registro de éxito
Date : 2025-08-01 09:17:42
Source : RemoteAccess
Event ID : 20276
Message : CoId={8E6A...} The user <USUARIO> has successfully connected on port VPN2-127.
Conclusión
Cuando una VPN PPTP funciona dentro de la LAN pero no desde Internet, casi siempre falta reenviar el protocolo GRE. La solución es sencilla: habilitar “PPTP Pass‑Through” o, mejor aún, migrar a L2TP‑IPsec para saltar las limitaciones técnicas y de seguridad de PPTP. Tras abrir UDP 500/4500/1701 y configurar certificados o PSK, la conexión queda estable y segura para usuarios remotos.