VPN: Funktionsweise, Protokolle und Einsatzszenarien

Kurzerklärung: Verschlüsselter Tunnel über ein öffentliches Netzwerk (Internet) der zwei Endpunkte sicher verbindet - schützt Remote-Mitarbeitende, verbindet Unternehmensstandorte und verbirgt Netzwerkverkehr vor Dritten.

Ein VPN (Virtual Private Network) ist eine Technologie, die zwei oder mehr Netzwerkendpunkte über ein öffentliches oder unsicheres Netz - typischerweise das Internet - so verbindet, als wären sie Teil desselben privaten Netzwerks. Der Datenverkehr wird dabei verschlüsselt und in einem sogenannten Tunnel übertragen, sodass Dritte weder Inhalt noch Metadaten einsehen können. VPNs werden im Unternehmensumfeld eingesetzt, um Außendienstmitarbeiter sicher ins Firmennetz einzubinden, Standorte miteinander zu verbinden oder sensible Kommunikation vor Abhören zu schützen.

Funktionsweise: Tunneling und Verschlüsselung

Tunneling

Das Herzstück eines VPN ist das Tunneling-Prinzip. Dabei wird ein Netzwerkpaket - das sogenannte innere Paket - vollständig in ein äußeres Paket eingebettet. Das äußere Paket enthält als Absender und Ziel die VPN-Endpunkte (Client und Server), nicht die ursprünglichen Kommunikationspartner. Für alle Beobachter im Transportnetz sieht der Datenverkehr daher aus wie eine gewöhnliche Verbindung zwischen zwei Punkten.

Ohne VPN ist das Ziel einer Verbindung für ISP, Router und Angreifer im WLAN sichtbar - bei HTTP auch der Inhalt. Mit VPN sehen Beobachter auf dem Übertragungsweg nur die Adresse des VPN-Servers und eine verschlüsselte Payload; der VPN-Server selbst sieht nach der Entschlüsselung das eigentliche Ziel und den Inhalt.

Unterschieden werden zwei Tunneling-Modi:

• Transport-Modus: Nur die Payload des IP-Pakets wird verschlüsselt, der IP-Header bleibt lesbar. Wird primär für Ende-zu-Ende-Kommunikation zwischen zwei Hosts verwendet (typisch bei IPSec im Host-to-Host-Szenario).
• Tunnel-Modus: Das gesamte ursprüngliche IP-Paket - Header und Payload - wird verschlüsselt und als Payload in ein neues Paket verpackt. Standard bei Gateway-to-Gateway-VPNs (Site-to-Site).

Verschlüsselung

Ein VPN ohne Verschlüsselung wäre lediglich eine Netzwerkkapselung ohne Vertraulichkeitsschutz. Die Verschlüsselung stellt sicher, dass abgefangene Pakete für Angreifer unlesbar sind. Typische kryptografische Verfahren im VPN-Kontext:

• AES-256 (Advanced Encryption Standard): Symmetrisches Verfahren, gilt als Standard für die Bulk-Verschlüsselung des Datenstroms. Sehr hohe Performance, auch auf Hardware mit AES-NI-Erweiterung.
• ChaCha20: Alternative zu AES, besonders leistungsstark auf Geräten ohne AES-Hardware-Beschleunigung (Mobile, IoT). Wird von WireGuard verwendet.
• RSA / ECDH: Asymmetrische Verfahren für den initialen Schlüsselaustausch. ECDH (Elliptic Curve Diffie-Hellman) bietet bei kleineren Schlüsseln vergleichbare Sicherheit wie RSA und ist performanter.
• Perfect Forward Secrecy (PFS): Jede Sitzung verwendet ephemere (kurzlebige) Schlüssel. Selbst wenn ein langfristiger privater Schlüssel kompromittiert wird, können vergangene Sitzungen nicht entschlüsselt werden.

Authentizität und Integrität werden über MACs (Message Authentication Codes) wie HMAC-SHA256 oder über AEAD-Cipher (Authenticated Encryption with Associated Data) wie AES-GCM sichergestellt.

VPN-Protokolle im Vergleich

IPSec (Internet Protocol Security)

IPSec ist ein auf IETF-Standards basierendes Protokoll-Framework, das auf Netzwerkebene (Layer 3) arbeitet. Die aktuelle Basisarchitektur ist in RFC 4301 (Kent & Seo, Dezember 2005) spezifiziert - einer Überarbeitung des ursprünglichen RFC 2401 von 1998. Es besteht aus zwei Kernprotokollen:

• AH (Authentication Header, RFC 4302): Stellt Authentizität und Integrität sicher, bietet aber keine Verschlüsselung.
• ESP (Encapsulating Security Payload, RFC 4303): Bietet Verschlüsselung, Authentizität und Integrität - in der Praxis der Standard.

Der Verbindungsaufbau läuft über IKE (Internet Key Exchange, aktuelle Version IKEv2, standardisiert in RFC 7296, Oktober 2014) in zwei Phasen. In Phase 1 wird eine IKE Security Association aufgebaut: beide Endpunkte authentifizieren sich gegenseitig (via Zertifikat oder Pre-Shared Key), handeln Verschlüsselungsparameter aus und tauschen über Diffie-Hellman Schlüssel aus. Phase 2 handelt die Parameter für den eigentlichen Datentunnel aus (je eine SA pro Richtung, mit zeitbasierter oder volumenbasierter Laufzeit).

IPSec ist in nahezu allen Betriebssystemen und Netzwerkgeräten nativ unterstützt. IKEv2/IPSec gilt als sehr stabil und wird häufig für Always-On-VPNs auf Mobilgeräten eingesetzt, da es bei Netzwechseln (WLAN zu Mobilfunk) die Verbindung aufrechterhalten kann (MOBIKE-Erweiterung).

Schwächen: Komplex zu konfigurieren, kann von restriktiven Firewalls blockiert werden (UDP 500, UDP 4500).

OpenVPN

OpenVPN ist ein Open-Source-VPN-Protokoll, das auf TLS/SSL aufbaut und auf Layer 2 oder Layer 3 operiert. Es verwendet das OpenSSL-Toolkit für Verschlüsselung und Authentifizierung.

• Läuft über TCP oder UDP (UDP bevorzugt für Performance)
• Kann über beliebige Ports betrieben werden - auch Port 443 (HTTPS), was die Erkennung erschwert
• Zertifikatsbasierte Authentifizierung via PKI (eigene CA erforderlich)
• Sehr flexibel konfigurierbar, breite Community und Drittanbieter-Unterstützung

Schwächen: Keine Implementierung im Betriebssystemkern, erfordert Drittanbieter-Client, geringere Performance als WireGuard bei hohem Durchsatz.

WireGuard

WireGuard ist das jüngste der etablierten VPN-Protokolle und seit Linux-Kernel 5.6 (2020) nativ im Kernel integriert. Jason Donenfeld stellte das Protokoll erstmals 2017 auf dem NDSS-Symposium in seiner Arbeit "WireGuard: Next Generation Kernel Network Tunnel" vor. Es setzt auf radikale Einfachheit: unter 4.000 Zeilen Code gegenüber Hunderttausenden bei OpenVPN oder IPSec - ein Faktor, der die Auditierbarkeit des Codes erheblich verbessert. NIST SP 800-77 Rev. 1 (2020) empfiehlt für IPSec-Deployments weiterhin IKEv2/ESP, während WireGuard als komplementäre Option für moderne Infrastrukturen anerkannt ist.

• Protokoll: UDP-basiert, fester Cipher-Stack (ChaCha20-Poly1305, Curve25519, BLAKE2s)
• Schlüsselpaar-Modell: Jeder Endpunkt hat ein statisches öffentliches/privates Schlüsselpaar - kein komplexes PKI-Setup erforderlich
• Performance: Deutlich höherer Durchsatz und niedrigere Latenz als OpenVPN, vergleichbar mit IPSec
• Roaming: Verbindung bleibt bei IP-Adresswechsel erhalten

# WireGuard Konfigurationsbeispiel (Peer)
[Interface]
PrivateKey = <privater-schlüssel-client>
Address = 10.0.0.2/32
DNS = 10.0.0.1

[Peer]
PublicKey = <öffentlicher-schlüssel-server>
AllowedIPs = 0.0.0.0/0   # Full Tunnel
Endpoint = vpn.beispiel.de:51820
PersistentKeepalive = 25

Schwächen: Kein dynamisches IP-Routing out-of-the-box, UDP-only (kann in restriktiven Netzen blockiert sein), standardmäßig keine Anonymität (statische IPs in der Peer-Liste).

L2TP/IPSec

L2TP (Layer 2 Tunneling Protocol) kombiniert die Tunneling-Fähigkeiten von PPTP und L2F mit der Verschlüsselung von IPSec. L2TP selbst bietet keine Verschlüsselung - es ist immer auf IPSec als Sicherheitsschicht angewiesen.

• In Windows, macOS und iOS nativ integriert
• Doppelte Kapselung (L2TP + IPSec) erhöht den Overhead
• Gilt als sicher, aber langsamer als moderne Alternativen
• Wird von WireGuard und IKEv2 zunehmend verdrängt

SSTP (Secure Socket Tunneling Protocol)

SSTP ist ein proprietäres Microsoft-Protokoll, das VPN-Traffic über HTTPS (Port 443) überträgt. Dadurch ist es in Umgebungen mit strikter Firewall gut nutzbar.

• Nahtlose Integration in Windows (kein Drittanbieter-Client nötig)
• Schwache plattformübergreifende Unterstützung (primär Windows)
• Für Microsoft-zentrierte Unternehmensumgebungen weiterhin relevant

Protokollvergleich

Protokoll	Layer	Verschlüsselung	Performance	Plattform-Support	Empfehlung
IKEv2/IPSec	3	AES-256, ChaCha20	Hoch	Sehr breit	Mobil, Enterprise
OpenVPN	2/3	AES-256, TLS	Mittel	Breit	Flexibel, Server
WireGuard	3	ChaCha20-Poly1305	Sehr hoch	Linux, Win, macOS	Modern, empfohlen
L2TP/IPSec	2	AES (via IPSec)	Mittel-Hoch	Breit (nativ)	Legacy
SSTP	2	TLS (Port 443)	Mittel	Windows-zentriert	Microsoft-Umgebungen

Site-to-Site vs. Remote-Access-VPN

Site-to-Site-VPN

Ein Site-to-Site-VPN verbindet zwei oder mehr Netzwerke dauerhaft miteinander - typischerweise Niederlassungen mit der Hauptzentrale oder Rechenzentren untereinander. Die VPN-Gateways (Firewalls, Router) bauen den Tunnel automatisch auf; Endgeräte bemerken die VPN-Verbindung nicht und benötigen keinen VPN-Client.

Einsatzszenarien: Standortvernetzung, Hybrid-Cloud-Anbindung (On-Premises zu AWS/Azure), Rechenzentrum-Replikation. Mitarbeiter am Zweigstandort greifen auf Ressourcen der Zentrale zu, ohne dass ihr Endgerät VPN-fähig sein muss - der Tunnel läuft transparent zwischen den Gateways.

Remote-Access-VPN

Beim Remote-Access-VPN (auch: Client-to-Site-VPN) baut ein einzelnes Endgerät eine verschlüsselte Verbindung zum Unternehmensnetz auf. Der Mitarbeiter benötigt einen VPN-Client und Zugangsdaten (Zertifikat, Passwort, MFA-Token). Nach Verbindungsaufbau erhält er eine IP-Adresse aus dem internen Adressbereich und kann auf interne Ressourcen zugreifen wie im Büro.

Einsatzszenarien: Homeoffice, Außendienst, Reisende.

Split Tunneling

Standardmäßig leiten viele VPNs den gesamten Datenverkehr des Clients durch den Tunnel (Full Tunnel). Split Tunneling ermöglicht es, nur bestimmten Traffic - etwa Verbindungen zu internen Ressourcen - durch den VPN zu leiten, während restlicher Internet-Traffic direkt über die lokale Verbindung läuft.

Im Full-Tunnel-Modus laufen alle Pakete durch den VPN-Gateway. Im Split-Tunnel-Modus wird interner Traffic (z. B. 10.0.0.0/8) durch den Tunnel geleitet, alles andere geht direkt über den lokalen ISP.

Vorteile von Split Tunneling:

• Geringere Bandbreitenbelastung des VPN-Gateways
• Niedrigere Latenz für nicht-unternehmensbezogene Dienste (Streaming, Cloud-Dienste)
• Geringerer Overhead auf dem Endgerät

Risiken von Split Tunneling:

• Endgerät ist gleichzeitig mit internem Netz und potenziell unsicherem Internet verbunden
• Malware auf dem Endgerät kann trotz VPN über das direkte Internet kommunizieren
• Datenverlust-Prävention (DLP) und Sicherheitskontrollen des Unternehmens greifen nur für den getunnelten Traffic

Sicherheitsempfehlung: In sicherheitskritischen Umgebungen sollte Split Tunneling deaktiviert oder auf klar definierte Ausnahmen (z. B. lokale Drucker, interne DNS-Server) beschränkt werden.

VPN im Unternehmenseinsatz

Typische Einsatzszenarien

• Homeoffice-Zugang: Mitarbeiter verbinden sich via Remote-Access-VPN ins Unternehmensnetz, um auf interne Systeme (Intranet, ERP, Dateiserver) zuzugreifen.
• Standortvernetzung: Filialen werden via Site-to-Site-VPN in das zentrale Netzwerk eingebunden.
• Drittanbieter-Zugang: Externe Dienstleister oder Lieferanten erhalten zeitlich begrenzten VPN-Zugang zu definierten Netzwerksegmenten.
• Schutz in unsicheren Netzen: Außendienst-Mitarbeiter nutzen VPN in öffentlichen WLANs (Hotels, Flughäfen), um Angriffe wie Man-in-the-Middle zu verhindern.

Always-On-VPN

Im Unternehmenskontext wird häufig Always-On-VPN eingesetzt: Das Endgerät baut automatisch eine VPN-Verbindung auf, sobald es das vertrauenswürdige Unternehmensnetz verlässt. Konfiguration erfolgt über Mobile-Device-Management (MDM) und ist für den Benutzer transparent.

Zero Trust Network Access (ZTNA) als Alternative

Traditionelle VPN-Architekturen basieren auf dem Perimeter-Modell: Wer im Tunnel ist, hat Zugang zum gesamten Netzwerksegment. Das ist in modernen, hybriden Umgebungen ein strukturelles Problem.

Zero Trust Network Access (ZTNA) verfolgt einen anderen Ansatz: Anstatt Netzwerkzugang zu gewähren, wird Zugang zu einzelnen Anwendungen gewährt - nach kontinuierlicher Prüfung von Identität, Gerätezustand und Kontext. Beim VPN-Modell führt eine erfolgreiche Authentifizierung zum Zugang auf das gesamte Netzwerksegment, was Lateral Movement ermöglicht. Im ZTNA-Modell wird nach Prüfung von Identität, Gerät und Kontext nur Zugang zur spezifischen Anwendung gewährt - Lateral Movement ist strukturell erschwert.

ZTNA-Lösungen wie Cloudflare Access, Zscaler Private Access oder Microsoft Entra Application Proxy setzen dieses Prinzip um. Sie eignen sich besonders für Cloud-native Umgebungen, Umgebungen mit vielen externen Partnern sowie Unternehmen, die das Prinzip des geringsten Privilegs auch auf Netzwerkebene durchsetzen wollen.

VPN und ZTNA schließen sich nicht aus - viele Unternehmen betreiben beide Konzepte parallel: VPN für Legacy-Systeme und Infrastrukturzugang, ZTNA für moderne Anwendungen.

Grenzen von VPN

VPN schützt nicht vor Malware

Ein VPN verschlüsselt den Datenverkehr zwischen Endpunkt und Gateway - nicht das Endgerät selbst. Ist ein Gerät mit Malware infiziert, läuft die Malware-Kommunikation über denselben Tunnel wie legitimer Traffic. VPN ersetzt keinen Endpoint-Schutz, kein EDR und kein aktuelles Patch-Management.

Der VPN-Anbieter sieht den entschlüsselten Traffic

Das ist der fundamentale Vertrauensaspekt bei VPNs: Am VPN-Gateway wird der Traffic entschlüsselt und weitergeleitet. Der Betreiber des VPN-Gateways - bei kommerziellen VPN-Diensten ein Drittanbieter - sieht theoretisch alle unverschlüsselten Verbindungen seiner Nutzer. Wer einen kommerziellen VPN-Anbieter nutzt, verschiebt das Vertrauensproblem lediglich vom Internetanbieter zum VPN-Anbieter.

Für Unternehmen ist dies kein Problem, da sie ihre eigene VPN-Infrastruktur betreiben. Für Privatanwender, die auf kommerzielle Anbieter angewiesen sind, gilt: No-Log-Versprechen sind nicht immer verifizierbar.

VPN-Zugang ist nicht gleich sicherer Zugang

Ein kompromittierter VPN-Zugang - etwa durch gestohlene Credentials oder schwache Passwörter ohne MFA - gibt dem Angreifer denselben Netzwerkzugang wie einem legitimen Mitarbeiter. VPN-Endpunkte sind deshalb ein bevorzugtes Angriffsziel und müssen zwingend mit Mehrfaktorauthentifizierung (MFA) gesichert werden.

VPN-Endpunkte als Angriffsziel

VPN-Gateways sind direkt aus dem Internet erreichbar - und damit ein attraktives Ziel für Angreifer. Bekannte Angriffsvektoren:

• Ungepatchte Schwachstellen in VPN-Software (in den letzten Jahren wiederholt kritische CVEs in Produkten von Pulse Secure, Fortinet, Citrix und anderen)
• Credential Stuffing auf Login-Seiten ohne MFA
• Schwachstellen in der IKE-Implementierung

Regelmäßige Patches, Schwachstellenscans und ein Penetrationstest der VPN-Infrastruktur sind Pflicht.

Auswahl eines VPN-Dienstes

Für Unternehmen

Unternehmen sollten VPN grundsätzlich selbst betreiben - entweder auf eigener Infrastruktur oder auf Basis einer managed Firewall/UTM. Relevante Kriterien:

• Protokoll: IKEv2/IPSec oder WireGuard für neue Deployments
• MFA-Integration: Pflicht - TOTP, FIDO2 oder Zertifikate
• Logging und Monitoring: VPN-Authentifizierungslogs ins SIEM
• Hochverfügbarkeit: Redundante Gateways, automatisches Failover
• Client-Verwaltung: MDM-Integration für Always-On-Konfiguration
• Segmentierung: VPN-Nutzer sollten nicht unrestriktiert auf alle Segmente zugreifen können - Firewall-Regeln auf dem Gateway einsetzen

Für Privatanwender

Bei kommerziellen VPN-Anbietern sollten folgende Punkte geprüft werden:

• Jurisdiction (Gerichtsbarkeit): Unterliegt der Anbieter Datenschutzgesetzen, die Logging-Pflichten vorschreiben?
• No-Log-Richtlinie: Wurde diese durch unabhängige Audits bestätigt?
• Protokoll: Anbieter mit WireGuard oder OpenVPN sind transparenter als proprietäre Protokolle
• Kill Switch: Unterbricht die Internetverbindung, wenn der VPN-Tunnel abbricht - verhindert unbeabsichtigte Datenlecks
• DNS-Leak-Schutz: DNS-Anfragen müssen ebenfalls über den Tunnel geleitet werden

Wer echte Anonymität benötigt, sollte beachten: Ein VPN allein ist kein Anonymisierungs-Tool. Korrelationsangriffe, Browser-Fingerprinting und Accountdaten ermöglichen es, VPN-Nutzer auch ohne IP-Adresse zu identifizieren.

	IPsec	TLS-VPN (SSL-VPN)	WireGuard
Layer	Layer 3 (IP)	Layer 4-7 (TLS über TCP)	Layer 3
Geschwindigkeit	Hoch	Mittel	Sehr hoch
Konfigurationsaufwand	Hoch	Mittel	Niedrig
NAT-Traversal	IKEv2: gut	Sehr gut	Gut
Audit-Komplexität	Hoch	Mittel	Niedrig (kleiner Codebase)
Verbreitung Enterprise	Sehr hoch	Hoch	Zunehmend