VPN Performance: MTU, Fragmentierung und Throughput verbessern

VPN-Performance-Probleme wirken oft wie „langsam“ oder „instabil“, haben aber sehr konkrete Ursachen: zu große Pakete (MTU), Fragmentierung im Pfad, kaputtes Path MTU Discovery (PMTUD) oder CPU-Limits durch Verschlüsselung. Gerade bei IPsec, GRE over IPsec und DMVPN addiert sich Overhead, wodurch die effektive Nutzlast sinkt. Mit sauberem MTU/MSS-Tuning, gezielter Fragmentierungsstrategie und Throughput-Checks kannst du spürbar bessere Performance erreichen – ohne die Security zu schwächen.

Warum VPNs Performance kosten

Ein VPN fügt Header hinzu und verschlüsselt Daten. Das erhöht Paketgröße und CPU-Aufwand. Wenn der Underlay-Pfad keine großen Pakete akzeptiert oder ICMP blockiert ist, entstehen Retransmits und Timeouts – das kostet Throughput deutlich mehr als „ein bisschen Overhead“.

• Overhead: zusätzliche Header (IPsec, GRE, UDP/4500 bei NAT-T)
• Fragmentierung: mehr Pakete, mehr Processing, mehr Verlust-Risiko
• PMTUD-Probleme: große Pakete hängen → Retransmits → „gefühlt langsam“
• Crypto-CPU: Verschlüsselung kann zum Bottleneck werden

MTU, MSS und Fragmentierung: die drei Stellschrauben

MTU ist die maximale IP-Paketgröße, MSS ist die maximale TCP-Nutzdatenlänge. Fragmentierung passiert, wenn ein Paket größer ist als die MTU des nächsten Hops. Im VPN-Kontext ist MSS-Clamping oft der schnellste Praxisfix für HTTPS/Downloads.

• MTU: gilt für alle Protokolle (TCP/UDP/ICMP)
• MSS: nur TCP, beeinflusst Segmentgröße (SYN-Option)
• Fragmentierung: erhöht Overhead und Fehleranfälligkeit

MSS-Formel (IPv4, ohne Optionen)

$\text{MSS}=\text{MTU}–20–20$

Typische Overhead-Szenarien (Praxisorientierung)

Je nach VPN-Design sinkt die effektive MTU. Du brauchst nicht jede Bytezahl perfekt zu kennen – aber du musst erkennen, wann du konservativer clampen solltest (z. B. GRE over IPsec oder DMVPN).

• IPsec ohne NAT-T: weniger Overhead als NAT-T
• NAT-T (UDP/4500): zusätzlicher UDP-Header, oft kleinere effektive MTU
• GRE over IPsec/DMVPN: GRE + IPsec → hoher Overhead, MSS-Clamp praktisch Pflicht
• PPPoE + VPN: PPPoE reduziert MTU, VPN reduziert weiter

Diagnose Schritt 1: DF-Ping für Path MTU testen

Mit DF-Pings findest du die größte Paketgröße, die ohne Fragmentierung durch den Pfad kommt. Wenn DF-Pings ab einer Größe scheitern, ist der Path kleiner als gedacht oder ICMP wird gedroppt.

DF-Ping auf Cisco (Beispiel)

Router# ping 8.8.8.8 df-bit size 1472
Router# ping 8.8.8.8 df-bit size 1452
Router# ping 8.8.8.8 df-bit size 1400

Interpretation (IPv4)

Die Ping-„size“ ist Nutzlast. Rechne grob +28 Byte (IP+ICMP), um Richtung MTU zu denken.

$\text{MTU}\approx \text{PingSize}+28$

Diagnose Schritt 2: IPsec-Counters und Drops prüfen

Wenn VPN „langsam“ ist, prüfe, ob viele Drops/Errors auftreten. Besonders aussagekräftig sind „decrypt/verify failed“, „no sa“, Interface-Drops und steigende Retransmits auf Client-Seite.

Router# show crypto ipsec sa
Router# show interfaces tunnel0 | include MTU|drops|error
Router# show interfaces gigabitEthernet0/1 | include drops|error

Fix 1: MSS-Clamping setzen (TCP-Performance-Quickwin)

Für die meisten Web-/App-Probleme im VPN ist MSS-Clamping der schnellste Fix, weil er ohne globale MTU-Änderung wirkt. Setze ihn dort, wo der Overhead entsteht: Tunnel-Interface, Dialer (PPPoE) oder WAN-Edge.

Startwerte (praxisnah)

• PPPoE: MSS 1452 (MTU 1492)
• GRE over IPsec/DMVPN: häufig MSS 1360 als konservativer Start

MSS-Clamp am Tunnel (GRE/IPsec/DMVPN)

Router# configure terminal
Router(config)# interface tunnel0
Router(config-if)# ip tcp adjust-mss 1360
Router(config-if)# end

MSS-Clamp am PPPoE-Dialer

Router# configure terminal
Router(config)# interface dialer0
Router(config-if)# ip tcp adjust-mss 1452
Router(config-if)# end

Fix 2: MTU auf Tunnel/Interface korrekt setzen

Wenn du die effektive MTU kennst (oder durch DF-Ping ermittelt hast), kannst du MTU am relevanten Interface setzen. Das wirkt auch für UDP, ist aber invasiver als MSS-Clamping.

MTU am Tunnel setzen (Beispiel)

Router# configure terminal
Router(config)# interface tunnel0
Router(config-if)# ip mtu 1400
Router(config-if)# end

MTU am Dialer (PPPoE)

Router# configure terminal
Router(config)# interface dialer0
Router(config-if)# mtu 1492
Router(config-if)# end

Fix 3: Fragmentierungsstrategie bewusst wählen

Im VPN-Design gibt es grundsätzlich zwei Ansätze: (1) Fragmentierung vermeiden (MTU/MSS reduzieren) oder (2) Fragmentierung kontrolliert zulassen. In den meisten Unternehmensnetzen ist „vermeiden“ besser, weil Fragmentierung störanfällig ist.

• Vermeiden: MTU/MSS senken (stabiler, weniger Drops)
• Zulassen: kann funktionieren, erhöht aber Risiko bei Verlust
• ICMP nicht pauschal blockieren (PMTUD braucht ICMP)

Fix 4: NAT-T und UDP/4500 berücksichtigen

Wenn NAT-T aktiv ist, läuft IPsec häufig über UDP/4500. Das kann die effektive MTU weiter reduzieren. Stelle sicher, dass UDP/4500 nicht gefiltert wird und dass MSS/MTU konservativ genug ist.

Router# show crypto isakmp sa
Router# show access-lists

Throughput verbessern: Crypto-Bottlenecks erkennen

Manchmal ist MTU nicht das Problem, sondern CPU/Hardware. IPsec-Verschlüsselung kann Router auslasten, besonders bei hohen Bandbreiten oder schwacher Hardwarebeschleunigung. Dann helfen MTU/MSS nur begrenzt.

• Symptom: CPU hoch, Throughput niedrig, Latenz steigt unter Last
• Ursache: Crypto in Software statt Hardware
• Lösung: stärkere Plattform/Hardware-Acceleration/Profiling

CPU prüfen

Router# show processes cpu sorted
Router# show crypto engine accelerator statistic

Verifikation nach Änderungen

Nach MTU/MSS-Tuning verifizierst du erneut DF-Pings und die reale Anwendung (HTTPS/Downloads). Zusätzlich prüfst du IPsec-Counters und Interface-Drops, um sicherzustellen, dass du das Problem wirklich gelöst hast.

DF-Ping und Tunnel-Tests

Router# ping <remote-host> df-bit size 1400
Router# show crypto ipsec sa

Client-Tests (Beispiel)

Client$ curl https://example.com
Client$ iperf3 -c <remote-iperf-server>

Typische Fehler und Quick-Fixes

Diese Muster tauchen in der Praxis immer wieder auf. Wenn du sie erkennst, kannst du sehr zielgerichtet handeln.

• „Webseiten laden nicht“: MSS-Clamp setzen (z. B. 1360/1452)
• Nur große Downloads brechen: PMTUD/ICMP prüfen, DF-Ping testen
• Encaps steigt, Decaps niedrig: Rückweg/ACL/MTU prüfen
• CPU am Limit: Crypto-Throughput/Acceleration prüfen

Quick-Reference: Checkliste (Copy & Paste)

Diese Kommandos decken MTU, Tunnel, IPsec und Ressourcen ab.

show interfaces tunnel0 | include MTU|drops|error
show interfaces dialer0 | include MTU|drops|error
show crypto ipsec sa
show crypto isakmp sa
show processes cpu sorted
ping 8.8.8.8 df-bit size 1472
ping 8.8.8.8 df-bit size 1452
ping 8.8.8.8 df-bit size 1400

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.