The Rise of the VPN: From Dial-Up Tunnels to WireGuard and Zero Trust
2026-08-22 · 10 min
A VPN's core idea has not changed since the mid-1990s: wrap traffic in an encrypted tunnel so it can cross a network you do not trust - typically the public Internet - while behaving as if it were still on the private network at the other end. What has changed dramatically, generation after generation, is how that tunnel is built, how strong its encryption is, how fast it runs, and eventually, whether the whole concept of a single trusted 'inside' the tunnel still makes sense at all.
That evolution tracks almost exactly against the Internet's own growth from a curiosity to critical infrastructure: each new protocol generation exists because the previous one's weaknesses became too expensive, too slow, or too insecure to keep tolerating at the new scale.
1996
PPTP is developed
Microsoft and a consortium of vendors create the Point-to-Point Tunneling Protocol, the first widely deployed consumer/enterprise VPN protocol, built into Windows 95's OSR2 update.
1999
L2TP is standardized
Layer 2 Tunneling Protocol (RFC 2661) combines the best ideas of PPTP and Cisco's L2F, but has no built-in encryption of its own - it is almost always paired with IPsec.
1998-2005
IPsec matures
The IPsec suite (RFC 2401 and successors) becomes the enterprise standard for site-to-site VPNs, providing strong, standardized encryption and authentication at the network layer.
2001
OpenVPN is released
James Yonan releases OpenVPN, an open-source SSL/TLS-based VPN that runs over standard UDP or TCP - easy to firewall-traverse and free from any single vendor's control.
2002-2003
SSL VPNs go mainstream
SSL/TLS-based 'clientless' VPNs (accessible from a browser) emerge as a lighter alternative to IPsec for remote-access use cases, avoiding IPsec's notorious firewall/NAT traversal headaches.
2005
IKEv2 is published
RFC 4306 (later RFC 7296) modernizes IPsec's key exchange, adding fast reconnection after a dropped connection - the feature that made IPsec genuinely usable on mobile devices switching between WiFi and cellular.
2012
WireGuard development begins
Jason A. Donenfeld starts designing WireGuard around a radical goal: a fraction of the code size of IPsec or OpenVPN, using a small, fixed set of modern cryptographic primitives instead of dozens of negotiable, sometimes-outdated options.
2018
Linus Torvalds merges WireGuard into Linux
WireGuard enters the Linux kernel mainline, a strong technical endorsement, and rapidly becomes the reference implementation for a new generation of fast, minimal VPN protocols.
2020
Zero Trust goes mainstream
NIST publishes SP 800-207, formalizing the Zero Trust Architecture model: verify every request individually regardless of network location, rather than trusting anything already 'inside' a VPN tunnel.
2020-2024
SASE and ZTNA displace classic remote-access VPN
Secure Access Service Edge and Zero Trust Network Access platforms increasingly replace always-on, full-network VPN access with per-application, continuously verified access - the direct architectural response to VPN's long-standing 'once you're in, you're trusted everywhere' weakness.
Why VPNs exist at all
Before broadband and cloud services, reaching a corporate file server or mainframe from outside the office meant a direct dial-up modem connection into a bank of remote-access servers - reliable but expensive to scale and entirely dependent on phone infrastructure. As the public Internet became cheap and ubiquitous in the mid-1990s, the obvious next step was to reuse it as the transport, but that only works if the traffic crossing it is protected from the untrusted networks in between - which is exactly the problem PPTP was built to solve in 1996.
Every VPN protocol since has been solving some combination of the same three problems: how to build the tunnel, how to prove both ends are who they claim to be, and how to encrypt what flows through it - with each generation making different tradeoffs between security strength, connection speed, and how well it survives firewalls, NAT, and unreliable networks.
A VPN wraps a client's traffic in an encrypted tunnel across an untrusted network (typically the public Internet) to a gateway, which then forwards it onto the private network as if the client were directly attached.
The first generation: PPTP, L2TP, and IPsec
PPTP was fast and simple to set up - genuinely groundbreaking for 1996 - but its encryption (Microsoft's MS-CHAP-based scheme) was progressively broken by researchers over the following decade and is now considered insecure for anything sensitive. L2TP, standardized in 1999, fixed PPTP's tunneling design but deliberately left out encryption entirely, on the assumption it would always be paired with a separate encryption layer.
That layer was IPsec, and the combination of L2TP for tunneling plus IPsec for encryption became the de facto enterprise standard through the 2000s. IPsec's strength was operating at the network layer, meaning it could secure any IP traffic transparently without any application even being aware of it - but that same low-level design made it notoriously difficult to get through firewalls and NAT devices, a persistent operational headache for anyone deploying it at scale.
SSL VPNs and OpenVPN: solving the firewall problem
The mid-2000s answer to IPsec's traversal problems was to build VPNs on top of SSL/TLS instead - the same protocol securing HTTPS traffic, which every firewall on Earth already had to let through on port 443. 'Clientless' SSL VPNs, accessible straight from a browser, made remote access dramatically simpler to deploy for basic use cases, while OpenVPN (released in 2001, but reaching wide enterprise adoption through this period) offered the same SSL/TLS-based approach as a full, flexible, open-source tunnel that could run over either UDP or TCP.
OpenVPN's open-source nature mattered as much as its technical design: unlike IPsec's dozens of vendor implementations with inconsistent interoperability, or PPTP's Microsoft-controlled evolution, anyone could audit, extend, or embed OpenVPN, and it became the default choice for consumer VPN services and self-hosted deployments alike for the better part of two decades.
WireGuard and the move toward radical simplicity
By the 2010s, IPsec and OpenVPN both carried real technical debt: large codebases (tens of thousands of lines), dozens of negotiable cryptographic algorithms (several since deprecated as insecure), and correspondingly large attack surfaces. WireGuard's answer, starting in 2012, was almost the opposite design philosophy: roughly 4,000 lines of code, a single fixed, modern cryptographic suite with no negotiation, and a connectionless design built around the same principles as SSH's key-based authentication rather than certificate hierarchies.
The result measurably outperforms both predecessors on speed and battery life on mobile devices, while its small codebase is genuinely auditable in a way IPsec's implementations never realistically were - which is exactly why Linus Torvalds merged it directly into the Linux kernel in 2018, an endorsement almost no other VPN protocol has received.
The next shift: from VPN to Zero Trust
Every protocol generation up to this point solved how to build a better tunnel. The most recent shift questions the tunnel model itself: a classic VPN grants broad access to an entire private network once a user authenticates, which means a single compromised laptop or stolen credential can move laterally across everything that network reaches - a weakness behind a long list of major breaches.
NIST's 2020 Zero Trust Architecture framework (SP 800-207) reframes the problem: instead of one strong perimeter check followed by implicit trust, verify every single request independently, regardless of whether it originates 'inside' or 'outside' any tunnel. Zero Trust Network Access (ZTNA) and Secure Access Service Edge (SASE) platforms implement that model in practice, granting access per application rather than to the whole network - not a replacement for the encryption VPNs pioneered, but a fundamentally different answer to the access-control question a VPN alone was never actually designed to solve.
En resumen
Encryption strength was never really the bottleneck in this history - AES has been considered sound for decades. What actually changed, generation after generation, was operational reality: making tunnels traverse real-world firewalls and NAT (SSL VPN, OpenVPN), making reconnection survivable on flaky mobile networks (IKEv2), making the whole implementation small enough to actually audit (WireGuard), and finally questioning whether 'inside the tunnel' should ever again mean 'implicitly trusted' (Zero Trust). Each generation is a direct answer to the previous one's most painful real-world limitation, not a purely academic improvement.
Tu dirección IP pública y tu ubicación de red, detectadas automáticamente.
Se carga automáticamente al abrir NetChecks — no requiere ninguna entrada. Usa el botón Actualizar tras cambiar de red o reconectar tu VPN.
Tu navegador
Escaneo todo en uno
Ejecuta todas las comprobaciones relevantes sobre una IP o nombre de host en una sola pasada: DNS, whois, ping, traceroute, un escaneo de puertos conocidos (1-1024), cabeceras HTTP y el certificado SSL.
Introduce un dominio o una dirección IP y ejecútalo para comprobar DNS, whois, ping, traceroute, puertos comunes, cabeceras HTTP y el certificado SSL de una sola vez.
La mayoría de las comprobaciones se ejecutan en paralelo - normalmente termina en unos 30 segundos, más si el objetivo es lento o inalcanzable.
El paso de escaneo de puertos solo se ejecuta si la casilla de consentimiento de arriba está marcada - el resto de comprobaciones se ejecutan de todas formas.
Ping
Envía solicitudes ICMP echo a un host para comprobar su accesibilidad y latencia.
Introduce un nombre de host o una dirección IP y pulsa Ping para enviar solicitudes ICMP echo y medir la latencia de ida y vuelta.
Más información sobre Ping
Qué es
Ping envía paquetes ICMP Echo Request a un host y mide el tiempo que tardan en volver los paquetes ICMP Echo Reply. Es la prueba de conectividad de red más básica que existe: responde exactamente a una pregunta, "¿es alcanzable esta máquina, y con qué rapidez?". El protocolo ICMP (RFC 792) se diseñó en 1981 específicamente para transportar mensajes de control y diagnóstico en redes IP, al margen de cualquier tráfico de aplicación -Ping es su implementación más conocida y universalmente disponible, presente prácticamente en todos los sistemas operativos y dispositivos de red desde sus primeras versiones.
Cómo funciona
Cada paquete ICMP lleva un campo TTL (Time To Live) que se decrementa en uno en cada router que atraviesa; si llega a cero antes de alcanzar el destino, el paquete se descarta y se envía un error de vuelta al remitente. El tiempo de ida y vuelta (RTT), medido en milisegundos, refleja la latencia de red acumulada durante todo el trayecto completo, no solo el último tramo cerca del destino -un punto que suele malinterpretarse, ya que un resultado de ping lento puede tener su origen en cualquier punto del trayecto, no necesariamente cerca del servidor probado. Un ping suele enviar varios paquetes seguidos en lugar de uno solo, lo que permite distinguir un pico puntual de latencia de un problema recurrente y calcular una tasa de pérdida de paquetes sobre la muestra.
Interpretar los resultados
Un RTT bajo y estable -unos pocos milisegundos en una red local, entre 10 y 50 ms para un destino dentro del mismo país, y notablemente más para un enlace intercontinental- indica una conexión saludable. Incluso una pequeña pérdida de paquetes (por encima del 1-2%) resulta especialmente perjudicial para usos sensibles a la latencia como VoIP o sesiones remotas interactivas, donde cada paquete perdido se manifiesta como un corte o un fallo audible. Una latencia muy variable de un paquete a otro (jitter) suele ser, para estos mismos usos, un problema mayor que una latencia elevada pero perfectamente estable. "Tiempo de espera agotado" significa que no llegó ninguna respuesta en el plazo previsto -el host podría estar realmente caído, un cortafuegos podría estar bloqueando silenciosamente el ICMP, o podría haber una ruta rota en algún punto del trayecto-; "Destino inalcanzable" es distinto y más informativo: un router intermedio ha enviado explícitamente un mensaje indicando que no ha podido reenviar el paquete, lo que ayuda a acotar dónde está realmente el problema.
Errores comunes
El error de interpretación más habitual es concluir que un host está "caído" en cuanto falla un ping, cuando en realidad muchísimos servidores y dispositivos -especialmente detrás de un cortafuegos bien configurado, o alojados en grandes proveedores cloud- bloquean deliberadamente el ICMP entrante como política, estando totalmente operativos y accesibles en sus servicios reales (HTTP, una base de datos, etc.). La ausencia de respuesta a un ping solo es una evidencia significativa de caída cuando se combina con otras señales, como que la propia aplicación tampoco responda. A la inversa, un ping correcto no garantiza en absoluto que el servicio de aplicación alojado en esa máquina funcione correctamente: son dos capas de la pila de red totalmente independientes.
Cuándo usarlo
Lo primero que hay que comprobar antes de escalar un ticket: ¿responde la máquina siquiera, antes de investigar más a fondo? Confirmar la conectividad tras un cambio de regla de cortafuegos o de tabla de rutas, para asegurarse de que el cambio no ha roto el acceso. Establecer una medición de latencia de referencia antes de un despliegue de VoIP o de un failover de enlace de operador, para tener un punto de comparación objetivo si más adelante llegan quejas sobre la calidad de las llamadas. Una comprobación de estado periódica y ligera para un MSP que supervisa varios sitios de clientes en paralelo, siempre como complemento -nunca como sustituto- de una monitorización más profunda a nivel de aplicación.
Traceroute
Traza la ruta de red (salto a salto) hasta un host de destino.
Introduce un nombre de host o una dirección IP y ejecútalo para ver cada salto de red entre este servidor y el destino, con la latencia de cada salto.
Introduce un dominio, elige un tipo de registro (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV o CAA) y realiza la consulta.
Whois
Consulta la información de registro de un dominio o dirección IP.
Introduce un dominio o una dirección IP para consultar sus datos de registro: registrador, organización propietaria y fechas importantes.
Comprobación de lista negra
Comprueba si una dirección IP o un dominio figura en listas negras públicas de spam/abuso (DNSBL).
Introduce una dirección IPv4 o un dominio y ejecútalo para consultar 7 listas negras (DNSBL/RBL) públicas a la vez - cada una se muestra como listada, no listada o comprobación fallida.
Escaneo de puertos TCP
Comprueba si los puertos TCP están abiertos en un host o IP: puertos comunes, una lista personalizada, o el rango completo 1-65535.
Introduce un host o una IP, elige puertos comunes, una lista personalizada o el rango completo, y escanea para ver qué puertos TCP responden.
Un escaneo completo puede tardar hasta ~100 segundos. Los escaneos grandes (más de 100 puertos, incluidos rangos/listas personalizados) están limitados a 1 por minuto por visitante.
Puertos abiertos (0)
Inspector de cabeceras HTTP
Obtiene el estado de la respuesta HTTP y las cabeceras de una URL.
Introduce una URL para obtener su código de estado HTTP y todas las cabeceras de respuesta que envía el servidor.
Verificador de certificado SSL / TLS
Inspecciona el certificado TLS de un host: emisor, fechas de validez y días restantes.
Introduce un nombre de host para inspeccionar su certificado TLS: emisor, fechas de validez y días restantes antes de que expire.
Geolocalización IP
Consulta la ubicación geográfica y la información de red de una dirección IP. Déjalo vacío para consultar tu propia IP pública.
Introduce cualquier dirección IP, o déjalo vacío para consultar la tuya, y verás su ubicación aproximada e información de red/ISP.
Calculado enteramente en tu navegador — no se envía ningún dato al servidor.
Introduce una dirección IP y un prefijo CIDR (p. ej. 192.168.1.0/24) para calcular al instante el rango de red, la dirección de difusión y el número de hosts utilizables.
Test de velocidad
Prueba básica de velocidad de descarga/subida contra este servidor (la precisión depende de la propia conexión del servidor).
Pulsa Iniciar para medir la velocidad de descarga y subida contra este servidor. La precisión depende de la propia conexión de este servidor.
Diccionario de códigos de país
Códigos de país ISO 3166-1 alfa-2 — búsqueda realizada enteramente en su navegador.
Busca o explora la lista de códigos de país ISO 3166-1 alfa-2, consultada enteramente en tu navegador.
País
Código ISO
Diccionario de prefijos telefónicos
Prefijos telefónicos internacionales por país — búsqueda realizada enteramente en su navegador.
Busca o explora los prefijos telefónicos internacionales por país, consultados enteramente en tu navegador.
País
Prefijo
Reloj mundial
Elige una zona horaria para ver la hora actual — arrastra el globo para girarlo.
Elige una zona horaria de la lista, o arrastra el globo, para ver la hora actual allí.
Tu hora
--:--:--
—
—
Hora seleccionada
--:--:--
—
—UTC±00:00
Diferencia contigo—
—
Arrastra para girar el globo.
Estado de la red móvil en Francia
Antenas móviles caídas o en mantenimiento en Francia, por operador (Orange, Free, SFR, Bouygues Telecom), según datos públicos de la Arcep. Instantánea actualizada una vez al día - no es un flujo en tiempo real.
Consulta los datos de averías de antenas móviles y fibra por operador francés — sin necesidad de introducir nada, actualizado automáticamente con los datos públicos de Arcep.
Fuente: Arcep, conjunto de datos «Sites indisponibles», publicado bajo Licencia Abierta / Etalab 2.0 - reutilización comercial explícitamente permitida, a diferencia de los datos IODA/CAIDA usados antes. La insignia Normal/Vigilancia/Alerta es una estimación propia (incidencias de hoy frente a la mediana de días anteriores), no una clasificación oficial de la Arcep. Enlaces de origen abajo.
Departamentos más afectados
Número de sitios actualmente caídos o en mantenimiento, por departamento. Haga clic en un operador arriba para filtrar.
Calidad de la red de fibra (FTTH) por operador: tasa de averías notificadas y tasa de fallos de conexión, según datos públicos de la Arcep. Indicadores mensuales, media móvil de 6 meses - no es un flujo en vivo como la sección móvil.
Fuente: Arcep, conjunto de datos «Qualité des réseaux en fibre optique», publicado bajo Licencia Abierta / Etalab 2.0 - reutilización comercial explícitamente permitida. Enlaces de origen abajo.
Por operador (grupo matriz)
Promedios de los últimos 6 meses disponibles, por grupo matriz del operador de infraestructura.
NetChecks se proporciona únicamente con fines de diagnóstico de red legítimo y educativos, sobre sistemas, dominios y direcciones IP que poseas o para los que tengas autorización explícita para realizar pruebas.
Ejecutar escaneos de puertos, búsquedas DNS/whois, traceroutes u otras comprobaciones contra sistemas de terceros sin autorización puede infringir las leyes sobre uso indebido de sistemas informáticos de tu jurisdicción (por ejemplo, la Computer Fraud and Abuse Act en EE. UU., la "Loi Godfrain" en Francia, o legislación local equivalente). Eres el único responsable de asegurarte de tener derecho a probar cualquier objetivo que introduzcas aquí.
Este sitio y sus resultados se proporcionan "tal cual", sin garantía de ningún tipo. El operador de este sitio no acepta ninguna responsabilidad por daños directos, indirectos o consecuentes, consecuencias legales o uso indebido derivados del uso de este sitio.
Las solicitudes tienen un límite de frecuencia para evitar abusos. El operador de esta instancia puede habilitar opcionalmente el registro de actividad de solicitudes - de ser así, cada solicitud a una herramienta (tu dirección IP, la marca de tiempo, la herramienta utilizada y el objetivo/consulta introducidos) puede registrarse en una base de datos con fines de seguridad, prevención de abusos y análisis de uso; esto está desactivado de forma predeterminada. Al usar este sitio aceptas estas condiciones; si no estás de acuerdo, no lo utilices.
El uso programático (API) de este sitio está sujeto a estos mismos términos, incluido el requisito de autorización anterior.
Enviar comentarios
Informa un problema, deja un comentario o sugiere una nueva función.
Este sitio muestra anuncios y, si aceptas, cookies de socios publicitarios para ayudar a financiar el alojamiento. Puedes rechazarlo y seguir usando todas las herramientas sin publicidad.