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.
Kort samengevat
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.
Uw openbare IP-adres en netwerklocatie, automatisch gedetecteerd.
Wordt automatisch geladen bij het openen van NetChecks — geen invoer nodig. Gebruik de knop Vernieuwen na het wisselen van netwerk of VPN.
Uw browser
Alles-in-één-scan
Voert in één keer alle relevante controles uit op één IP-adres of hostnaam: DNS, whois, ping, traceroute, een scan van bekende poorten (1-1024), HTTP-headers en het SSL-certificaat.
Voer een domein of IP-adres in en voer uit om DNS, whois, ping, traceroute, veelgebruikte poorten, HTTP-headers en het SSL-certificaat in één keer te controleren.
De meeste controles worden parallel uitgevoerd - meestal binnen ongeveer 30 seconden voltooid, langer als het doel traag of onbereikbaar is.
De poortscanstap wordt alleen uitgevoerd als het toestemmingsvakje hierboven is aangevinkt - alle andere controles worden sowieso uitgevoerd.
Ping
Verzendt ICMP-echoverzoeken naar een host om bereikbaarheid en latentie te controleren.
Voer een hostnaam of IP-adres in en klik op Ping om ICMP-echoverzoeken te sturen en de retourlatentie te meten.
Meer informatie over Ping
Wat het is
Ping stuurt ICMP Echo Request-pakketten naar een host en meet hoelang het duurt voordat de ICMP Echo Reply-pakketten terugkomen. Het is de meest basale netwerkconnectiviteitstest die er is: hij beantwoordt precies één vraag, "is deze machine bereikbaar, en hoe snel?". Het ICMP-protocol (RFC 792) werd in 1981 speciaal ontworpen om controle- en diagnoseberichten over IP-netwerken te transporteren, los van elk applicatieverkeer - Ping is de bekendste en meest universeel beschikbare implementatie ervan, praktisch aanwezig op elk besturingssysteem en netwerkapparaat sinds de vroegste versies daarvan.
Hoe het werkt
Elk ICMP-pakket bevat een TTL-veld (Time To Live) dat bij elke gepasseerde router met één wordt verlaagd; komt het op nul voordat het doel is bereikt, dan wordt het pakket verworpen en wordt er een foutmelding teruggestuurd naar de afzender. De gemeten retourtijd (RTT) in milliseconden weerspiegelt de opgetelde netwerklatentie over de volledige heen-en-terugreis, niet alleen het laatste stuk vlak bij het doel - een punt dat vaak verkeerd wordt begrepen, aangezien een traag pingresultaat zijn eigenlijke oorzaak overal langs het pad kan hebben, niet noodzakelijk bij de geteste server. Een ping stuurt doorgaans meerdere pakketten achter elkaar in plaats van slechts één, waardoor je een eenmalige latentiepiek kunt onderscheiden van een terugkerend probleem en een pakketverliespercentage over de steekproef kunt berekenen.
Resultaten interpreteren
Een stabiele, lage RTT - enkele milliseconden op een lokaal netwerk, 10 tot 50 ms voor een bestemming binnen hetzelfde land, en merkbaar meer voor een intercontinentale verbinding - duidt op een gezonde verbinding. Zelfs een klein beetje pakketverlies (boven 1-2%) is bijzonder schadelijk voor latentiegevoelige toepassingen zoals VoIP of interactieve externe sessies, waar elk verloren pakket zich manifesteert als een storing of hoorbare onderbreking. Sterk wisselende latentie van pakket tot pakket (jitter) is voor diezelfde toepassingen vaak problematischer dan een hoge maar perfect stabiele latentie. "Time-out van het verzoek" betekent dat er binnen de toegestane tijd geen antwoord is binnengekomen - de host kan werkelijk offline zijn, een firewall kan ICMP stilzwijgend blokkeren, of er kan ergens langs het pad een route verbroken zijn; "Bestemming onbereikbaar" is anders en informatiever: een tussenliggende router heeft expliciet een bericht teruggestuurd dat hij het pakket niet kon doorsturen, wat helpt om af te bakenen waar het probleem zich werkelijk bevindt.
Veelgemaakte fouten
De meest voorkomende verkeerde interpretatie is concluderen dat een host "offline" is zodra een ping mislukt, terwijl heel veel servers en apparaten - vooral achter een goed geconfigureerde firewall, of gehost bij grote cloudproviders - inkomende ICMP bewust blokkeren als beleid, terwijl ze volledig operationeel en bereikbaar zijn op hun daadwerkelijke diensten (HTTP, een database, enzovoort). Het uitblijven van een pingantwoord is dus alleen betekenisvol bewijs van uitval wanneer het gecombineerd wordt met andere signalen, zoals dat de applicatie zelf ook niet reageert. Omgekeerd garandeert een geslaagde ping geenszins dat de applicatiedienst op die machine correct functioneert - dat zijn twee volledig onafhankelijke lagen van de netwerkstack.
Wanneer te gebruiken
Het eerste dat gecontroleerd moet worden voordat een ticket wordt geëscaleerd: reageert de machine überhaupt, voordat er verder wordt gezocht? Connectiviteit bevestigen na een wijziging van een firewallregel of routeringstabel, om zeker te zijn dat de wijziging de toegang niet heeft verbroken. Een latentie-baseline vaststellen vóór een VoIP-uitrol of een failover van een operatorverbinding, zodat er een objectief vergelijkingspunt is als er later klachten binnenkomen over de gesprekskwaliteit. Een lichte, periodieke statuscontrole voor een MSP die meerdere klantlocaties parallel monitort, altijd als aanvulling op - nooit als vervanging van - diepere monitoring op applicatieniveau.
Traceroute
Traceert het netwerkpad (hop voor hop) naar een doelhost.
Voer een hostnaam of IP-adres in en voer uit om elke netwerkhop tussen deze server en de bestemming te zien, met de latentie per hop.
Voer een domein in, kies een recordtype (A, AAAA, MX, TXT, NS, CNAME, SOA, PTR, SRV of CAA) en voer de opzoeking uit.
Whois
Zoekt registratiegegevens op voor een domein of IP-adres.
Voer een domein of IP-adres in om de registratiegegevens op te zoeken: registrar, eigenaarsorganisatie en belangrijke data.
Blacklist-controle
Controleert of een IP-adres of domein voorkomt op openbare spam-/misbruik-blacklists (DNSBL).
Voer een IPv4-adres of domein in en voer uit om 7 openbare DNSBL/RBL-blacklists tegelijk te controleren - elke lijst toont vermeld, niet vermeld of controle mislukt.
TCP-poortscan
Controleert of TCP-poorten open staan op een host of IP: veelgebruikte poorten, een aangepaste lijst, of het volledige bereik 1-65535.
Voer een host of IP in, kies veelgebruikte poorten, een aangepaste lijst of het volledige bereik, en scan om te zien welke TCP-poorten reageren.
Een volledige bereikscan kan tot ~100 seconden duren. Grote scans (meer dan 100 poorten, inclusief aangepaste bereiken/lijsten) zijn beperkt tot 1 per minuut per bezoeker.
Open poorten (0)
HTTP-header-inspecteur
Haalt de HTTP-antwoordstatus en headers op voor een URL.
Voer een URL in om de HTTP-statuscode en alle antwoordheaders die de server terugstuurt op te halen.
SSL-/TLS-certificaatcontrole
Onderzoekt het TLS-certificaat van een host: uitgever, geldigheidsdata en resterende dagen.
Voer een hostnaam in om het TLS-certificaat te inspecteren: uitgever, geldigheidsdata en resterende dagen tot verloop.
Geo-IP-opzoeking
Zoekt de geografische locatie en netwerkinformatie op voor een IP-adres. Leeg laten om uw eigen openbare IP op te zoeken.
Voer een IP-adres in, of laat leeg om uw eigen adres op te zoeken, om de geschatte locatie en netwerk-/ISP-informatie te zien.
Volledig berekend in uw browser — er worden geen gegevens naar de server verzonden.
Voer een IP-adres en CIDR-prefix in (bijv. 192.168.1.0/24) om direct het netwerkbereik, broadcastadres en aantal bruikbare hosts te berekenen.
Snelheidstest
Eenvoudige download-/uploadsnelheidstest tegen deze server (nauwkeurigheid hangt af van de eigen uplink van de server).
Klik op Start om de download- en uploadsnelheid naar deze server te meten. De nauwkeurigheid hangt af van de eigen verbinding van deze server.
Landcode-woordenboek
ISO 3166-1 alpha-2-landcodes — volledig doorzocht in uw browser.
Zoek of blader door de lijst met ISO 3166-1 alpha-2-landcodes, volledig doorzocht in uw browser.
Land
ISO-code
Netnummer-woordenboek
Internationale landnummers per land — volledig doorzocht in uw browser.
Zoek of blader door internationale landcodes voor telefoonnummers, volledig doorzocht in uw browser.
Land
Netnummer
Wereldklok
Kies een tijdzone om de huidige tijd te zien - sleep de wereldbol om deze te draaien.
Kies een tijdzone uit de lijst, of sleep aan de globe, om de huidige tijd daar te zien.
Jouw tijd
--:--:--
—
—
Geselecteerde tijd
--:--:--
—
—UTC±00:00
Verschil met jou—
—
Sleep om de wereldbol te draaien.
Status van het Franse mobiele netwerk
Mobiele antennesites die uitgevallen zijn of in onderhoud zijn in Frankrijk, per operator (Orange, Free, SFR, Bouygues Telecom), op basis van openbare gegevens van ARCEP. Momentopname eenmaal per dag bijgewerkt door ARCEP - geen minuut-voor-minuut feed.
Bekijk storingsgegevens van mobiele antennes en glasvezel per Franse operator — geen invoer nodig, automatisch bijgewerkt met openbare Arcep-gegevens.
Bron: ARCEP, dataset "Sites indisponibles", gepubliceerd onder Licence Ouverte / Etalab 2.0 - commercieel hergebruik uitdrukkelijk toegestaan, in tegenstelling tot de IODA/CAIDA-gegevens die dit tabblad eerder gebruikte. Het label Normaal/Waakzaam/Alarm is een interne schatting (aantal storingen vandaag versus de mediaan van voorgaande dagen), geen officiële ARCEP-classificatie. Bronlinks hieronder.
Zwaarst getroffen departementen
Aantal sites dat momenteel is uitgevallen of in onderhoud is, per departement. Klik hierboven op een operator om te filteren.
Kwaliteit van het glasvezelnetwerk (FTTH) per operator: gemeld storingspercentage en verbindingsfoutpercentage, op basis van openbare gegevens van ARCEP. Maandelijkse indicatoren, voortschrijdend gemiddelde over 6 maanden - geen live feed zoals het mobiele gedeelte.
Bron: ARCEP, dataset "Qualité des réseaux en fibre optique", gepubliceerd onder Licence Ouverte / Etalab 2.0 - commercieel hergebruik uitdrukkelijk toegestaan. Bronlinks hieronder.
Per operator (moedergroep)
Gemiddelden over de laatste 6 beschikbare maanden, per moedergroep van de infrastructuuroperator.
NetChecks wordt uitsluitend aangeboden voor legitieme netwerkdiagnostiek en educatieve doeleinden, op systemen, domeinen en IP-adressen die u bezit of waarvoor u uitdrukkelijk bevoegd bent om te testen.
Het uitvoeren van poortscans, DNS-/whois-opzoekingen, traceroutes of andere controles op systemen van derden zonder toestemming kan wetten inzake computermisbruik in uw rechtsgebied schenden (bijvoorbeeld de Computer Fraud and Abuse Act in de VS, de "Loi Godfrain" in Frankrijk, of gelijkwaardige lokale wetgeving). U bent zelf volledig verantwoordelijk om ervoor te zorgen dat u het recht heeft om elk hier ingevoerd doel te testen.
Deze site en de resultaten ervan worden geleverd "zoals ze zijn", zonder enige garantie. De beheerder van deze site aanvaardt geen aansprakelijkheid voor directe, indirecte of gevolgschade, juridische gevolgen of misbruik die voortvloeien uit het gebruik van deze site.
Verzoeken worden qua snelheid beperkt om misbruik te voorkomen. De beheerder van deze instantie kan optioneel logging van verzoekactiviteit inschakelen - indien dat het geval is, kan elk toolverzoek (je IP-adres, tijdstempel, het gebruikte tool en het ingevoerde doel/query) worden vastgelegd in een database voor beveiliging, misbruikpreventie en gebruiksanalyse. Dit staat standaard uit. Door deze site te gebruiken, gaat u akkoord met deze voorwaarden; als u niet akkoord gaat, gebruik de site dan niet.
Programmatisch (API-)gebruik van deze site valt onder dezelfde voorwaarden, inclusief de hierboven genoemde autorisatievereiste.
Feedback versturen
Meld een probleem, laat een reactie achter of stel een nieuwe functie voor.
Deze site gebruikt advertenties en, als u accepteert, cookies van advertentiepartners om de hosting mede te financieren. U kunt weigeren en alle tools advertentievrij blijven gebruiken.