VPN remota — el teletrabajador

Un firewall, miles de clientes, mil escenarios

Una VPN de acceso remoto resuelve un problema parecido a IPSec site-to-site (cifrar capa 3 entre dos puntos), pero con una asimetría brutal: un solo concentrador VPN y miles de clientes heterogéneos — Windows, macOS, iPhones, Androids, Linux, y a veces incluso un router del IKEA en el salón.

Los actores son distintos. Cliente VPN: software o cliente nativo del SO que el usuario instala (o le instalan) en su dispositivo. Concentrador VPN / gateway: el dispositivo de borde corporativo que atiende todas las conexiones entrantes — Cisco ASA, Fortigate, Palo Alto GlobalProtect, AWS Client VPN, Tailscale relay. Identidad del usuario: aquí entra el factor que en site-to-site no existe — quién es la persona detrás de la conexión, con su MFA, su passkey o su token.

Y los protocolos del juego son distintos a IPSec puro. Hay tres familias: las VPN basadas en TLS (OpenVPN, AnyConnect-SSL, GlobalProtect-SSL) que heredan la herencia PQC de TLS 1.3; las VPN basadas en IKEv2/IPSec (AnyConnect-IPSec, GlobalProtect-IPSec, IKEv2 nativo de iOS y Windows) que heredan la migración de la estación anterior; y WireGuard, que es categoría propia y merece sección aparte.

Esta heterogeneidad introduce un factor que en IPSec site-to-site no existe: la velocidad de migración la marca el cliente más lento. Si tu Windows 10 corporativo lleva una versión del cliente de hace 3 años, ese empleado no negociará PQC aunque el concentrador lo soporte. Es el problema clásico de las flotas grandes — y por eso la migración real es un ejercicio de gestión de parque más que de criptografía.

De PPTP al teletrabajo masivo

La VPN remota es probablemente la categoría con más cadáveres criptográficos enterrados. PPTP estuvo en producción 25 años. Cisco IPSec con XAUTH también. Aquí los protocolos no se entierran cuando son inseguros, sino cuando los desinstalan los clientes.

• 1996
  PPTP · Microsoft
  El primer "VPN para todos". Roto criptográficamente desde 2012 (MS-CHAPv2 bruteforceable en ~24h). Sigue habiendo deployments.
• 2001
  OpenVPN · James Yonan
  Open-source, basado en TLS, multiplataforma. Se convierte en el estándar de facto fuera de entornos enterprise.
• 2005-2010
  Cisco AnyConnect · Pulse · GlobalProtect
  La era enterprise. SSL-VPN (TLS sobre puerto 443) gana terreno porque atraviesa firewalls hostiles. La criptografía sigue el ritmo de TLS.
• 2018
  WireGuard · Jason Donenfeld
  Reescritura desde cero. ~4000 líneas de código (vs ~600.000 de OpenVPN). Cripto fija no negociable: Curve25519 + ChaCha20-Poly1305 + BLAKE2s. Mainline en el kernel Linux desde 5.6.
• 2020-2023
  Tailscale · Cloudflare WARP
  VPNs como servicio basadas en WireGuard. Cambian la idea de "VPN corporativa" hacia mesh networking y zero-trust.
• 2023
  Rosenpass v1.0
  Daemon Rust que añade KEX post-cuántico (ML-KEM + Classic McEliece) a WireGuard usando el slot PSK. Verificado formalmente. La respuesta canónica al problema de WireGuard.
• 2025
  VPN comerciales con PQC
  ExpressVPN (enero), NordVPN (mayo) y Mullvad activan PQC en sus clientes basados en WireGuard. Generalmente vía Kyber/ML-KEM en el slot PSK.
• 2025-2026 →
  Roadmap enterprise
  Cisco anuncia "Crawl Walk Run" PQC para AnyConnect. Palo Alto y Fortinet preparan ML-KEM en GlobalProtect e SSL-VPN. Calendario realista: 2026-2028 para despliegue masivo.

Lo que hoy se considera "bien hecho"

Una VPN de acceso remoto bien configurada en 2026 combina cripto sólida con gestión de identidad fuerte. El cifrado solo no basta — la mitad del problema es quién es la persona detrás del túnel.

El gap de seguridad real en VPN remota suele estar en lo no-criptográfico: clientes desactualizados, certificados de usuario sin renovar, MFA exenciones que se quedaron permanentes, split-tunneling abierto a Internet. La cripto importa, pero hay un montón de cosas que importan igual o más.

La paradoja de WireGuard

La situación cuántica de las VPN basadas en TLS o IKEv2 es la misma que vimos en las estaciones anteriores. Pero WireGuard merece análisis aparte — y es probablemente el caso más interesante pedagógicamente de todo Cryptolab.

El detalle interesante es por qué WireGuard tiene una cripto fija. Su autor, Jason Donenfeld, lo diseñó así a propósito: la cripto negociable de IPSec y TLS es donde han aparecido históricamente la mayoría de vulnerabilidades de protocolo (downgrade attacks, misconfiguration, BEAST, POODLE, FREAK, Logjam…). Eliminando la negociación, eliminas toda esa clase de bugs. Es una decisión de diseño brillante.

WireGuard es seguro precisamente porque no se puede configurar mal. Y por la misma razón, es difícil de migrar a PQC.

En TLS, basta con que una nueva cipher suite aparezca en el registro IANA y los clientes y servidores la negocien. En IPSec, RFC 9370 permitió añadir KEMs adicionales. En WireGuard, no hay registro, no hay negociación. Cualquier cambio de criptografía implica un cambio de protocolo — un nuevo "WireGuard 2" incompatible. Y cambiar el protocolo cuando hay millones de despliegues en el mundo es dolorosísimo.

La respuesta de la comunidad ha sido creativa: usar el slot PSK (preshared key) que WireGuard ya tiene — pensado originalmente para defensa en profundidad contra fallos en Curve25519 — y meter ahí una clave derivada de un KEX post-cuántico ejecutado fuera del protocolo. Esa es la idea de Rosenpass.

Tres caminos según el protocolo

Cada familia de VPN remota está migrando por una vía distinta. Son tres soluciones diferentes a un problema común — cada una con sus tiempos.

¿Por qué Classic McEliece en Rosenpass?

Es una elección curiosa que merece explicación. Rosenpass usa dos KEMs en paralelo: ML-KEM (lattices) y Classic McEliece (códigos correctores de errores). La razón es defensa en profundidad dentro del propio PQC: si una familia matemática cae (lattices o códigos), la otra sigue protegiendo. Classic McEliece tiene claves enormes (~1 MB) pero lleva 40 años resistiendo análisis, mucho más tiempo que ML-KEM. Es la apuesta conservadora dentro de PQC.

Estado real por familia

La asimetría llamativa: el segmento consumer (las VPNs comerciales) van más rápido en PQC que el enterprise. La razón es estructural — un proveedor consumer controla cliente y servidor (su app y su backend), puede empujar updates en días. Una empresa con AnyConnect tiene que esperar a que Cisco saque versión, certifique, y luego desplegar a 50.000 endpoints. Lleva años.

Los 6 criterios de la auditoría

Como en estaciones anteriores, 6 criterios para 90 puntos máximos. La particularidad de VPN remota es que la mitad de los puntos vienen de cripto y la otra mitad de postura del dispositivo: cliente actualizado, MFA, política aplicada. La parte humana pesa.

Mapeo a badge: 0–30 Classical · 31–55 Hybrid-Ready · 56–75 Quantum-Safe · 76–90 Q-Day Proof. La paradoja de esta estación es que una empresa pequeña self-hosted con WireGuard + Rosenpass puede llegar a Q-Day Proof antes que un banco con AnyConnect en 50.000 endpoints. La complejidad operacional manda tanto como la criptografía.