Netzwerk & WAN

GETVPN

GETVPN (Group Encrypted Transport VPN) verschlüsselt den Verkehr vieler Standorte mit einem gemeinsamen Gruppenschlüssel, ohne Punkt-zu-Punkt-Tunnel.

  • Tunnellos, gemeinsame Gruppen-SA
  • Any-to-any über privates WAN
  • Header Preservation
  • Nativer Multicast
  • Cisco GETVPN / H3C GDVPN (GDOI)
Von Andreas Huser, Technische Beratung & Architektur Aktualisiert am 11 Min. Lesezeit

GETVPN (Group Encrypted Transport VPN) ist ein tunnelloses IPsec-Modell von Cisco: Statt paarweiser Tunnel teilen sich alle Teilnehmer eine gemeinsame Gruppen-SA und verschlüsseln so any-to-any, ohne Overlay-Topologie. Das passt zu Netzen, in denen ohnehin schon jeder jeden erreicht, typisch ein privates MPLS-Backbone.

Dieser Artikel erklärt das Kernkonzept der Header Preservation (und warum es GETVPN ans private WAN bindet und vom Internet fernhält), die Rollen Key Server und Group Member samt GDOI und Rekeying, die zeitbasierte Replay-Abwehr TBAR, die typischen Einsatzfelder, die Cisco-Bindung und das gleichartige H3C-Pendant GDVPN.

1. Tunnellos: eine SA für alle

Bei klassischem IPsec handelt jedes Endpunkt-Paar seine eigene SA aus. GETVPN dreht das um: Ein zentraler Key Server verteilt eine gemeinsame SA an alle Group Member. Jeder kann sofort mit jedem verschlüsselt kommunizieren, ohne erst eine Verbindung aufzubauen. Die Zahl der Sicherheitsbeziehungen wächst damit nicht quadratisch mit der Standortzahl.

2. Header Preservation: der entscheidende Trick

Technisch nutzt GETVPN den IPsec-Tunnel-Modus, aber mit Adresserhalt und ohne ein klassisches Overlay aufzubauen (in diesem Sinne tunnellos): Der äußere IP-Header trägt nicht Tunnel-Endpunkte, sondern eine Kopie der originalen Quell- und Zieladresse. Dadurch routet das darunterliegende Netz weiterhin anhand der echten Adressen, QoS-Markierungen bleiben sichtbar, und nativer IP-Multicast funktioniert ohne Replikation am Tunnelkopf.

Header Preservation ist Segen und Grenze zugleich: Im privaten MPLS-/WAN-Backbone ist es ideal, weil die Provider-Routing- und QoS-Logik erhalten bleibt. Über das Internet scheitert es: NAT verändert genau die Adressen, die GETVPN bewahrt, und private Adressen sind dort ohnehin nicht routbar. GETVPN gehört deshalb ins private WAN, nicht ins Internet.

3. Key Server, Group Member und GDOI

Zwei Rollen: Der Key Server (KS) definiert die Gruppenrichtlinie, authentifiziert die Mitglieder und verteilt das Schlüsselmaterial. Die Group Member (GM) sind die Standort-Router, die sich registrieren und danach autonom verschlüsseln. Die Verteilung läuft über GDOI (Group Domain of Interpretation, RFC 6407, UDP 848): GMs ziehen beim Registrieren den Verkehrsschlüssel (TEK) und den Rekey-Schlüssel (KEK).

Schlüssel werden regelmäßig erneuert (Rekey), per Unicast (mit Bestätigung) oder skalierbarer per Multicast. Da ein einzelner KS ein Single Point of Failure wäre, koppelt man mehrere als COOP-Key-Server (Cooperative); der mit höchster Priorität wird primär, die anderen halten den Zustand synchron.

Cisco IOS: GETVPN Group Member (GDOI)

crypto gdoi group GETVPN
 identity number 1001
 server address ipv4 10.0.0.1
!
crypto map CMAP 10 gdoi
 set group GETVPN
!
interface GigabitEthernet0/1
 crypto map CMAP

4. Anti-Replay ohne Sequenzfenster: TBAR

Weil viele Sender dieselbe SA nutzen, funktioniert das klassische Sequenznummern-Fenster nicht. GETVPN nutzt stattdessen TBAR (Time-Based Anti-Replay): Jedes Paket trägt einen Pseudotime-Zeitstempel, den der Empfänger gegen ein Zeitfenster (Standard 30 Sekunden) prüft. Die Pseudotime gibt der Key Server vor, sie ist von der realen Systemzeit unabhängig.

Zeit-Tücke beachten

Springende Systemuhren (abrupte NTP-Korrekturen) können auf manchen Plattformen TBAR-Fehler und Paketverluste auslösen; NTP nur schrittweise (slew) korrigieren lassen. In weiträumigen WANs mit hoher Latenz oder asymmetrischem Routing muss das TBAR-Fenster großzügig genug zum maximalen Laufzeitunterschied passen, sonst werden gültige Pakete als Replay verworfen.

5. Typische Einsatzfelder

  • Flächige Verschlüsselung im privaten WAN viele Standorte über ein Carrier-MPLS-VPN, die any-to-any verschlüsselt kommunizieren sollen (Banken, Versorger, Behörden).
  • Multicast-lastige Netze nativer Multicast bleibt dank Header Preservation ohne Replikationsproblem erhalten.
  • QoS-sensible Anwendungen VoIP/Video, weil die DSCP-Markierung im erhaltenen Header sichtbar bleibt und der Provider priorisieren kann.

6. Herstellerwelten: GETVPN und H3C GDVPN

Der Name GETVPN ist Cisco-spezifisch (GDOI ist offen, die Gesamtarchitektur mit Header Preservation, TBAR und COOP nicht). Das Konzept der GDOI-Gruppenverschlüsselung gibt es aber auch bei anderen: H3C bietet mit GDVPN (Group Domain VPN) ein gleichartiges Modell, ebenfalls auf GDOI (RFC 6407), mit gemeinsamer Gruppen-SA, KS/GM-Rollen, KEK/TEK-Rekey, Header Preservation und zeitbasiertem Anti-Replay. Eine Besonderheit der H3C-MSR-Router: Sie arbeiten in der Regel nur als Group Member, der Key Server kommt von einer anderen Plattform.

Beide sind funktional verwandt, aber nicht als interoperabel dokumentiert; man bleibt je in einer Herstellerwelt. Und beide lösen dasselbe Problem: any-to-any-Verschlüsselung über ein bestehendes privates Netz. Sobald NAT oder das öffentliche Internet im Spiel sind, ist Gruppenverschlüsselung das falsche Werkzeug; dann führen DMVPN oder ein Site-to-Site-VPN zum Ziel. In der Praxis kombiniert man beides (Gruppenverschlüsselung im MPLS-Kern, DMVPN als Internet-Backup).

7. Best Practices und typische Fehler

  • COOP immer mindestens zwei kooperierende Key Server; ein einzelner KS gefährdet beim Rekey das ganze Netz.
  • Fail-Close konfigurieren ohne gültige Schlüssel soll der Verkehr nicht im Klartext laufen; Ausnahmen für Routing- und Management-Verkehr explizit erlauben.
  • Stabile Zeit NTP slew-only, besonders auf empfindlichen Plattformen, sonst TBAR-Paketverluste.
  • TBAR-Fenster zur Latenz passen in großen WANs großzügig dimensionieren.
  • Kein NAT/Internet GETVPN niemals über NAT oder das öffentliche Internet einsetzen.

8. Stärken und Grenzen

StärkenGrenzen
Eine gemeinsame SA: any-to-any ohne quadratischen Tunnel-AufwandNur für private WANs; NAT und Internet sind ausgeschlossen
Header Preservation: Provider-Routing und QoS bleiben sichtbarHerstellergebunden: GETVPN (Cisco) bzw. GDVPN (H3C), untereinander nicht interoperabel
Nativer Multicast ohne Replikation am TunnelkopfKey Server kritisch: ohne COOP/Rekey droht Ausfall oder Klartext
Schnelle Kommunikation, keine Tunnelaushandlung pro FlussTBAR empfindlich gegen Uhrensprünge und asymmetrisches Routing
Zentrales, auditierbares Schlüsselmanagement (GDOI)Kein Internet-Backup; dafür separat DMVPN/Site-to-Site nötig

Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.

Der nächste Schritt

GETVPN im eigenen Haus richtig einsetzen?

Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.

Erstgespräch vereinbaren oder Formular ausfüllen