GRE over IPsec vs. VTI: Performance, MTU, Troubleshooting im Vergleich

GRE over IPsec und VTI (Virtual Tunnel Interface) sind zwei etablierte Wege, um IPsec-VPNs „route-based“ zu betreiben. Beide können dynamisches Routing (BGP/OSPF/EIGRP) transportieren, beide können Multi-Subnetz-Szenarien sauber abbilden – und beide können trotzdem im Betrieb schmerzhaft sein, wenn MTU/PMTUD, Encapsulation und Troubleshooting nicht verstanden sind. Der wichtigste Unterschied ist die Schichtung: Bei GRE over IPsec kapselst du zuerst in GRE und verschlüsselst danach, bei VTI ist der Tunnel selbst bereits IPsec-geschützt. Das wirkt sich auf Overhead, MTU, Features (Multicast), Performance und Debugbarkeit aus. Dieser Artikel vergleicht beide Ansätze praxisnah – mit Fokus auf Performance, MTU und Troubleshooting.

Grundkonzept: Encapsulation-Stack im Vergleich

Der Encapsulation-Stack entscheidet über Overhead und Failure Modes. GRE fügt einen zusätzlichen Header hinzu, VTI spart sich GRE, kann aber je nach Plattform/Feature ebenfalls Overhead erzeugen (z. B. durch zusätzliche IPsec-Header).

Encapsulation als Stack

$\text{GRE over IPsec}:\text{IP}\to \text{GRE}\to \text{IPsec(ESP)}$
$\text{VTI}:\text{IP}\to \text{IPsec(Tunnel Interface)}$

• GRE over IPsec: mehr Overhead, dafür sehr flexibel (Multicast, „reines“ L3)
• VTI: weniger Header-Schichten, oft einfacher im Betrieb

Wann GRE over IPsec sinnvoll ist

GRE wird oft gewählt, wenn du Multicast oder bestimmte L3-Eigenschaften sicher transportieren willst, oder wenn du ein Design hast, das GRE ohnehin nutzt (z. B. DMVPN/MP-GRE). GRE ist auch hilfreich, wenn du Features brauchst, die in deinem VTI-Mode nicht sauber abbildbar sind.

• Multicast über VPN (PIM/IGMP) – häufig einfacher mit GRE
• DMVPN/mGRE Szenarien
• Komplexe Overlays, bei denen GRE das „Transportvehikel“ ist

Wann VTI in der Praxis die bessere Wahl ist

VTIs sind in vielen Enterprise-S2S-Designs der Standard, weil sie Skalierung und Betrieb vereinfachen. Routing ist sauber, Failover ist gut steuerbar, und du sparst dir GRE-spezifische Fehlerquellen. Für viele Standorte und viele Prefixes ist VTI meist die „wartbare“ Variante.

• Route-based VPNs mit dynamischem Routing (BGP/OSPF)
• Skalierung: viele Sites, Template-Konfiguration
• Einfacheres Troubleshooting (Tunnel-Interface als Single Object)

Performance: Was entscheidet wirklich?

In der Praxis entscheidet nicht nur Overhead, sondern vor allem die Data-Plane-Fähigkeit der Plattform (Hardware Offload, Crypto Throughput), die Paketgrößen (MTU) und ob du unnötige Fragmentierung erzeugst. GRE hat mehr Header, was minimal mehr Bandbreite kostet und unter Umständen mehr CPU/ASIC-Arbeit verursacht.

• Crypto Offload/ASIC ist der wichtigste Faktor
• Kleine Pakete (VoIP) sind CPU-sensitiver als große
• Mehr Overhead → weniger effektiver Throughput pro Link

Effektiver Throughput (vereinfacht)

$\text{Goodput}\approx \text{LinkRate}\times \text{(1 – OverheadRatio)}$

MTU: Der häufigste Praxisunterschied

GRE over IPsec hat typischerweise mehr Overhead als VTI, weil GRE zusätzlich kapselt. Das reduziert die effektive MTU stärker. Wenn PMTUD/ICMP gefiltert ist, entstehen Blackholes. In beiden Designs ist MSS Clamping ein Standard-Fix für TCP, besonders auf heterogenen WAN-Links (PPPoE/LTE).

• GRE over IPsec: höherer Overhead → niedrigere effektive MTU
• VTI: meist etwas mehr MTU-Headroom
• PMTUD muss funktionieren, sonst „small works, large fails“

MSS Faustregel

$\text{MSS(IPv4)}=\text{Path MTU}–40$

MTU-Debugging: So beweist du das Problem

Wenn du MTU-Probleme vermutest, testest du mit DF-Pings und beobachtest Drops. Wichtig ist, dass du den Test über den Tunnelpfad machst (Quelle/VRF korrekt), sonst misst du das Falsche.

DF-Ping (IPv4 Pattern)

ping <remote-host> df-bit size 1472 repeat 5
ping <remote-host> df-bit size 1400 repeat 5

Drops prüfen

show interfaces | include MTU|drops|error
show platform hardware qfp active statistics drop

MSS Clamping: Best Practice für beide Designs

Wenn du keine einheitliche Jumbo-MTU hast, ist MSS Clamping auf dem Tunnelinterface ein pragmatischer Standard. Es reduziert Tickets erheblich, weil TCP dann keine zu großen Segmente erzeugt. Der genaue Wert hängt vom Overhead ab; starte konservativ und verifiziere.

MSS Clamping auf VTI

interface Tunnel100
 ip tcp adjust-mss 1360

MSS Clamping auf GRE Tunnel

interface Tunnel0
 ip tcp adjust-mss 1360

Troubleshooting: Welche Ebenen du prüfen musst

Der wichtigste Unterschied im Troubleshooting ist, wie du den Tunnel „siehst“. Bei VTI ist der Tunnel ein einzelnes Interface-Objekt mit IPsec-Schutz. Bei GRE over IPsec musst du GRE-Status und IPsec-Status getrennt betrachten, was mehr Fehlermöglichkeiten schafft.

VTI: Standard Checks

show interface Tunnel100
show crypto ikev2 sa
show crypto ipsec sa
show ip route <remote-prefix>
show ip cef <remote-host> detail

GRE over IPsec: Standard Checks

show interface Tunnel0
show crypto ikev2 sa
show crypto ipsec sa
show ip route <remote-prefix>
show ip cef <remote-host> detail

Edge-Cases: Multicast, Routing Protokolle und QoS

GRE ist historisch der „einfachste“ Weg, Multicast über IPsec zu transportieren, weil GRE Multicast nativ kapseln kann. Bei VTI hängt Multicast-Fähigkeit stärker von Plattform/Release und Konfiguration ab. QoS kann bei beiden funktionieren, aber du musst wissen, wo du markierst (pre/post encrypt) und welche Bits erhalten bleiben.

• Multicast: GRE oft unkomplizierter
• Routing: beide geeignet, VTI meist einfacher
• QoS: Marking vor der Verschlüsselung planen (DSCP/TC)

Fehlerbilder im Vergleich: Was typischerweise schiefgeht

Die Fehlerbilder sind ähnlich, aber die Ursachen verteilen sich anders. GRE over IPsec hat mehr „moving parts“ (GRE + IPsec), VTI verlagert Komplexität stärker ins Routing- und Policy-Design.

• GRE over IPsec: Tunnel up, aber kein Traffic → MTU/PMTUD oder Crypto Selector/Policy
• GRE over IPsec: nur Hub erreichbar → Routing/Next-Hop über GRE falsch
• VTI: Tunnel up, aber Traffic falsch geroutet → Routing-Leak/Policy
• VTI: Failover bricht Sessions → Asymmetry/State, Tracking fehlt

Entscheidungsleitfaden: Welches Design ist „besser“?

Für die meisten Enterprise-Site-to-Site VPNs ist VTI die wartbarere Standardwahl. GRE over IPsec bleibt relevant, wenn du Multicast oder mGRE-basierte Patterns (DMVPN) brauchst oder wenn spezielle Overlay-Anforderungen existieren.

• Standard S2S + BGP/OSPF, viele Sites → VTI bevorzugen
• Multicast, DMVPN, mGRE/Shortcut Patterns → GRE over IPsec
• Heterogene Access-Links → MSS Clamping und PMTUD-Design sind Pflicht

Quick-Runbook: Vergleichs-Debug in 10 Minuten

Diese Checkliste hilft, bei beiden Designs schnell zu erkennen, ob das Problem Crypto, Routing oder MTU ist.

show crypto ikev2 sa
show crypto ipsec sa
show interface tunnel0
show interface tunnel100
show ip route <remote-prefix>
show ip cef <remote-host> detail
ping <remote-host> df-bit size 1400 repeat 5
show interfaces | include drops|error

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.