VPN: Arten, IPsec, Auswahl und Fehlersuche

VPN: Arten, IPsec, Auswahl und Fehlersuche

https://bildung.social/@oerinformatik/

https://oer-informatik.de/vpn

VPN, Virtual Private Network, Site-to-Site, End-to-Site, Remote Access, IPsec, OpenVPN, WireGuard, Tunnelmodus, MTU, Split-Tunneling, Fehlersuche

tl/dr; (ca. 22 min Lesezeit): Ein VPN verbindet Geräte oder Netze über das Internet so, als lägen sie in einem gemeinsamen privaten Netz: Die Daten laufen verschlüsselt und authentifiziert durch einen Tunnel. Du lernst die VPN-Arten Site-to-Site, End-to-Site und End-to-End mit den beteiligten Geräten kennen und erfährst, wie ein VPN Vertraulichkeit, Integrität und Authentizität sicherstellt. Danach geht es um IPsec mit AH, ESP und Tunnelmodus, um OpenVPN und WireGuard, um die Wahl von TCP oder UDP, Routing oder Bridging und Split- oder Full-Tunnel sowie um Kriterien für Software und Hardware. Zum Schluss findest Du eine Checkliste für die Fehlersuche, wenn der Tunnel nicht aufgebaut wird, keine Ziele erreicht oder große Pakete verliert [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Dieser Artikel ist Teil einer Artikelreihe zu Netzwerken: IPv4-Adressierung und Subnetting / Routing / Firewall und DMZ / VPN / Übungsaufgaben zu VPN

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Dieser Artikel baut auf der Kann-Liste der Artikel Kryptografie und Routing auf.

Als Grundlagen zu VPN kann ich nach Durchlesen des Artikels…

• … den Begriff Virtual Private Network erklären und beschreiben, welchen sicherheitstechnischen Vorteil ein VPN bei der Nutzung öffentlicher Netze bietet.

• … die Schutzziele Vertraulichkeit, Integrität und Authentizität auf ein VPN beziehen und erläutern, mit welchen Mechanismen sie erreicht werden.

• … die VPN-Arten Site-to-Site, End-to-Site und End-to-End unterscheiden, Beispielen zuordnen und die Geräte nennen, auf denen das VPN eingerichtet wird.

• … eine VPN-Verbindung skizzieren bzw. ein Schaubild um VPN-Client, VPN-Gateway und Tunnel ergänzen.

• … Nachteile eines VPN gegenüber einer unverschlüsselten Verbindung nennen.

Darüber hinaus kann ich als Kernwissen für alle Fachrichtungen…

• … den Aufbau von IPsec (AH, ESP, IKE, Tunnel- und Transportmodus) erläutern und begründen, warum AH mit NAT nicht funktioniert und warum ein Paket im Tunnelmodus zwei IP-Header hat.

• … die Authentifizierung mit Pre-Shared Key und mit X.509-Zertifikaten vergleichen und eine VPN-Software oder -Hardware nach begründeten Kriterien auswählen.

• … TCP oder UDP als Transportprotokoll, Routing oder Bridging als Betriebsart und Split- oder Full-Tunnel begründet wählen.

• … Konfigurationszeilen eines VPN-Clients erläutern und den Einfluss des VPN-Overheads auf MTU, Nutzdaten und Übertragungsdauer berechnen.

• … Fehlerursachen beim Aufbau und Betrieb eines VPN (Zugangsdaten, blockierte Ports am Hotspot, fehlende Routen, zu große MTU, Umgehung über IPv6) systematisch eingrenzen und beheben.

Jemand aus dem Vertrieb sitzt im Hotel und möchte auf den Dateiserver der Firma zugreifen. Eine Filiale soll die Warenwirtschaft der Zentrale nutzen. Ein Dienstleister wartet einen Server aus der Ferne. In allen drei Fällen liegen zwischen den Beteiligten fremde Netze, über deren Sicherheit niemand bestimmen kann – meist das Internet oder ein offenes WLAN. Ein eigenes Kabel zu jedem Standort wäre viel zu teuer. Die Lösung ist ein Virtual Private Network (VPN).

Die Mindmap zeigt die Themen dieses Artikels im Überblick:

Was ist ein VPN?

Ein Virtual Private Network (virtuelles privates Netz) ist eine logische Netzwerkverbindung über ein öffentliches Netz, die sich für die Beteiligten so verhält, als wären sie direkt an ein gemeinsames privates Netz angeschlossen:

• virtuell, weil keine eigene physische Leitung existiert; die Daten laufen über die vorhandene Internetverbindung,

• privat, weil Unbeteiligte die Daten weder lesen noch unbemerkt verändern können und nur berechtigte Teilnehmende Zugang erhalten,

• Netzwerk, weil die Endpunkte Adressen aus dem internen Netz erhalten bzw. erreichen und interne Dienste nutzen können.

Technisch beruht ein VPN auf Tunneling: Ein VPN-Endpunkt verpackt (kapselt) die Pakete des internen Netzes verschlüsselt in neue Pakete, die über das Internet zum anderen Endpunkt geschickt und dort wieder ausgepackt (entkapselt) werden. Für Router im Internet ist nur die äußere Hülle sichtbar: Absender und Empfänger sind die beiden Tunnelendpunkte.

Welche Schutzziele erfüllt ein VPN?

Schutzziele und ihre Umsetzung im VPN

Schutzziel	Bedeutung im VPN	erreicht durch
Vertraulichkeit	Nur die Tunnelendpunkte können die Daten lesen.	symmetrische Verschlüsselung der Nutzdaten (z. B. AES, ChaCha20)
Integrität	Veränderungen unterwegs werden bemerkt, veränderte Pakete verworfen.	Prüfwert je Paket (HMAC mit SHA-2 oder authentifizierte Verschlüsselung wie AES-GCM)
Authentizität	Beide Seiten können sicher sein, mit wem sie verbunden sind.	Pre-Shared Key, Zertifikate, Benutzername und Passwort mit zweitem Faktor

Die Schlüssel für die Verschlüsselung werden beim Verbindungsaufbau ausgehandelt (z. B. mit einem Diffie-Hellman-Verfahren) und regelmäßig erneuert. Wie symmetrische und asymmetrische Verfahren, Hashfunktionen und Zertifikate funktionieren, beschreibt der Artikel Kryptografie. Weil sich beide Seiten gegenseitig authentifizieren, schützt ein richtig konfiguriertes VPN auch vor Man-in-the-Middle-Angriffen: Ein Angreifer, der sich zwischen die Partner schaltet und sich als Gegenstelle ausgibt, kann den Schlüssel bzw. das Zertifikat der echten Gegenstelle nicht vorweisen und wird abgewiesen.

Das wichtigste Argument für ein VPN lässt sich in einem Satz sagen: Daten, die über ein fremdes oder öffentliches Netz laufen, können ohne VPN mitgelesen und verändert werden – mit VPN nicht. Typische Merkmale einer VPN-Verbindung sind deshalb: Tunnel, Verschlüsselung, Authentifizierung der Teilnehmenden, Integritätsschutz und Zugriff auf interne Adressen und Dienste.

VPN-Arten: Wer wird mit wem verbunden?

Bei Site-to-Site baut das VPN-Gateway den Tunnel dauerhaft auf; alle Geräte eines Standorts nutzen ihn, ohne selbst etwas konfigurieren zu müssen. Bei End-to-Site braucht jedes Endgerät eine VPN-Client-Software und eigene Zugangsdaten; im Firmennetz wartet ein VPN-Gateway (Router, Firewall oder VPN-Server), das den Tunnel annimmt. Bei End-to-End reicht der Schutz bis in die beiden Endgeräte – auch innerhalb eines Netzes.

Wie ein VPN in einer Skizze aussieht, folgt immer demselben Muster: Endgerät mit VPN-Client oder Netz mit VPN-Gateway – Internet als Wolke – VPN-Gateway – internes Netz mit Switch und Servern. Den Tunnel zeichnest Du als beschriftete Verbindung durch das Internet, deren Enden genau an den Geräten liegen, auf denen das VPN eingerichtet ist.

VPN-Protokolle: IPsec, OpenVPN und WireGuard

IPsec

IPsec (Internet Protocol Security) arbeitet auf der Vermittlungsschicht (Schicht 3) und sichert IP-Pakete direkt ab. Es besteht aus mehreren Teilen:

• IKE (Internet Key Exchange, heute IKEv2): handelt Verfahren und Schlüssel aus und authentifiziert die Partner; läuft über UDP-Port 500.

• AH (Authentication Header, IP-Protokoll 51): sichert Integrität und Authentizität des gesamten Pakets einschließlich des äußeren IP-Headers, verschlüsselt aber nicht.

• ESP (Encapsulating Security Payload, IP-Protokoll 50): verschlüsselt die Nutzdaten und sichert ihre Integrität. In der Praxis wird fast nur ESP verwendet.

IPsec kennt zwei Modi:

• Transportmodus: Nur die Nutzdaten des Pakets werden geschützt, der ursprüngliche IP-Header bleibt. Geeignet für End-to-End-Verbindungen zwischen zwei Geräten.

• Tunnelmodus: Das komplette ursprüngliche Paket wird verschlüsselt und in ein neues Paket gesteckt. Jedes Paket hat dann zwei IP-Header: außen die öffentlichen Adressen der Tunnelendpunkte (damit das Paket im Internet geroutet werden kann), innen die privaten Adressen von Absender und Empfänger im internen Netz. Standard für Site-to-Site und End-to-Site.

Original:      | IP-Header (intern) | TCP | Daten |
Tunnelmodus:   | IP-Header (außen) | ESP-Header | IP-Header (intern) | TCP | Daten | ESP-Trailer + Prüfwert |
                                                 \________________ verschlüsselt __________________/

AH und NAT vertragen sich nicht: Steht zwischen den Endpunkten ein Router mit NAT (z. B. der DSL-Router im Homeoffice oder am Hotspot), ändert er die Absenderadresse im äußeren IP-Header. Weil AH genau diesen Header in seinen Prüfwert einbezieht, stimmt der Prüfwert beim Empfänger nicht mehr – das Paket wird als manipuliert verworfen. ESP schützt den äußeren Header nicht; mit NAT-Traversal (NAT-T) werden die ESP-Pakete zusätzlich in UDP (Port 4500) verpackt, damit NAT-Router sie wie normale UDP-Pakete umsetzen können.

OpenVPN und WireGuard

• OpenVPN baut den Tunnel mit TLS auf (deshalb oft „SSL-VPN“ genannt), authentifiziert meist mit Zertifikaten und läuft über UDP oder TCP (Standardport 1194). Es ist sehr flexibel und funktioniert auch hinter restriktiven Firewalls, weil es notfalls über TCP 443 laufen kann.

• WireGuard ist ein schlankes, modernes Protokoll mit fest gewählten Verfahren (u. a. ChaCha20, Poly1305, Curve25519). Jede Seite hat ein Schlüsselpaar; die öffentlichen Schlüssel werden auf der Gegenstelle hinterlegt. WireGuard läuft nur über UDP und ist seit 2020 im Linux-Kernel enthalten.

• PPTP ist veraltet und gilt als unsicher; es sollte nicht mehr eingesetzt werden.

Eine OpenVPN-Client-Konfiguration enthält typische Zeilen wie diese:

client
dev tun
proto udp
remote vpn.example.org 1194
cipher AES-256-GCM
auth SHA256
remote-cert-tls server

Bedeutung von Zeilen einer OpenVPN-Konfiguration

Zeile	Bedeutung
dev tun	Tunnel-Schnittstelle auf Schicht 3 (Routing); dev tap wäre eine Schicht-2-Schnittstelle (Bridging)
proto udp	Transportprotokoll UDP
remote vpn.example.org 1194	Adresse bzw. Name und Port des VPN-Servers (Gegenstelle)
cipher AES-256-GCM	symmetrische Verschlüsselung der Nutzdaten mit AES und 256-Bit-Schlüssel
auth SHA256	Hashfunktion SHA-256 für den Integritäts- und Authentizitätsschutz der Pakete (HMAC); bei AES-GCM sichert schon das Verschlüsselungsverfahren die Integrität der Nutzdaten, auth wirkt dann nur noch auf den Steuerkanal (z. B. mit tls-auth)
remote-cert-tls server	der Client akzeptiert nur ein Zertifikat, das für einen Server ausgestellt ist (Schutz vor Man-in-the-Middle)

Seit OpenVPN 2.5 handeln Client und Server das Verfahren für die Nutzdaten über die Option data-ciphers aus (z. B. data-ciphers AES-256-GCM:CHACHA20-POLY1305). cipher dient nur noch als Rückfallwert für ältere Gegenstellen, steht aber in vielen Konfigurationen und Prüfungsanlagen weiterhin.

Entscheidungen bei der Einrichtung

TCP oder UDP?

UDP und TCP als Transportprotokoll eines VPN

	UDP	TCP
Vorteil	wenig Overhead, keine doppelten Wiederholungen, gut für Sprache und Video	zuverlässige Übertragung mit Bestätigung, Fluss- und Reihenfolgekontrolle; kommt eher durch restriktive Firewalls (Port 443)
Nachteil	keine Empfangsbestätigung, wird in manchen Netzen blockiert	mehr Overhead; „TCP über TCP“: Bei Paketverlust wiederholen innerer und äußerer TCP-Strom gleichzeitig, das bremst stark

Faustregel: UDP, wenn es möglich ist; TCP nur, wenn UDP im Netz nicht durchkommt.

Routing oder Bridging?

• Routing (Schicht 3, tun): Die beiden Seiten sind verschiedene IP-Netze; der Tunnel ist ein eigenes kleines Transfernetz, und die Router brauchen Routen in das jeweils andere Netz. Das ist der Normalfall – insbesondere, wenn die Netze verschiedene Adressbereiche haben.

• Bridging (Schicht 2, tap): Beide Seiten bilden ein gemeinsames Ethernet-Segment mit einem gemeinsamen Adressbereich; auch Broadcasts gehen durch den Tunnel. Nur sinnvoll, wenn Anwendungen das zwingend brauchen, denn es erzeugt viel unnötigen Datenverkehr.

Wichtig beim Routing: Die Adressbereiche der verbundenen Netze dürfen sich nicht überschneiden. Nutzt das Homeoffice zufällig dasselbe private Netz wie die Firma (z. B. beide 192.168.178.0/24), weiß der Client nicht, welches Ziel lokal und welches im Tunnel liegt.

Split-Tunnel, Full-Tunnel und erzwungenes VPN

• Beim Split-Tunneling geht nur der Datenverkehr für das Firmennetz durch den Tunnel; Internetseiten ruft das Gerät direkt über den lokalen Anschluss auf. Das spart Bandbreite in der Zentrale, aber dieser Verkehr wird nicht von Firewall und Proxy der Firma gefiltert.

• Beim Full-Tunnel geht der gesamte Datenverkehr durch den Tunnel und von der Zentrale aus ins Internet. So greifen die Sicherheitsrichtlinien der Firma (Proxy, Filter, Protokollierung) auch unterwegs.

• Bei einem erzwungenen VPN (Always-on-VPN) baut das Gerät den Tunnel automatisch auf, sobald es ein Netzwerk hat, und lässt ohne Tunnel keinen Datenverkehr (außer für die Anmeldung an einem Hotspot) zu. Vorteile: Dienstliche Daten laufen nie ungeschützt über fremde Netze, Beschäftigte können das VPN nicht vergessen oder abschalten, und der gesamte Internetverkehr wird zentral gefiltert und auf Schadsoftware geprüft.

Eine typische Lücke ist IPv6: Ist der Tunnel nur für IPv4 eingerichtet und erhält das Notebook am Hotspot eine globale IPv6-Adresse, laufen IPv6-Verbindungen am Tunnel und am Proxy vorbei. Abhilfe: IPv6 im VPN mitkonfigurieren (auch IPv6 durch den Tunnel leiten) oder IPv6 außerhalb des Tunnels sperren.

VPN-Software und -Hardware auswählen

Bei der Software ist vor allem die Art der Authentifizierung wichtig:

Authentifizierung mit PSK oder Zertifikaten

	Pre-Shared Key (PSK) bzw. selbst verteilte öffentliche Schlüssel	X.509-Zertifikate einer Zertifizierungsstelle (CA)
Prinzip	Ein gemeinsames Geheimnis bzw. der öffentliche Schlüssel jeder Gegenstelle wird von den Admins auf allen Geräten hinterlegt.	Jede Seite weist sich mit einem Zertifikat aus, das eine CA signiert hat; die Gegenstelle prüft Signatur, Gültigkeit und Sperrstatus.
Vorteile	einfach, keine CA nötig, wenig Verwaltungsaufwand bei wenigen Standorten	skaliert für viele Geräte und Personen, Zertifikate laufen ab und können gesperrt werden, Speicherung auf Token oder Smartcard möglich
Nachteile	gleiches Geheimnis auf vielen Geräten, mühsamer Schlüsselwechsel, bei Verlust eines Geräts müssen alle Gegenstellen geändert werden; verlangt große Sorgfalt der Admins	eigene oder fremde CA nötig, Aufwand für Ausstellen, Erneuern und Sperren

Bei der Hardware (VPN-Gateway, Router, Firewall) zählen:

• Hardwarebeschleunigung für Kryptografie (z. B. AES-NI): sehr wichtig, sonst bricht der verschlüsselte Durchsatz deutlich ein. Datenblätter nennen dafür einen eigenen Wert (IPsec VPN Throughput).

• maximale Anzahl gleichzeitiger Tunnel (Site-to-Site und Clients) und Lizenzen für Remote-Access-Nutzende.

• Anzahl und Geschwindigkeit der Netzwerkports: genug für alle Leitungen, ggf. für Link-Aggregation und getrennte Zonen.

• garantierte Firmware- und Sicherheitsupdates über einen langen Zeitraum: Ein VPN-Gateway steht direkt im Internet; ohne Updates ist es ein Sicherheitsrisiko.

• unterstützte Protokolle und Verfahren (IKEv2, aktuelle Verschlüsselungsverfahren, ggf. WireGuard), Hochverfügbarkeit und Verwaltung.

• Die Leistungsaufnahme spielt für die Funktion des Tunnels keine Rolle, wohl aber für Betriebskosten und Green IT.

Grenzen und Nachteile eines VPN

• Overhead und Leistung: Zusätzliche Header verringern die Nutzdaten je Paket, Verschlüsselung kostet Rechenleistung; die Verbindung wird langsamer, die Latenz steigt.

• Kosten und Aufwand: Gateways, Lizenzen, Einrichtung, Zertifikatsverwaltung und Support.

• Komplexität bei der Fehlersuche: Probleme können am Client, im lokalen Netz, beim Provider, am Gateway oder im Zielnetz liegen.

• Kein Schutz für das Endgerät selbst: Ein mit Schadsoftware befallenes Notebook trägt diese auch durch den Tunnel ins Firmennetz. Viele Unternehmen ergänzen VPNs deshalb um Gerätekontrollen oder setzen auf Zero Trust Network Access (siehe Firewall und DMZ).

• Kommerzielle VPN-Dienste für Privatkund*innen sind etwas anderes als ein Firmen-VPN: Sie verbergen die eigene IP-Adresse gegenüber Webseiten, leiten den Verkehr teils über mehrere Server (Multi-Hop) und können Länderbeschränkungen umgehen. Einen Zugang zu einem Firmennetz schaffen sie nicht, und der Anbieter kann den gesamten Verkehr sehen.

Overhead, MTU und Übertragungsdauer

Ein Ethernet-Frame darf höchstens 1500 Byte Nutzlast (das IP-Paket) tragen (MTU, Maximum Transmission Unit); mit Header und Prüfsumme ist er 1518 Byte lang. Im Tunnel kommen zusätzliche Header dazu (bei IPsec im Tunnelmodus ein neuer IP-Header und der ESP-Header mit Trailer, zusammen rund 50 bis 80 Byte; bei WireGuard 60 bzw. 80 Byte). Passt ein Paket mit diesen Headern nicht mehr in 1500 Byte, muss es zerlegt (fragmentiert) werden – oder es wird verworfen, wenn Fragmentieren verboten ist.

Deshalb wird im VPN eine kleinere MTU eingestellt (z. B. 1400 Byte): Dann ist Platz für die zusätzlichen Informationen zur Verschlüsselung, Authentifizierung und Integrität, ohne dass fragmentiert werden muss. Testen lässt sich das unter Windows mit ping -f -l <Größe> <Ziel>: -f verbietet das Fragmentieren, -l legt die Größe der Nutzdaten fest. Antwortet der Ping mit „Paket müsste fragmentiert werden“, ist das Paket für die Strecke zu groß. (Zur Größe kommen beim Ping 28 Byte IP- und ICMP-Header hinzu.)

Rechenbeispiel: Über ein VPN mit 20 Mbit/s sollen 200 MiB übertragen werden. Von 1500 Byte MTU gehen 60 Byte für den Tunnel (äußerer IP-Header und ESP) und 40 Byte für den inneren IP- und TCP-Header ab:

\text{Nutzdaten je Paket} = 1500\ \text{Byte} - 60\ \text{Byte} - 40\ \text{Byte} = 1400\ \text{Byte}

\text{Anzahl Pakete} = \frac{200 \cdot 1024 \cdot 1024\ \text{Byte}}{1400\ \text{Byte}} \approx 149\,796{,}6 \rightarrow 149\,797

t = \frac{149\,797 \cdot 1518\ \text{Byte} \cdot 8\ \text{bit/Byte}}{20\,000\,000\ \text{bit/s}} \approx 90{,}957\ \text{s} \approx 91\ \text{s}

Ohne VPN (1460 Byte Nutzdaten je Paket) wären es rund 87 s – das VPN kostet hier gut 4 % Übertragungszeit.

Die Grafik stellt die Aufteilung eines Ethernet-Frames aus dem Rechenbeispiel ohne und mit VPN gegenüber:

Fehlersuche: Wenn das VPN nicht funktioniert

Gehe systematisch vor und grenze zuerst ein, wie weit die Verbindung kommt:

Fehlerbilder bei VPN-Verbindungen

Symptom	mögliche Ursachen	Beseitigung
Internet geht, Tunnel wird nicht aufgebaut (nur eine Person betroffen)	falsche Zugangsdaten oder abgelaufenes Passwort, Benutzerkonto bzw. Zertifikat am Gateway nicht angelegt oder abgelaufen, Client falsch installiert oder konfiguriert (Serveradresse, Protokoll), Uhrzeit falsch (Zertifikatsprüfung), lokale Firewall blockiert	Zugangsdaten und Benutzerkonto prüfen, Konfiguration bzw. Profil neu einspielen, Zertifikat erneuern, Uhrzeit synchronisieren, Protokolle von Client und Gateway auswerten
Tunnel scheitert an einem bestimmten Netz (Hotel, Hotspot, Mobilfunk), Webseiten funktionieren	Captive Portal noch nicht bestätigt, Ports bzw. Protokolle gesperrt (UDP 500/4500, ESP, UDP 1194), NAT ohne NAT-Traversal, AH hinter NAT, Provider blockiert VPN	zuerst am Portal anmelden, NAT-Traversal aktivieren, auf ESP statt AH umstellen, VPN über TCP 443 bzw. ein SSL-VPN anbieten, Mobilfunk-Hotspot nutzen
Tunnel steht, Ping auf das Gateway geht, interne Server sind nicht erreichbar	Route ins Firmennetz fehlt im Client (oder auf dem Gateway zurück), Adressbereiche überschneiden sich, Firewall-Regeln im Tunnel fehlen, interner DNS-Server nicht zugewiesen	Route (z. B. 10.10.0.0/16 über den Tunneladapter) ergänzen bzw. vom Gateway verteilen lassen, Adressbereiche ändern, Regeln ergänzen, DNS im Profil setzen
Kleine Pakete gehen, große Übertragungen hängen oder brechen ab	MTU zu groß, Fragmentierung verboten oder ICMP „Packet Too Big“ gefiltert	MTU im VPN-Client bzw. Gateway verringern (z. B. 1400 Byte), MSS-Clamping am Gateway, ICMP nicht vollständig sperren
Ein Teil des Verkehrs läuft am Tunnel vorbei	Split-Tunneling, IPv6 außerhalb des Tunnels	Full-Tunnel bzw. erzwungenes VPN, IPv6 in die VPN-Konfiguration aufnehmen

Hilfreich sind dabei ipconfig /all (hat der Tunneladapter eine Adresse?), route print bzw. ip route (gibt es eine Route ins Zielnetz über den Tunnel?), ping und tracert (wie weit kommen Pakete, laufen sie durch den Tunnel?) sowie die Protokolle von Client und Gateway.

Leitfragen

1. Was ist ein VPN, und welchen Vorteil bietet es bei der Nutzung öffentlicher Netze? Antwort

Ein Virtual Private Network ist eine logische, verschlüsselte und authentifizierte Verbindung (Tunnel) über ein öffentliches Netz, die sich wie ein privates Netz verhält. Daten können unterwegs weder mitgelesen noch unbemerkt verändert werden, und nur berechtigte Teilnehmende erhalten Zugang. siehe Abschnitt „Was ist ein VPN?“

2. Wie stellt ein VPN Vertraulichkeit, Integrität und Authentizität sicher? Antwort

Vertraulichkeit durch symmetrische Verschlüsselung (z. B. AES), Integrität durch einen Prüfwert je Paket (HMAC bzw. AES-GCM) und Authentizität durch Pre-Shared Key, Zertifikate oder Benutzeranmeldung mit zweitem Faktor; die Schlüssel werden beim Aufbau ausgehandelt. siehe Abschnitt „Welche Schutzziele erfüllt ein VPN?“

3. Wie unterscheiden sich Site-to-Site, End-to-Site und End-to-End, und wo wird das VPN jeweils eingerichtet? Antwort

Site-to-Site verbindet zwei Netze über je ein VPN-Gateway, End-to-Site ein Endgerät (VPN-Client) mit einem Netz (VPN-Gateway), End-to-End zwei einzelne Geräte, auf denen beiden das VPN läuft. siehe Abschnitt „VPN-Arten“

4. Warum hat ein IPsec-Paket im Tunnelmodus zwei IP-Header, und warum macht AH hinter NAT Probleme? Antwort

Der innere Header enthält die internen Adressen, der äußere die öffentlichen Adressen der Tunnelendpunkte, damit das Paket im Internet geroutet werden kann. AH sichert auch den äußeren Header; ändert ein NAT-Router dessen Adresse, stimmt der Prüfwert nicht mehr und das Paket wird verworfen. siehe Abschnitt „IPsec“

5. Was spricht für Zertifikate, was für einen Pre-Shared Key? Antwort

Ein PSK ist einfach und braucht keine CA, eignet sich aber nur für wenige Gegenstellen und erfordert viel Sorgfalt beim Verteilen und Wechseln. Zertifikate skalieren, laufen ab, lassen sich sperren und auf Token speichern, brauchen aber eine CA. siehe Abschnitt „VPN-Software und -Hardware auswählen“

6. Wann wählst Du UDP, Routing und Full-Tunnel für ein VPN? Antwort

UDP ist wegen des geringen Overheads die Regel, TCP nur, wenn UDP blockiert ist. Routing ist richtig, wenn die verbundenen Netze verschiedene Adressbereiche haben. Ein Full-Tunnel bzw. erzwungenes VPN sorgt dafür, dass der gesamte Verkehr durch die Sicherheitssysteme der Firma läuft. siehe Abschnitt „Entscheidungen bei der Einrichtung“

7. Warum wird die MTU in einem VPN verringert? Antwort

Die zusätzlichen Header des Tunnels brauchen Platz. Mit einer kleineren MTU (z. B. 1400 Byte) passen sie noch in 1500 Byte, ohne dass Pakete fragmentiert oder verworfen werden; dafür sinken die Nutzdaten je Paket. siehe Abschnitt „Overhead, MTU und Übertragungsdauer“

8. Ein Tunnel steht, aber interne Server sind nicht erreichbar. Wo suchst Du? Antwort

In der Routingtabelle des Clients (fehlt die Route ins Firmennetz über den Tunnel?), bei überschneidenden Adressbereichen, bei den Firewall-Regeln im Tunnel und bei der DNS-Zuweisung. siehe Abschnitt „Fehlersuche“

Links und weitere Informationen

• Übungen: Übungsaufgaben zu VPN

• Voraussetzung: Kryptografie, Routing

• weiterführend: Firewall und DMZ, IPv6-Adressierung, Subnetting und Autokonfiguration

• als Nachschlagewerk: BSI IT-Grundschutz-Kompendium, Baustein NET.3.3 VPN (Edition 2023, gilt bis Ende 2028), RFC 4301 – Security Architecture for IP, RFC 7296 – IKEv2, WireGuard

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “VPN: Arten, IPsec, Auswahl und Fehlersuche” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/vpn veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/it-sicherheit/schutzmassnahmen. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]