PPTP es una trampa: por qué debes evitarlo y qué usar en su lugar

Si alguna vez te has quedado mirando un icono de VPN “Conectado” mientras tu aplicación agota el tiempo de espera, felicidades: has conocido
la clase especial de interfaz mentirosa que los VPN heredados hacen posible. PPTP es el abuelo de esas fallas—lo bastante antiguo como para
estar por todas partes, lo bastante frágil como para arruinarte la tarde y lo bastante inseguro como para arruinarte el trimestre.

PPTP todavía aparece en routers heredados, plantillas antiguas de Windows y en integraciones “temporales” de proveedores que de alguna forma
duran años. La decisión correcta no es ajustarlo. La decisión correcta es eliminarlo. Este texto es deliberadamente directo: PPTP está
obsoleto, ha sido roto de formas que importan y hay opciones mejores que además son más fáciles de operar.

Qué es realmente PPTP (y por qué se comporta de forma extraña)

PPTP significa Point-to-Point Tunneling Protocol. Fue diseñado para tunelizar PPP (Point-to-Point Protocol) sobre redes IP.
Piensa en supuestos de la era del módem: autenticar con métodos PPP, luego envolver tramas en un túnel y enrutar como si estuvieras
“en la LAN”.

PPTP usa dos piezas distintas:

• Canal de control TCP en el puerto 1723 para la configuración y gestión del túnel.
• Encapsulación GRE (protocolo IP 47) para los datos realmente tunelizados.

Ese detalle de GRE importa operativamente. PPTP no es “solo un puerto TCP”. Es una sesión TCP más una encapsulación separada no-TCP que
muchos firewalls, dispositivos NAT y grupos de seguridad en la nube manejan mal. Cuando alguien dice “abrimos el 1723 y aún no funciona”,
no es mala suerte. Se están topando con el diseño del protocolo.

La autenticación se hace típicamente con MS-CHAPv2, y el cifrado—si está habilitado—es MPPE (Microsoft Point-to-Point Encryption), que
se basa en RC4. Esto no es una “pila criptográfica moderna”. Es una pieza de museo que accidentalmente tiene acceso a la red.

Por qué deberías evitar PPTP en 2025

El problema con PPTP no es que sea “viejo”. El problema es que es viejo en exactamente las formas equivocadas: autenticación débil,
criptografía débil y comportamiento de transporte frágil en redes modernas. Si lo usas, estás apostando tu postura de seguridad a que
los atacantes sean perezosos y a que el camino de red sea inusualmente amigable. Eso no es una estrategia. Es pensamiento deseoso.

1) MS-CHAPv2 hace práctica la captura y crackeo de contraseñas

Las implementaciones de PPTP suelen usar MS-CHAPv2. El handshake puede ser capturado por un atacante activo (o uno pasivo en algunos
entornos), y la seguridad efectiva a menudo colapsa a una búsqueda de clave DES debido a la estructura del protocolo. Traducción: el mejor
escenario es que tu seguridad dependa de una contraseña que nunca estuvo pensada para resistir ataques offline a escala.

Si estás pensando “pero usamos contraseñas fuertes”, haz la pregunta más relevante: ¿aplicamos contraseñas fuertes de forma consistente,
para cada cuenta que puede autenticarse, incluidos proveedores, cuentas de servicio y laptops antiguas de ejecutivos? PPTP castiga la
seguridad “casi”.

2) MPPE/RC4 no es donde quieres apoyar la confidencialidad

Incluso si exiges cifrado en PPTP, te apoyas en MPPE con RC4. RC4 tiene una larga historia de sesgos y deprecación en estándares de seguridad.
Más importante aún, las debilidades de autenticación en PPTP significan que la historia del cifrado no es separable limpiamente de la de
la autenticación. No puedes decir “la criptografía está bien; es solo un túnel”.

3) GRE a través de NAT: un dolor operativo recurrente

Las redes modernas están llenas de NAT, balanceadores, firewalls stateful, enrutamiento asimétrico y “appliances de seguridad” que venden más
marketing que análisis de paquetes. GRE no se comporta como flujos TCP/UDP, y muchos dispositivos tienen dificultades para rastrearlo de forma
fiable, especialmente a través de NAT. Espera fallos intermitentes, tráfico unidireccional y usuarios diciendo “funciona en mi hotspot móvil pero
no en casa”.

4) Fallos de MTU y fragmentación son comunes y fáciles de diagnosticar mal

PPTP añade overhead. PPP añade overhead. GRE añade overhead. Si lo ejecutas a través de caminos con MTU efectiva más pequeña (común en la nube
y en ISP), obtienes problemas de PMTUD, fragmentos que se pierden o conexiones misteriosamente lentas. Los usuarios ven “VPN conectada pero
SharePoint no funciona”, y te comes horas antes de descubrir que es solo el tamaño de paquetes.

5) Postura de cumplimiento y auditoría: perderás argumentos que no deberías

Muchas organizaciones tienen controles base que efectivamente prohíben PPTP. Incluso si logras que “funcione”, gastas capital político y tiempo
de ingeniería defendiendo una decisión legada. Los auditores no necesitan ser criptógrafos para entender “protocolo VPN obsoleto con debilidades
conocidas”. Esa conversación termina igual siempre: “por favor migren”.

Broma #1: La seguridad de PPTP es como cerrar la puerta principal pero dejar la llave debajo de una roca etiquetada “KEY”. Técnicamente hay una cerradura.

Hechos e historia que explican el lío

PPTP no es malvado; es producto de su época. Entender esa época explica por qué el protocolo luce como lo hace—y por qué no encaja ahora.

1. PPTP apareció a mediados de los 90 cuando el acceso remoto significaba módems dial-up y “la red corporativa” eran subredes de confianza.
2. Estuvo fuertemente asociado con ecosistemas Microsoft, buscando que el acceso remoto en Windows se sintiera nativo y sencillo para empresas.
3. PPTP tuneliza PPP, por eso verás características de la era PPP: MS-CHAP, MPPE y patrones de negociación previos al diseño moderno de VPN.
4. Usa GRE para datos—no UDP—porque el diseño asumía que la red cooperaría y porque GRE era una herramienta de encapsulación común entonces.
5. MS-CHAPv2 se desplegó ampliamente porque se integraba con flujos de credenciales de Windows y expectativas de Active Directory.
6. Se demostraron ataques prácticos serios contra MS-CHAPv2 hace años, y la comunidad de seguridad avanzó, aunque muchas redes no lo hicieron.
7. Varios grandes proveedores de OS depreciaron o eliminaron soporte PPTP, forzando clientes de terceros o soluciones alternativas en flotas modernas.
8. NAT se volvió ubicuo después de que las decisiones de diseño de PPTP ya eran fijas, y la relación de GRE con NAT ha sido incómoda desde entonces.
9. Las VPN modernas viraron hacia UDP y un intercambio de claves robusto (IKEv2, VPNs basadas en TLS, protocolos basados en Noise como WireGuard) porque Internet es hostil y desordenada.

Cómo falla PPTP en el mundo real (modelo de amenazas, no marketing)

El atacante que debes asumir que existe

No necesitas un estado-nación para tener un mal día. Las amenazas realistas son:

• Captura de credenciales y crackeo offline tras captura de un handshake o phishing seguido de intentos de fuerza bruta contra la VPN.
• Atacantes en el camino en cafeterías, hoteles y algunos entornos ISP/empresariales donde el tráfico puede observarse o manipularse.
• Middleboxes mal configurados que “a veces” dejan pasar GRE, creando incidentes de disponibilidad intermitente que parecen error de usuario.
• Movimiento lateral interno una vez que un dispositivo comprometido se autentica con éxito y obtiene un punto de apoyo a nivel de red.

Modo de fallo: “Cifrado activado” pero la seguridad aún colapsa

Con PPTP, la gente suele aferrarse a la casilla: “Requerir MPPE”. El problema es que si la autenticación puede ser coaccionada o crackeada,
el cifrado no te salva. La criptografía no es un amuleto mágico. Es un sistema. El sistema de PPTP es frágil.

Modo de fallo: “Conectado” pero el tráfico de aplicaciones está roto

PPTP puede establecer un canal de control y aún así fallar en mover la carga útil de forma estable porque GRE está bloqueado, se rastrea mal
el estado o hay fragmentación. Los usuarios ven un icono conectado. Tú ves una cola de tickets. El protocolo fomenta falsos positivos.

Modo de fallo: respuesta a incidentes sin telemetría útil

Las pilas VPN modernas traen registros decentes, primitivas criptográficas modernas y herramientas de depuración bien entendidas. Las pilas PPTP
varían mucho según la plataforma, a menudo proveen registros escasos y te obligan a depurar a nivel de paquete más a menudo de lo que deberías para
un servicio de acceso remoto. Eso significa más tiempo para restaurar y menor confianza en el contención.

Principio de fiabilidad que aplica aquí

Cita (idea parafraseada), atribuida a Richard Cook: “El éxito oculta las debilidades del sistema; el fallo las revela.” PPTP tiende a verse bien
hasta el día que no, y entonces descubres cuánta poca tolerancia tenías.

Qué usar en su lugar: WireGuard, IKEv2/IPsec, OpenVPN y compañía

WireGuard: el predeterminado moderno para muchos equipos

WireGuard es ligero, rápido y comparativamente fácil de razonar. Usa primitivas criptográficas modernas y corre sobre UDP. Desde la perspectiva
de SRE, las ventajas operativas son reales: superficie de ataque pequeña, modelo de configuración más simple y buen rendimiento en hardware commodity.

Dónde destaca:

• VPN para usuarios remotos con una flota de clientes moderna
• Túneles site-to-site, incluyendo cloud-to-on-prem
• Alto rendimiento con bajo consumo de CPU

Dónde hay que pensar:

• Procesos de distribución y rotación de claves (hazlo como con claves SSH: intencionalmente)
• Integración de identidad y postura del dispositivo (a menudo lo combinarás con una capa de control de acceso)

IKEv2/IPsec: aburrido, estandarizado, ampliamente soportado

IKEv2 con IPsec es el clásico corporativo que realmente se ganó su lugar. Está ampliamente soportado por sistemas operativos sin clientes
adicionales, maneja mejor la movilidad que modos IPsec antiguos y funciona con suites criptográficas modernas.

Dónde destaca:

• Empresas con dispositivos Windows/macOS/iOS/Android gestionados
• Fuerte integración con autenticación basada en certificados
• Situaciones donde “sin instalación de cliente adicional” es un requisito político

Dónde hay que pensar:

• Complejidad: hay más perillas y a la gente le encanta tocarlas
• Travesía de NAT: normalmente resuelta con encapsulación UDP, pero todavía necesitas reglas de firewall correctas

OpenVPN (basado en TLS): maduro y flexible, a veces más pesado

OpenVPN es un caballo de batalla de larga vida. Es flexible, corre sobre UDP o TCP e integra muchos sistemas de autenticación. Operativamente
es sólido cuando está bien configurado, pero puede ser más intensivo en recursos que WireGuard y tiene más partes móviles.

Dónde destaca:

• Entornos que necesitan integración profunda de autenticación (RADIUS, LDAP, gateways MFA)
• Redes con restricciones inusuales donde el fallback a TCP es necesario
• Equipos que quieren un ecosistema maduro y patrones operativos establecidos

Portales SSL VPN y capas de acceso “zero trust”

A veces no necesitas una VPN a nivel L3 completa. A veces necesitas acceso a unas pocas aplicaciones internas con fuertes verificaciones de identidad
y dispositivo. Los proxies de acceso modernos pueden reducir drásticamente el radio de blast. Si tu caso de uso PPTP es “dejar que proveedores
hagan RDP en una máquina”, darles un túnel de red completo es la herramienta equivocada.

Qué no hacer: “Solo mantenemos PPTP pero añadimos MFA”

MFA ayuda contra la reutilización de credenciales y cierto phishing. No arregla el diseño débil del túnel, la fragilidad de GRE ni la deprecación
del ecosistema. MFA en PPTP es como instalar un sistema de alarma moderno en un coche sin frenos: sabrás cuando choques.

Guion de diagnóstico rápido

Cuando ocurre un incidente con PPTP, la rapidez importa. Quieres responder tres preguntas rápido: ¿está bloqueado?, ¿se autenticó? y ¿los datos
realmente fluyen?

Primero: confirma si GRE está pasando (no solo TCP 1723)

• Revisa reglas de firewall/grupos de seguridad para TCP/1723 y para el protocolo IP 47 (GRE).
• En el servidor, captura paquetes para buscar GRE durante un intento de conexión.
• Si ves solo tráfico TCP de control y no GRE, es un problema de ruta de red, no de contraseña.

Segundo: valida el método de autenticación y los registros

• Confirma si el servidor usa MS-CHAPv2 y si los clientes lo negocian.
• Busca handshakes fallidos repetidos; las políticas de rate-limit y bloqueo importan.
• Si la autenticación succeed pero el tráfico falla, deja de discutir credenciales y empieza a mirar MTU y enrutamiento.

Tercero: comprueba MTU/fragmentación y la selección de rutas

• Prueba la MTU de la ruta con sondas “no fragmentar”.
• Revisa si el cliente está forzando una ruta por defecto o haciendo split tunneling.
• Busca enrutamiento asimétrico entre el concentrador VPN y las redes internas.

Árbol de decisión (práctico)

• No se observa GRE → arregla el firewall/NAT/ruta o deja de usar PPTP.
• GRE observado, auth falla → arregla credenciales/política de auth; considera la deprecación inmediata si el riesgo de crackeo es plausible.
• Auth succeed, tráfico inestable → MTU/PMTUD/enrutamiento; considera migrar porque esto volverá a ocurrir.

Tareas prácticas con comandos: diagnosticar, medir, decidir

Las tareas abajo asumen Linux en el lado servidor (o un host de diagnóstico cercano). Los comandos son intencionadamente aburridos. Lo aburrido
es bueno en incidentes. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.

Task 1: Confirmar que el puerto de control PPTP está escuchando

cr0x@server:~$ sudo ss -lntp | grep ':1723'
LISTEN 0      128          0.0.0.0:1723      0.0.0.0:*    users:(("pptpd",pid=1412,fd=6))

Significado: El daemon está escuchando en TCP/1723 en todas las interfaces.

Decisión: Si nada está escuchando, no estás depurando un “problema de VPN”, estás depurando despliegue del servicio. Inicia/habilita el servicio o deja de fingir que PPTP existe.

Task 2: Comprobar reglas de firewall para TCP/1723 y GRE

cr0x@server:~$ sudo nft list ruleset | sed -n '1,140p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    tcp dport 22 accept
    tcp dport 1723 accept
  }
}

Significado: TCP/1723 está permitido, pero no hay un accept explícito para GRE (ip protocol 47).

Decisión: Si GRE no está permitido, PPTP “conectará” y luego fallará o se quedará estancado. O bien añades permiso a GRE (y aceptas el riesgo) o migras.

Task 3: Verificar que llegan paquetes GRE durante un intento de conexión

cr0x@server:~$ sudo tcpdump -ni eth0 'proto 47 or port 1723' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:11:03.120981 IP 203.0.113.44.51120 > 198.51.100.10.1723: Flags [S], seq 311541, win 64240, options [mss 1460,sackOK,TS val 711 ecr 0,nop,wscale 7], length 0
12:11:03.121220 IP 198.51.100.10.1723 > 203.0.113.44.51120: Flags [S.], seq 144211, ack 311542, win 65160, options [mss 1460,sackOK,TS val 155 ecr 711,nop,wscale 7], length 0
12:11:05.542110 IP 203.0.113.44 > 198.51.100.10: GREv1, call 17, seq 0, len 156

Significado: Ves tanto el handshake TCP como el tráfico GRE. La ruta de red al menos está pasando GRE.

Decisión: Si ves TCP pero no GRE, deja de perseguir auth y MTU; arregla la ruta o muévete a una VPN basada en UDP.

Task 4: Confirmar el reenvío IP (servidor actuando como gateway)

cr0x@server:~$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Significado: El servidor puede reenviar paquetes entre interfaces.

Decisión: Si es 0, los clientes pueden conectarse pero no llegarán a redes internas. Habilita el reenvío o revisa la arquitectura de enrutamiento.

Task 5: Inspeccionar logs del kernel por errores GRE/PPTP

cr0x@server:~$ sudo journalctl -k --since "30 min ago" | tail -n 8
Dec 27 12:03:41 server kernel: pptp: GRE: bad checksum from 203.0.113.44
Dec 27 12:03:41 server kernel: ppp0: renamed from pptp0
Dec 27 12:03:43 server kernel: IPv4: martian source 192.168.0.10 from 203.0.113.44, on dev ppp0

Significado: Puedes tener tráfico corrupto, rarezas de NAT o IPs privadas mal enrutadas (“martian source”) dentro del túnel.

Decisión: Si ves advertencias de checksum o martian, sospecha middleboxes o subredes superpuestas. Esto es un riesgo estructural; planifica la migración.

Task 6: Comprobar que las interfaces ppp están subiendo

cr0x@server:~$ ip link show | grep -E 'ppp|pptp'
7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3

Significado: Existe una interfaz PPP y está arriba; MTU es 1400 (a menudo reducido para disminuir fragmentación).

Decisión: Si la interfaz nunca aparece, tienes un problema de auth/daemon/config. Si aparece pero las aplicaciones fallan, mira rutas/MTU.

Task 7: Verificar enrutamiento y si los clientes VPN pueden alcanzar subredes internas

cr0x@server:~$ ip route show
default via 198.51.100.1 dev eth0
10.10.0.0/16 via 10.99.0.1 dev eth1
192.168.200.0/24 dev ppp0 proto kernel scope link src 192.168.200.1

Significado: El servidor tiene una ruta a la interna 10.10.0.0/16 vía eth1 y una subred de clientes VPN en ppp0.

Decisión: Asegura que existan rutas de retorno en routers internos hacia 192.168.200.0/24, o NATea el tráfico VPN intencionalmente (y documenta el compromiso).

Task 8: Confirmar reglas NAT si emascaras clientes VPN

cr0x@server:~$ sudo iptables -t nat -S | sed -n '1,80p'
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A POSTROUTING -s 192.168.200.0/24 -o eth1 -j MASQUERADE

Significado: La subred de clientes VPN se NATea al salir por eth1 hacia redes internas.

Decisión: NAT puede “hacer que funcione” sin cambiar rutas internas, pero oculta la identidad del cliente y complica auditoría. Decide si ese compromiso es aceptable a corto plazo.

Task 9: Detectar problemas MSS/MTU con una prueba ping DF

cr0x@server:~$ ping -M do -s 1372 -c 3 10.10.20.15
PING 10.10.20.15 (10.10.20.15) 1372(1400) bytes of data.
From 198.51.100.10 icmp_seq=1 Frag needed and DF set (mtu = 1400)
From 198.51.100.10 icmp_seq=2 Frag needed and DF set (mtu = 1400)
From 198.51.100.10 icmp_seq=3 Frag needed and DF set (mtu = 1400)

--- 10.10.20.15 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Significado: Tu path MTU es 1400 (o menor). Paquetes más grandes serán descartados si la fragmentación está bloqueada.

Decisión: Reduce MTU/MSS en el túnel, o arregla PMTUD/filtrado ICMP. También: por esto pasan los tickets PPTP en redes aleatorias.

Task 10: Comprobar ICMP bloqueado (rompe PMTUD)

cr0x@server:~$ sudo nft list ruleset | grep -n 'icmp' | head
27:    ip protocol icmp accept

Significado: ICMP está permitido (bien), lo que ayuda a PMTUD.

Decisión: Si ICMP está bloqueado, tendrás fallos de MTU en negro. Permite tipos ICMP esenciales o ajusta MSS en egress.

Task 11: Verificar intentos de autenticación de usuarios PPTP (ejemplo: Debian/Ubuntu con pptpd + PAM)

cr0x@server:~$ sudo journalctl -u pptpd --since "2 hours ago" | tail -n 12
Dec 27 10:44:12 server pptpd[1412]: CTRL: Client 203.0.113.44 control connection started
Dec 27 10:44:13 server pppd[18891]: Plugin /usr/lib/pppd/2.4.9/pptp.so loaded.
Dec 27 10:44:13 server pppd[18891]: CHAP authentication succeeded
Dec 27 10:44:13 server pppd[18891]: MPPE 128-bit stateless compression enabled
Dec 27 10:44:13 server pppd[18891]: local  IP address 192.168.200.1
Dec 27 10:44:13 server pppd[18891]: remote IP address 192.168.200.10

Significado: Auth succeed; MPPE habilitado; IPs asignadas. Esto no es un incidente de “contraseña incorrecta”.

Decisión: Pasa a enrutamiento/MTU/DNS. También considera: auth succeed significa que un atacante también puede tener éxito si las credenciales se filtran.

Task 12: Comprobar comportamiento DNS para clientes VPN (clásico “está conectado pero nada funciona”)

cr0x@server:~$ resolvectl status | sed -n '1,80p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 7 (ppp0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53

Significado: El sistema está configurado para usar DNS interno sobre la interfaz VPN.

Decisión: Si los clientes VPN no pueden resolver nombres internos, arregla los DNS empujados o la configuración split-DNS. Si no puedes empujar DNS fiable en clientes PPTP, migra.

Task 13: Identificar un cliente detrás de un NAT que rompe GRE (conntrack del servidor)

cr0x@server:~$ sudo conntrack -L -p tcp --dport 1723 2>/dev/null | head -n 5
tcp      6 431999 ESTABLISHED src=203.0.113.44 dst=198.51.100.10 sport=51120 dport=1723 src=198.51.100.10 dst=203.0.113.44 sport=1723 dport=51120 [ASSURED] mark=0 use=1

Significado: El canal de control está establecido. Esto no confirma que GRE fluya.

Decisión: Correlaciona con tcpdump de GRE. Si el control está up pero GRE ausente, la ruta NAT/firewall es la culpable.

Task 14: Validar si servicios internos ven la IP real del cliente (pregunta de auditoría)

cr0x@server:~$ sudo tcpdump -ni eth1 host 10.10.20.15 and port 445 -c 3
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:19:41.221033 IP 10.99.0.10.54812 > 10.10.20.15.445: Flags [S], seq 390011, win 64240, options [mss 1460,sackOK,TS val 921 ecr 0,nop,wscale 7], length 0

Significado: La IP origen es 10.99.0.10 (probablemente el NAT del gateway VPN), no la IP real del cliente VPN. Eso es NAT en acción.

Decisión: Si la auditabilidad importa, evita NAT y arregla el enrutamiento—o, mejor, migra a un sistema donde la identidad se maneje y registre claramente.

Task 15: Confirmar si el perímetro bloquea GRE (los grupos de seguridad en la nube a menudo lo hacen)

cr0x@server:~$ sudo iptables -S INPUT | sed -n '1,80p'
-P INPUT DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 1723 -j ACCEPT

Significado: No hay regla que permita GRE. Si el host también está detrás de un firewall en la nube que no puede expresar GRE, estás acabado.

Decisión: Trátalo como fuerza impulsora: elige WireGuard/IKEv2/OpenVPN y sigue adelante. No construyas un laberinto de excepciones para GRE.

Tres micro-historias empresariales desde las trincheras

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana heredó una configuración PPTP tras una adquisición. “Funcionaba”, que es cómo los sistemas legados ganan permanencia. El nuevo
equipo de red migró firewalls perimetrales a un servicio de firewall gestionado. Abrieron TCP/1723, verificaron que el puerto era accesible y
siguieron adelante. Llegaron tickets a la mañana siguiente: “La VPN se conecta pero no puedo acceder a nada.”

La suposición equivocada fue simple: trataron PPTP como un servicio normal basado en puertos. El canal de control subía bien. GRE no. Algunos
clientes veían acceso parcial dependiendo de dónde estaban en Internet, porque algunos caminos pasaban GRE y otros no. El equipo perdió horas en
logs de autenticación porque “conectado” parecía “éxito”.

La solución no fue una regla de firewall ingeniosa. El producto de firewall gestionado no soportaba el protocolo IP 47 como necesitaban, y aun
donde se podía alternar, el NAT upstream rompía el seguimiento de sesión. Montaron un proof-of-concept con WireGuard en una instancia pequeña,
lo probaron con los mismos usuarios y los tickets se detuvieron.

La lección: los protocolos que requieren “manejo especial” se volverán incidentes de disponibilidad en cuanto tu red se modernice. Y se culpará
a “la nube” en lugar del verdadero culpable: un diseño de túnel que asume una Internet cooperativa.

Micro-historia 2: La optimización que salió mal

Otra organización mantuvo PPTP porque era “ligero”. Estaban ofreciendo acceso remoto para personal estacional y querían el menor overhead posible
en una VM gateway pequeña. Alguien notó que los problemas de MTU eran comunes y decidió “optimizar” reduciendo agresivamente la MTU del túnel y
clampando MSS en el tráfico saliente para evitar fragmentación de una vez por todas.

Funcionó—en su mayoría. Las quejas de conectividad bajaron y declararon victoria. Luego aumentaron las quejas de rendimiento: transferencias de
archivos lentas, escritorio remoto pegajoso y apps internas extrañamente lentas bajo carga pico. El equipo asumió que era la capa de aplicación.
No lo era. Habían creado un techo de rendimiento y amplificado la ineficiencia TCP. MTU pequeña significa más paquetes para la misma carga; más
paquetes significan más overhead; más overhead significa más CPU y más oportunidades de pérdida.

Bajo carga, la CPU de la VM subía en softirq y procesamiento de paquetes. Los usuarios lo veían como “la VPN es lenta”. SRE lo veía como “¿por qué
una VM pequeña parece estar DDoSéndose a sí misma?” Su “optimización” convirtió un túnel frágil en uno frágil que además no podía mover datos.

Finalmente reemplazaron PPTP por IKEv2/IPsec, con ajustes de MTU sensatos y NAT traversal correcto. El rendimiento se estabilizó y el helpdesk dejó
de recolectar el mismo ticket en fuentes tipográficas ligeramente distintas.

La lección: cuando compensas una debilidad estructural del protocolo, no estás optimizando—estás acumulando efectos secundarios.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una financiera operaba un pequeño servicio PPTP para algunos sistemas legados. Sabían que era malo y tenían un plan de deprecación, pero los proyectos
toman tiempo. Lo único que hicieron bien fue aburrido: trataron el concentrador PPTP como un endpoint que debe observarse, no confiarse.

Tenían logging centralizado para eventos de autenticación, sincronía horaria consistente y alertas sobre patrones de login inusuales (nuevas geografías,
fallos repetidos y aumentos súbitos de sesiones exitosas). Además, regla estricta: las cuentas PPTP eran separadas de las cuentas normales y tenían
expiración corta. Los proveedores recibían cuentas por persona, no credenciales compartidas. Era molesto. Ese era el punto.

Una noche saltaron alertas: logins exitosos repetidos en una cuenta de proveedor fuera de horas normales, seguidos por un patrón de escaneo de puertos
internos. Gracias a logs limpios y tiempo alineado, la respuesta a incidentes no empezó con “¿estamos seguros de que esto es real?” Deshabilitaron la
cuenta PPTP, bloquearon las IPs origen y rotaron credenciales. El atacante perdió el punto de apoyo rápidamente.

Más tarde migraron fuera de PPTP. Pero la práctica aburrida—cuentas segmentadas, buenos logs, alertas sensatas—convirtió una intrusión potencialmente
desordenada en un evento contenido. No porque PPTP fuera seguro. Porque los operadores actuaron como si no lo fuera.

Broma #2: Ejecutar PPTP en producción es como mantener una máquina de fax “por si acaso”. Absolutamente se usará en el peor momento posible.

Errores comunes: síntomas → causa raíz → solución

Las fallas de PPTP se repiten. No son misteriosas; tienen patrón. Aquí están las que más tiempo desperdician.

1) Síntoma: “La VPN se conecta, pero no pasa tráfico”

Causa raíz: GRE (protocolo IP 47) bloqueado por firewall, grupo de seguridad, dispositivo NAT o estado mal rastreado.

Solución: Confirma con tcpdump si hay GRE; permite GRE end-to-end si debes; de lo contrario migra a VPN basada en UDP (WireGuard/IKEv2/OpenVPN).

2) Síntoma: “Funciona en Wi‑Fi de la oficina, falla en ISP doméstico”

Causa raíz: Routers domésticos/ISP CGNAT manejan mal GRE o no soportan passthrough de PPTP con fiabilidad.

Solución: Deja de confiar en GRE. Usa WireGuard o IKEv2 con NAT traversal.

3) Síntoma: “Conectado, pero sitios internos cargan parcialmente / descargas cuelgan”

Causa raíz: PMTUD/MTU en negro; ICMP bloqueado; fragmentación descartada por middleboxes.

Solución: Prueba ping DF; permite ICMP fragmentation-needed; clamp MSS; reduce MTU del túnel con cautela. Trátalo como disparador de migración.

4) Síntoma: Avisos frecuentes de contraseña o desconexiones repetidas

Causa raíz: Desajuste en negociación de autenticación (MS-CHAPv2 vs otros), o cambios en políticas del backend de identidad.

Solución: Fija métodos de auth soportados; inspecciona logs; considera auth basada en certificados en IKEv2/IPsec o acceso moderno ligado a identidad.

5) Síntoma: “Está lento, pero la CPU es baja”

Causa raíz: Pérdida/fragmentación que lleva a backoff TCP; overhead por MTU pequeño; inestabilidad de ruta. No siempre es tema de CPU.

Solución: Mide pérdida de paquetes, retransmisiones y MTU. No “optimices” reduciendo MTU a ciegas; arregla la ruta o reemplaza el protocolo.

6) Síntoma: Los sistemas internos ven solo la IP del gateway VPN

Causa raíz: NAT (mascaradeo) usado para evitar añadir rutas para la subred de clientes.

Solución: Añade enrutamiento y rutas de retorno apropiadas, o acepta NAT como parche a corto plazo con limitaciones de auditoría explícitas. Prefiere migrar a acceso consciente de identidad.

7) Síntoma: “Usuarios aleatorios pueden conectar; otros siempre fallan”

Causa raíz: Rango IP superpuesto entre redes domésticas de clientes y subredes internas corporativas (colisión clásica 192.168.0.0/24).

Solución: Usa pools de direcciones VPN que no se superpongan, implementa split tunneling cuidadosamente o muévete a acceso por aplicación. Las superposiciones nunca mejoran con el tiempo.

8) Síntoma: El equipo de seguridad marca la VPN inmediatamente

Causa raíz: PPTP es ampliamente reconocido como obsoleto y débil, independientemente de mitigaciones locales.

Solución: No debatas. Presenta un plan de migración con cronogramas, responsables y una arquitectura de reemplazo.

Listas de verificación / plan paso a paso: desaprobar PPTP con seguridad

Paso 0: Decide el reemplazo según restricciones

• Si necesitas simplicidad y rendimiento: WireGuard.
• Si necesitas soporte nativo en OS y certificados: IKEv2/IPsec.
• Si necesitas flexibilidad y pegamento de autenticación: OpenVPN.
• Si solo necesitas unas pocas apps: no despliegues una VPN completa; usa un proxy de acceso.

Paso 1: Inventario del uso de PPTP (usuarios, dispositivos, redes, dependencias)

• Lista endpoints PPTP (servidores, routers, appliances).
• Lista quién lo usa (empleados, proveedores, cuentas de servicio).
• Lista qué acceden (subredes, apps, puertos).
• Captura cuándo lo usan (horario laboral, trabajos por lotes fuera de horario).

Paso 2: Encierra PPTP en una caja de contención (mientras exista)

• Separa cuentas PPTP de las cuentas normales.
• Exige contraseñas fuertes y aplica bloqueos/limitación de tasa.
• Restringe lo que los clientes PPTP pueden alcanzar mediante reglas de firewall (mínimo privilegio).
• Centraliza logs y alerta sobre patrones inusuales de auth y tráfico.

Paso 3: Construye la nueva VPN en paralelo

• Elige una o dos subredes internas para exponer primero.
• Diseña direccionamiento para evitar solapamientos con rangos domésticos comunes.
• Decide split tunnel vs túnel completo intencionalmente.
• Decide comportamiento DNS (DNS completo, split DNS, resolvers internos).

Paso 4: Piloto con usuarios reales y redes hostiles

• Prueba desde ISPs domésticos, hotspots móviles y Wi‑Fi de hoteles.
• Mide latencia, throughput, comportamiento de reconexión y manejo de fallos.
• Asegúrate de que el equipo de soporte pueda diagnosticarlo rápido (logs, métricas, runbooks).

Paso 5: Migra en olas, con fecha límite firme

• Comienza con TI y usuarios avanzados.
• Luego migra equipos con necesidades previsibles.
• Deja proveedores y flujos “especiales” para el final, pero no permitas que veto la fecha.

Paso 6: Desmantela PPTP como si fuera definitivo

• Deshabilita la creación de cuentas nuevas.
• Elimina perfiles de configuración PPTP de la gestión de dispositivos.
• Apaga el servicio, cierra TCP/1723 y quita permisos a GRE.
• Monitorea intentos de conexión luego—espera algunos; trátalos como rezagados de migración, no como razón para resucitarlo.

Preguntas frecuentes

¿PPTP siempre es inseguro, o solo con contraseñas débiles?

Es estructuralmente débil en despliegues reales comunes porque MS-CHAPv2 permite ataques offline prácticos. Las contraseñas fuertes ayudan, pero no
convierten a PPTP en un diseño moderno ni arreglan la fragilidad GRE/NAT.

¿Puedo hacer aceptable a PPTP forzando cifrado MPPE de 128 bits?

No. Los ajustes de cifrado no arreglan las debilidades de autenticación ni la deprecación del ecosistema. Estás puliendo un protocolo que falla
tanto en seguridad como en fiabilidad.

¿Cuál es el reemplazo más simple para un equipo pequeño?

WireGuard suele ser lo más simple operativamente: configuraciones pequeñas, buen rendimiento y menos partes móviles. Combínalo con un proceso
de gestión de claves y políticas de red estrictas.

Necesitamos “cliente integrado” en Windows e iOS. ¿Qué elegir?

IKEv2/IPsec con autenticación basada en certificados es la respuesta típica. Está ampliamente soportado sin clientes de terceros y puede montarse
de forma que los equipos de seguridad lo reconozcan como sensato.

¿OpenVPN sigue siendo una buena opción, o también es “legado”?

OpenVPN es maduro, no obsoleto. Puede configurarse de forma segura y operarse con fiabilidad, aunque es más pesado que WireGuard y tiene más
superficie de configuración. Si necesitas su flexibilidad, sigue siendo una opción válida.

¿Por qué PPTP falla específicamente en algunos hoteles o redes domésticas?

Porque GRE a menudo es manejado mal por dispositivos NAT y firewalls. TCP/1723 puede pasar, dando la ilusión de conectividad, mientras que el
payload GRE está bloqueado o mal rastreado.

¿Debemos usar VPN de túnel completo o split tunnel al migrar?

Decide según riesgo y realidades de ancho de banda. Túnel completo simplifica controles de seguridad y logging pero aumenta la carga y puede
frustrar a usuarios. Split tunnel reduce carga pero incrementa complejidad y puede filtrar tráfico si se configura mal. Ambas son viables con VPNs
modernas; PPTP es el lugar equivocado para tener este debate.

¿Y “L2TP/IPsec”? ¿Es mejor que PPTP?

En general es una mejora significativa sobre PPTP, especialmente si se configura con criptografía moderna y auth por certificados. Pero en muchos
equipos IKEv2/IPsec es una mejor opción que L2TP/IPsec porque maneja la movilidad y condiciones de red modernas con más gracia.

Tenemos un dispositivo de proveedor que solo soporta PPTP. ¿Qué hacemos?

Colócalo detrás de un gateway controlado que hable una VPN moderna externamente y solo PPTP en un segmento interno fuertemente restringido, luego
planifica reemplazar el dispositivo. Trata el soporte PPTP como un defecto del proveedor, no como un “requisito”.

¿“VPN conectada pero DNS roto” es cosa de PPTP?

Es un problema general de VPN, pero los clientes PPTP son notoriamente inconsistentes entre plataformas y clientes antiguos pueden no aceptar de forma
fiable DNS empujados. Si la corrección DNS importa (y importa), elige una pila VPN con comportamiento cliente fuerte y gestión central.

Conclusión: qué hacer el lunes por la mañana

Si todavía ejecutas PPTP, no mantienes una VPN. Mantienes una colección de filos afilados que por casualidad se autentican. El camino más rápido
a menos tickets y menos conversaciones de seguridad feas es dejar de invertir en ello.

Pasos prácticos:

• Declara PPTP deprecado internamente con una fecha de apagado real, no aspiracional.
• Elige un reemplazo (WireGuard para simplicidad/rendimiento, IKEv2/IPsec para clientes nativos, OpenVPN para flexibilidad).
• Contén el servicio PPTP existente mientras exista: reglas de mínimo privilegio, cuentas separadas, logging central y alertas.
• Ejecuta un piloto en paralelo desde redes hostiles, no solo en LAN de oficina.
• Quita permisos a GRE y cierra 1723 cuando termines. No dejes puertos embrujados atrás.