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.
In sintesi
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.
Il tuo indirizzo IP pubblico e la posizione di rete, rilevati automaticamente.
Si carica automaticamente all'apertura di NetChecks — nessun dato da inserire. Usa il pulsante Aggiorna dopo aver cambiato rete o riconnesso la VPN.
Il tuo browser
Scansione All-in-One
Esegue in un'unica passata tutti i controlli rilevanti su un IP o hostname: DNS, whois, ping, traceroute, una scansione delle porte note (1-1024), header HTTP e certificato SSL.
Inserisci un dominio o un indirizzo IP ed esegui la scansione per controllare DNS, whois, ping, traceroute, porte comuni, intestazioni HTTP e certificato SSL in un solo passaggio.
La maggior parte dei controlli viene eseguita in parallelo - di solito termina in circa 30 secondi, di più se il target è lento o irraggiungibile.
Il passaggio di scansione delle porte viene eseguito solo se la casella di consenso sopra è selezionata - tutti gli altri controlli vengono eseguiti comunque.
Ping
Invia richieste echo ICMP a un host per verificare raggiungibilità e latenza.
Inserisci un nome host o un indirizzo IP e premi Ping per inviare richieste ICMP echo e misurare la latenza di andata e ritorno.
Scopri di più su Ping
Cos'è
Ping invia pacchetti ICMP Echo Request a un host e misura il tempo impiegato dai pacchetti ICMP Echo Reply per tornare indietro. È il test di connettività di rete più elementare che esista: risponde esattamente a una domanda, "questa macchina è raggiungibile, e con quale rapidità?". Il protocollo ICMP (RFC 792) è stato progettato nel 1981 specificamente per trasportare messaggi di controllo e diagnostica sulle reti IP, al di fuori di qualsiasi traffico applicativo - Ping ne è l'implementazione più nota e universalmente disponibile, presente praticamente su ogni sistema operativo e dispositivo di rete fin dalle prime versioni.
Come funziona
Ogni pacchetto ICMP trasporta un campo TTL (Time To Live) decrementato di uno a ogni router attraversato; se raggiunge zero prima di arrivare al target, il pacchetto viene scartato e un errore viene rimandato al mittente. Il tempo di andata e ritorno (RTT), misurato in millisecondi, riflette la latenza di rete cumulativa sull'intero percorso, non solo l'ultimo tratto vicino al target - un punto spesso frainteso, poiché un risultato di ping lento può avere la sua causa in qualsiasi punto del percorso, non necessariamente vicino al server testato. Un ping in genere invia più pacchetti di seguito anziché uno solo, il che permette di distinguere un picco di latenza occasionale da un problema ricorrente e di calcolare un tasso di perdita di pacchetti sul campione.
Interpretare i risultati
Un RTT basso e stabile - pochi millisecondi su una rete locale, tra 10 e 50 ms per una destinazione nello stesso paese, e notevolmente di più per un collegamento intercontinentale - indica una connessione sana. Anche una piccola perdita di pacchetti (oltre l'1-2%) è particolarmente dannosa per usi sensibili alla latenza come VoIP o sessioni remote interattive, dove ogni pacchetto perso si manifesta come un'interruzione o un'interferenza udibile. Una latenza molto variabile da un pacchetto all'altro (jitter) è spesso, per questi stessi usi, un problema maggiore di una latenza elevata ma perfettamente stabile. "Richiesta scaduta" significa che non è arrivata alcuna risposta entro il tempo previsto - l'host potrebbe essere effettivamente offline, un firewall potrebbe bloccare silenziosamente l'ICMP, oppure un percorso potrebbe essere interrotto in qualche punto del tragitto; "Destinazione irraggiungibile" è diverso e più informativo: un router intermedio ha esplicitamente rimandato indietro un messaggio dicendo di non essere riuscito a inoltrare il pacchetto, il che aiuta a circoscrivere dove si trovi realmente il problema.
Errori comuni
L'errore di interpretazione più comune è concludere che un host sia "offline" nel momento in cui un ping fallisce, quando in realtà moltissimi server e dispositivi - specialmente dietro un firewall ben configurato, o ospitati presso i grandi provider cloud - bloccano deliberatamente l'ICMP in ingresso per policy, pur essendo pienamente operativi e raggiungibili sui loro servizi reali (HTTP, un database, ecc.). L'assenza di risposta a un ping è quindi una prova significativa di inattività solo se combinata con altri segnali, come il fatto che anche l'applicazione stessa non risponda. Al contrario, un ping riuscito non garantisce affatto che il servizio applicativo ospitato su quella macchina funzioni correttamente - sono due livelli dello stack di rete del tutto indipendenti.
Quando usarlo
La prima cosa da verificare prima di escalare un ticket: la macchina risponde almeno, prima di indagare oltre? Confermare la connettività dopo una modifica a una regola firewall o a una tabella di routing, per assicurarsi che la modifica non abbia interrotto l'accesso. Stabilire una misurazione di latenza di riferimento prima di un rollout VoIP o di un failover di un collegamento operatore, in modo da avere un punto di confronto oggettivo se in seguito arrivano lamentele sulla qualità delle chiamate. Un controllo di stato periodico e leggero per un MSP che monitora più sedi cliente in parallelo, sempre come complemento - mai come sostituto - di un monitoraggio più approfondito a livello applicativo.
Traceroute
Traccia il percorso di rete (hop per hop) verso un host di destinazione.
Inserisci un nome host o un indirizzo IP ed esegui la scansione per vedere ogni salto di rete tra questo server e la destinazione, con la latenza di ciascun salto.
Ricerca DNS (Nslookup)
Interroga i record DNS: A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV, CAA.
Inserisci un dominio, scegli un tipo di record (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV o CAA) ed esegui la ricerca.
Whois
Cerca le informazioni di registrazione per un dominio o un indirizzo IP.
Inserisci un dominio o un indirizzo IP per consultarne i dati di registrazione: registrar, organizzazione proprietaria e date importanti.
Controllo blacklist
Verifica se un indirizzo IP o un dominio è presente in blacklist pubbliche anti-spam/abuso (DNSBL).
Inserisci un indirizzo IPv4 o un dominio ed esegui per controllare contemporaneamente 7 blacklist pubbliche (DNSBL/RBL) - ciascuna viene mostrata come elencata, non elencata o controllo non riuscito.
Scansione porte TCP
Verifica se le porte TCP sono aperte su un host o IP: porte comuni, un elenco personalizzato o l'intero intervallo 1-65535.
Inserisci un host o un IP, scegli porte comuni, un elenco personalizzato o l'intervallo completo, quindi esegui la scansione per vedere quali porte TCP rispondono.
Una scansione dell'intero intervallo può richiedere fino a ~100 secondi. Le scansioni grandi (più di 100 porte, inclusi intervalli/elenchi personalizzati) sono limitate a 1 al minuto per visitatore.
Porte aperte (0)
Analizzatore di header HTTP
Recupera lo stato della risposta HTTP e gli header per un URL.
Inserisci un URL per ottenere il suo codice di stato HTTP e tutte le intestazioni di risposta inviate dal server.
Verifica certificato SSL/TLS
Esamina il certificato TLS di un host: emittente, date di validità e giorni rimanenti.
Inserisci un nome host per ispezionare il suo certificato TLS: emittente, date di validità e giorni rimanenti prima della scadenza.
Ricerca Geo-IP
Cerca la posizione geografica e le informazioni di rete per un indirizzo IP. Lascia vuoto per cercare il tuo indirizzo IP pubblico.
Inserisci un indirizzo IP qualsiasi, oppure lascia vuoto per cercare il tuo, per vedere la posizione approssimativa e le informazioni di rete/ISP.
Calcolato interamente nel tuo browser — nessun dato inviato al server.
Inserisci un indirizzo IP e un prefisso CIDR (es. 192.168.1.0/24) per calcolare all'istante l'intervallo di rete, l'indirizzo di broadcast e il numero di host utilizzabili.
Test di velocità
Test di base della velocità di download/upload rispetto a questo server (la precisione dipende dalla connessione in uplink del server stesso).
Premi Avvia per misurare la velocità di download e upload verso questo server. La precisione dipende dalla connessione di questo server.
Dizionario dei codici paese
Codici paese ISO 3166-1 alpha-2 — ricerca eseguita interamente nel tuo browser.
Cerca o sfoglia l'elenco dei codici paese ISO 3166-1 alpha-2, ricercato interamente nel tuo browser.
Paese
Codice ISO
Dizionario dei prefissi telefonici
Prefissi internazionali per paese — ricerca eseguita interamente nel tuo browser.
Cerca o sfoglia i prefissi telefonici internazionali per paese, ricercati interamente nel tuo browser.
Paese
Prefisso
Orologio mondiale
Scegli un fuso orario per vedere l'ora attuale — trascina il globo per farlo girare.
Scegli un fuso orario dall'elenco, oppure trascina il globo, per vedere l'ora attuale in quel luogo.
Il tuo orario
--:--:--
—
—
Orario selezionato
--:--:--
—
—UTC±00:00
Differenza rispetto a te—
—
Trascina per ruotare il globo.
Stato della rete mobile francese
Siti di antenne mobili guasti o in manutenzione in Francia, per operatore (Orange, Free, SFR, Bouygues Telecom), dai dati pubblici dell'ARCEP. Istantanea aggiornata una volta al giorno dall'ARCEP - non un flusso minuto per minuto.
Sfoglia i dati sui guasti delle antenne mobili e della fibra per operatore francese — nessun dato da inserire, aggiornato automaticamente dai dati pubblici di Arcep.
Fonte: ARCEP, dataset "Sites indisponibles", pubblicato con Licence Ouverte / Etalab 2.0 - riuso commerciale esplicitamente consentito, a differenza dei dati IODA/CAIDA usati in precedenza in questa scheda. Il badge Normale/Attenzione/Allerta è una stima interna (numero di guasti odierno rispetto alla mediana dei giorni precedenti), non una classificazione ufficiale dell'ARCEP. Link alle fonti qui sotto.
Dipartimenti più colpiti
Numero di siti attualmente guasti o in manutenzione, per dipartimento. Fai clic su un operatore sopra per filtrare.
Qualità della rete in fibra (FTTH) per operatore: tasso di guasti segnalati e tasso di errore di connessione, dai dati pubblici dell'ARCEP. Indicatori mensili, media mobile su 6 mesi - non un flusso in tempo reale come la sezione mobile.
Fonte: ARCEP, dataset "Qualité des réseaux en fibre optique", pubblicato con Licence Ouverte / Etalab 2.0 - riuso commerciale esplicitamente consentito. Link alle fonti qui sotto.
Per operatore (gruppo madre)
Medie sugli ultimi 6 mesi disponibili, per gruppo madre dell'operatore infrastrutturale.
NetChecks è fornito esclusivamente per scopi legittimi di diagnostica di rete ed educativi, su sistemi, domini e indirizzi IP di tua proprietà o per i quali sei esplicitamente autorizzato a effettuare test.
L'esecuzione di scansioni delle porte, ricerche DNS/whois, traceroute o altri controlli su sistemi di terze parti senza autorizzazione potrebbe violare le leggi sull'uso improprio dei computer nella tua giurisdizione (ad esempio il Computer Fraud and Abuse Act negli USA, la "Loi Godfrain" in Francia, o normative locali equivalenti). Sei l'unico responsabile di assicurarti di avere il diritto di testare qualsiasi target inserito qui.
Questo sito e i suoi risultati sono forniti "così come sono", senza garanzia di alcun tipo. Il gestore di questo sito non si assume alcuna responsabilità per eventuali danni diretti, indiretti o consequenziali, conseguenze legali o usi impropri derivanti dall'uso di questo sito.
Le richieste sono limitate in frequenza per prevenire abusi. L'operatore di questa istanza può abilitare facoltativamente la registrazione dell'attività delle richieste - in tal caso, ogni richiesta a uno strumento (il tuo indirizzo IP, la data/ora, lo strumento utilizzato e l'obiettivo/query inserito) potrebbe essere registrata in un database per finalità di sicurezza, prevenzione degli abusi e analisi dell'utilizzo. Questa funzione è disattivata per impostazione predefinita. Utilizzando questo sito accetti questi termini; se non sei d'accordo, non utilizzarlo.
L'uso programmatico (API) di questo sito è soggetto agli stessi termini, incluso il requisito di autorizzazione sopra indicato.
Invia feedback
Segnala un problema, lascia un commento o suggerisci una nuova funzionalità.
Questo sito utilizza annunci pubblicitari e, se accetti, cookie dei partner pubblicitari per contribuire a finanziare l'hosting. Puoi rifiutare e continuare a usare tutti gli strumenti senza pubblicità.