Wer die VPN Geschwindigkeit testen möchte, braucht mehr als einen schnellen Speedtest im Browser. Ein VPN verändert den Datenpfad (Routing), fügt Verschlüsselungs-Overhead hinzu, nutzt oft andere Protokolle (UDP/TCP) und hängt stark von Gateway-CPU, MTU, Paketverlust und der Qualität der Internetanbindung ab. Deshalb können zwei Tests, die „gleich aussehen“, völlig unterschiedliche Ergebnisse liefern: Ein Speedtest zeigt vielleicht 200 Mbit/s, während sich Videokonferenzen ruckelig anfühlen – oder Downloads sind schnell, aber Webapps reagieren träge. Genau hier hilft ein strukturiertes Messkonzept mit passenden Tools und klaren Metriken. In diesem Beitrag lernen Sie, welche Kennzahlen für VPN-Performance wirklich relevant sind (Durchsatz, Latenz, Jitter, Paketverlust, Retransmits, CPU, MTU), welche Tools sich dafür eignen (iperf3, ping/mtr, traceroute, Flent, Speedtest CLI, Wireshark) und wie Sie Ergebnisse richtig interpretieren. Ziel ist, dass Sie nicht nur „schneller/langsamer“ feststellen, sondern die Ursache eingrenzen können: Ist der Engpass die WAN-Leitung, das VPN-Gateway, ein QoS-Problem, NAT/Firewall-State, oder schlicht ein ungünstiger Pfad durch den Tunnel?

Welche Metriken die VPN-Geschwindigkeit wirklich beschreiben

„Geschwindigkeit“ ist im Netzwerkbetrieb kein einzelner Wert. Für VPNs sollten Sie mindestens diese Metriken erfassen:

• Throughput (Durchsatz): wie viele Bits pro Sekunde netto übertragen werden können (Up/Down getrennt).
• Latenz (Round Trip Time): wie schnell Pakete hin und zurück kommen; für interaktive Apps oft wichtiger als Durchsatz.
• Jitter: Schwankung der Latenz; kritisch für VoIP und Video.
• Paketverlust: bereits kleine Werte (z. B. 0,5–1 %) können TCP stark bremsen und Echtzeitdienste hörbar verschlechtern.
• Retransmits: TCP-Wiederholungen durch Verlust/Überlast; Indikator für „nicht sauber“ statt „zu langsam“.
• CPU/Offload am Gateway: VPN-Verschlüsselung ist CPU-intensiv; ohne Crypto-Offload wird das Gateway zum Flaschenhals.
• MTU/MSS: falsche MTU führt zu Fragmentierung oder Drops großer Pakete, was den Throughput massiv reduziert.

Eine einfache, aber nützliche Daumenregel: Für Webapps und Remote-Desktop sind Latenz und Verlust meist wichtiger als maximaler Durchsatz; für große Dateiübertragungen zählt Durchsatz und Stabilität (Retransmits/MTU).

Warum VPNs „langsam“ wirken: die häufigsten technischen Ursachen

• Backhaul: Full-Tunnel leitet Internettraffic über ein entferntes Gateway; das erhöht Latenz und reduziert effektiven Durchsatz.
• Crypto-Bottleneck: Gateway-CPU oder fehlender AES-NI/Crypto-Offload limitiert.
• UDP/TCP-Interaktion: manche VPNs kapseln TCP in TCP (TCP-over-TCP), was bei Verlust schlecht skaliert.
• Paketverlust im Underlay: WLAN, Mobilfunk, überlastete ISP-Links oder Peering-Probleme.
• MTU-Probleme: große Pakete fragmentieren oder werden verworfen; PMTUD wird durch ICMP-Filter sabotiert.
• QoS/Policing: Provider oder interne Policies priorisieren bestimmte Klassen falsch oder drosseln.

PMTUD-Hintergrund: Path MTU Discovery ist für IPv4 in RFC 1191 und für IPv6 in RFC 8201 beschrieben.

Messdesign: So testen Sie VPN-Performance sinnvoll

Bevor Sie Tools starten, legen Sie ein sauberes Testdesign fest. Ein gutes Design beantwortet drei Fragen:

• Baseline: Wie schnell ist die Verbindung ohne VPN (Underlay)?
• VPN-Pfad: Wie schnell ist es mit VPN, getrennt nach internem Traffic und Internettraffic?
• Engpass: Wo liegt die Limitierung (Client, WLAN, ISP, Gateway, Zielsystem)?

Best Practice: immer A/B testen

• Test 1: Ohne VPN (direkter Internetzugang oder internes Netz, je nach Szenario).
• Test 2: Mit VPN (gleiche Testziele, gleiche Zeitfenster).
• Test 3: Mit VPN zu einem internen Ziel (z. B. iperf3-Server im Rechenzentrum).
• Test 4: Mit VPN ins Internet (wenn Full Tunnel oder wenn Internet über VPN geführt wird).

Wichtig: Testen Sie zu festen Endpunkten. Öffentliche Speedtests ändern Serverstandorte dynamisch und verfälschen Vergleiche.

Tools für VPN-Geschwindigkeit: Was wofür geeignet ist

• iperf3: Standard für Throughput-Tests (TCP/UDP), sehr gut für kontrollierte Messungen. Projektseite: iperf3.
• ping: schnelle Latenzprüfung, aber begrenzt aussagekräftig unter Last.
• mtr: kombiniert ping und traceroute, zeigt Loss/Latenz pro Hop; sehr nützlich bei Underlay-Problemen. Infos: mtr.
• traceroute/tracert: Pfadvisualisierung; gut, um Backhaul oder falsches Routing zu erkennen.
• Speedtest CLI: grobe Internet-Performance; nützlich als Indikator, aber nicht als alleinige VPN-Messung. Tool: Speedtest CLI.
• Flent: kombiniert Tests (Throughput + Latenz unter Last), ideal für Bufferbloat-Analyse. Projekt: Flent.
• Wireshark/tcpdump: tiefes Troubleshooting (Retransmits, MSS, Fragmentierung, TLS/ESP), nicht primär „Speed“, aber extrem wertvoll. Wireshark: Wireshark.

Durchsatz messen mit iperf3: sauber, reproduzierbar, aussagekräftig

iperf3 ist das wichtigste Werkzeug, wenn Sie VPN-Throughput seriös testen wollen. Sie betreiben dafür einen iperf3-Server im Zielnetz (z. B. im Rechenzentrum, in der Cloud oder im internen Segment hinter dem VPN-Gateway) und messen vom Client aus.

TCP-Throughput testen

• Misst realitätsnahes Verhalten vieler Anwendungen (Downloads, Web, Dateiübertragung).
• Sehr sensitiv auf Paketverlust und Latenz (TCP Congestion Control).

# Server (im Zielnetz)
iperf3 -s
Client (ohne VPN und mit VPN vergleichen)
iperf3 -c 10.10.20.10 -P 4 -t 30

UDP-Throughput und Jitter testen

• Hilfreich für VoIP/Video-Szenarien und für VPNs, die UDP-basiert sind (WireGuard, viele IPsec-Setups).
• Sie sehen Jitter und Loss direkt.

iperf3 -c 10.10.20.10 -u -b 50M -t 30

Interpretation: warum Parallelstreams ( -P ) wichtig sind

Ein einzelner TCP-Stream erreicht über Pfade mit höherer Latenz oft nicht den maximalen Durchsatz. Mehrere parallele Streams (z. B. 4–8) nähern sich der Leitungskapazität an. Wenn Sie nur mit -P 1 testen, messen Sie oft eher TCP-Window-Limitierung als „VPN-Speed“.

Latenz und Jitter richtig messen: nicht nur „ping“

Ping ist ein guter Start, aber Latenz unter Last ist entscheidender. Nutzer spüren Probleme vor allem dann, wenn Latenz schwankt, sobald jemand im Hintergrund Daten überträgt (Bufferbloat).

Baseline-Latenz

# Windows
ping 10.10.20.10 -n 20
macOS/Linux
ping -c 20 10.10.20.10

Pfadstabilität und Loss pro Hop mit mtr

mtr -rw 10.10.20.10

• Loss am ersten Hop deutet oft auf WLAN/Local LAN.
• Loss erst später deutet auf ISP/Peering/Backhaul.
• Hohe Latenzsprünge können auf Umwege, Overload oder QoS-Policing hindeuten.

Latenz unter Last mit Flent

Flent kann z. B. gleichzeitig Traffic erzeugen und Latenz messen. Das ist besonders hilfreich, wenn Nutzer „VPN fühlt sich langsam an“ sagen, obwohl Speedtests gut aussehen.

• Interpretation: Wenn Latenz unter Last stark ansteigt, ist nicht unbedingt das VPN „zu langsam“, sondern der Pfad puffert zu viel oder QoS fehlt.

Wichtige Kennzahlen richtig interpretieren

Throughput ist kein Garant für gutes Nutzererlebnis

• Ein VPN kann 300 Mbit/s schaffen, aber mit 80–150 ms Latenz wirkt jede Webapp träge.
• Videokonferenzen leiden bei Jitter und Loss, auch wenn der Durchsatz hoch ist.

Paketverlust multipliziert sich mit Verschlüsselung und TCP

Schon geringer Paketverlust kann TCP stark ausbremsen, weil Retransmits und Congestion Control die Sendeleistung reduzieren. Wenn Sie hohe Retransmits sehen, ist die VPN-Geschwindigkeit oft Folge eines Underlay-Problems (WLAN/ISP) oder eines MTU-Problems, nicht „zu schwacher VPN-Algorithmus“.

MTU/MSS: der versteckte Performance-Killer

• Wenn PMTUD blockiert wird, entstehen „Blackhole“-Effekte: kleine Pakete gehen, große scheitern.
• VPN-Overhead reduziert die effektive MTU; MSS-Clamping am Gateway ist oft ein pragmatischer Fix.

VPN-spezifische Unterschiede: IPsec, OpenVPN, WireGuard

• IPsec/IKEv2: Sehr verbreitet, performant mit Hardware-Offload; empfindlich bei NAT-T/MTU und bei falsch gesetzten Proposals. Überblick: RFC 4301 und RFC 7296.
• OpenVPN: Flexibel, aber CPU-lastiger; je nach Setup UDP oder TCP. TCP-Modus kann in restriktiven Netzen helfen, ist aber bei Loss manchmal ineffizient.
• WireGuard: Sehr schlank, oft hohe Performance und gute Mobilität; Performance hängt dennoch vom Underlay und Gateway-CPU ab. Infos: WireGuard.

Messfallen: Warum Speedtests im VPN häufig täuschen

• Serverauswahl: Speedtests wählen „nahe“ Server; Ihr VPN-Gateway kann aber weit weg sein.
• Single vs. Multi-Stream: manche Tests sind multi-stream, andere nicht; Ergebnisse sind nicht direkt vergleichbar.
• Cache-Effekte: CDN und Browser-Caches verfälschen „Download-Gefühl“.
• Full Tunnel vs. Split Tunnel: Wenn Internet lokal bleibt (Split), misst Speedtest nicht das VPN, sondern den lokalen ISP.
• QoS und Traffic-Shaping: Provider priorisieren manchmal Speedtest-Traffic oder drosseln bestimmte Muster.

Praxis: Ein vollständiger Testplan für IT-Teams

Mit diesem Plan erhalten Sie reproduzierbare Ergebnisse, die sich zwischen Standorten und Zeitfenstern vergleichen lassen.

Testziele festlegen

• Internes Ziel: iperf3-Server im Rechenzentrum (idealerweise nahe am VPN-Gateway).
• Externes Ziel: definierter Internet-Endpunkt (z. B. ein Cloud-VM-Testserver), wenn Internet über VPN läuft.

Messreihen

• Ohne VPN: ping + mtr zum internen Ziel (falls erreichbar), sonst zu einem neutralen Ziel; Speedtest als ISP-Baseline.
• Mit VPN: ping + mtr + iperf3 TCP (1 Stream und 4 Streams) + iperf3 UDP (Jitter/Loss).
• Latenz unter Last: Flent (oder parallel iperf3 + ping), um Bufferbloat sichtbar zu machen.
• MTU-Check: wenn Symptome vorliegen (Teilabbrüche, große Downloads scheitern).

Dokumentation der Messbedingungen

• Uhrzeit, Standort, Zugangsnetz (WLAN/LAN/Mobilfunk), VPN-Profil, Tunneltyp (Split/Full)
• Gateway-Node (bei HA/Cluster), CPU-Auslastung am Gateway, ggf. Crypto-Offload aktiv
• Client-Gerät und OS-Version

Ergebnisse bewerten: Was ist „gut“?

Absolute Zahlen hängen stark vom Use Case ab. Statt „gut/schlecht“ ist es sinnvoller, Ziele pro Anwendung festzulegen:

• Webapps/Remote Desktop: niedrige Latenz (z. B. stabil < 50–80 ms), geringe Jitter-Spitzen, möglichst kein Loss.
• VoIP/Video: geringer Jitter, Loss nahe 0 %, stabile Latenz; QoS kann entscheidend sein.
• Dateitransfer: hoher stabiler Throughput, wenig Retransmits, keine MTU-Probleme.

Wenn Sie eine einfache Einordnung brauchen, hilft dieser Gedanke: Ein VPN ist „gesund“, wenn Durchsatz stabil ist und Latenz unter Last nicht explodiert. Ein „schneller Peak“ ist weniger wert als ein stabiler Mittelwert.

Wenn die VPN-Geschwindigkeit schlecht ist: die schnellsten Ursachen-Checks

• CPU am Gateway: Ist das Gateway ausgelastet? Krypto kann limitieren.
• Paketverlust: mtr zeigt Loss? WLAN/ISP prüfen.
• Routing/Backhaul: geht der Traffic einen Umweg? traceroute zeigt es oft schnell.
• MTU/MSS: große Transfers brechen? PMTUD/MSS prüfen.
• Split vs. Full: wird Internet unnötig durch VPN gezogen?
• QoS: VoIP/Video priorisieren, wenn Echtzeit wichtig ist.

Outbound-Links zur Vertiefung

• iperf3: Download und Dokumentation
• Speedtest CLI: Offizielles Tool
• Flent: Latenz unter Last messen
• mtr: Path- und Loss-Analyse
• Wireshark: Paket-Analyse
• RFC 1191: Path MTU Discovery (IPv4)
• RFC 8201: Path MTU Discovery (IPv6)
• RFC 4301: IPsec Architecture
• RFC 7296: IKEv2
• WireGuard: Offizielle Projektseite

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.