TL;DR

• Ein produktiver Site-to-Site-Tunnel blieb konstant bei rund 500 Mbit/s. Auf einem VpnGw2-Gateway, das für deutlich über 1 Gbit/s ausgelegt war.
• Die Ursache war weder die On-Prem-Firewall noch die Internetleitung noch die MTU. Es war die ausgehandelte Cipher-Suite: AES256 + SHA256 statt GCMAES256.
• Auf einem VpnGw2 macht diese eine Einstellung rund den Faktor 2,3 aus. 550 Mbit/s gegenüber 1,25 Gbit/s (Microsoft Learn, Stand 11. Juni 2026).
• Ausgelöst hat es eine Custom IPsec Policy, die eine Compliance-Anforderung erfüllen sollte. Sie hat das Audit bestanden. Gemessen hat danach niemand.
• Prüfe die ausgehandelte Security Association auf der Firewall, nicht die konfigurierte Policy im Azure-Portal.

Das Symptom

Ein regulierter Finanzdienstleister in Deutschland betreibt eine Site-to-Site-VPN-Verbindung zwischen einem eigenen Rechenzentrum und Azure. Auf der Azure-Seite lief ein VpnGw2-Gateway, dimensioniert für deutlich über 1 Gbit/s.

Anwender meldeten, dass große Übertragungen nach Azure langsamer liefen als bei der Dimensionierung zugesagt. Die Messung bestätigte das: Der Tunnel blieb konstant im Bereich von 500 Mbit/s. Nicht schwankend, nicht erst unter Last. Eine harte Decke bei ungefähr der Hälfte dessen, wofür das Gateway ausgelegt war.

Genau diese Konstanz ist das entscheidende Signal. Überlastung erzeugt Schwankungen. Ein ausgelastetes Gerät bricht unter Last ein und erholt sich, sobald die Last nachlässt. Eine flache Linie, die bei jeder Messung denselben Wert zeigt, bedeutet: Hier setzt etwas ein Limit durch, statt an seine Grenzen zu kommen.

Was wir zuerst vermutet haben und warum das nicht stimmte

Die erste These war die On-Prem-Firewall. Das ist der naheliegendste Kandidat und meistens der richtige Startpunkt. Viele Firewalls liefern beim IPsec-Durchsatz deutlich weniger als beim beworbenen Firewall-Durchsatz und beide Zahlen stehen auf derselben Datenblattseite, oft mit einem Faktor von 3 bis 5 dazwischen.

Aber: Die CPU-Last der Firewall blieb während der Übertragungen entspannt. Nichts arbeitete am Anschlag.

Also haben wir geprüft, ob wir schlicht falsch messen. Ein einzelner TCP-Stream erreicht über einen Tunnel mit realer Latenz selten dessen Maximum. Die TCP-Fenstergröße limitiert lange vor der Verschlüsselung. Mit iperf3 -P 8 lässt sich eine echte Decke von einem Messartefakt unterscheiden.

Aber: Die parallelen Streams veränderten den Gesamtdurchsatz nicht nennenswert. Acht Streams kamen zusammen ungefähr auf das, was ein einzelner erreichte.

Diese Kombination: entspannte Firewall, kein Gewinn durch Parallelisierung, ein flacher und reproduzierbarer Wert, schließt die beiden häufigsten Ursachen aus und zeigt auf etwas Konkretes: ein fixes Limit im Tunnel selbst.

Was es tatsächlich war

Die Verbindung handelte AES256 zur Verschlüsselung mit SHA256 für die Integrität aus, nicht GCMAES256.

Damit lag der Tunnel auf einem dokumentierten langsamen Pfad. Microsoft veröffentlicht Durchsatzwerte pro Tunnel, aufgeschlüsselt nach Algorithmus — und die liegen weit auseinander:

Die beobachteten rund 500 Mbit/s lagen wenige Prozent neben dem dokumentierten Wert für diese SKU und diesen Algorithmus. Diese Nähe hat aus einer Vermutung eine Diagnose gemacht.

Nach der Umstellung beider Seiten auf GCMAES256 für IPsec-Verschlüsselung und -Integrität stieg der Durchsatz über 1 Gbit/s. Die Änderung selbst dauerte Minuten.

Zur Einordnung: Das waren operative Messungen während eines laufenden Incidents, keine kontrollierte Benchmark mit festen Streamzahlen und Wiederholungen. Die belastbare Evidenz ist die dokumentierte Tabelle. Unsere Zahlen bestätigen sie der Tendenz nach und sie war der Grund, warum wir wussten, wo wir suchen müssen.

Warum es dazu kam

Das ist der Teil, der sich auf andere Umgebungen übertragen lässt.

Beim Kunden existierte eine Custom IPsec/IKE Policy, ganz bewusst gesetzt. Regulierte Umgebungen schreiben häufig konkrete kryptografische Parameter vor: eine Mindest-Diffie-Hellman-Gruppe, eine bestimmte Schlüssellänge, eine freigegebene Algorithmenliste aus einem älteren Standard.

Custom Policies sind in Azure ein Alles-oder-nichts: Man muss sämtliche Algorithmen und Parameter für IKE Main Mode und IPsec Quick Mode angeben, eine teilweise Spezifikation ist nicht zulässig (Microsoft Learn). Wer alle Felder füllt, muss sich zwangsläufig für ein IPsec-Verschlüsselungsverfahren entscheiden. AES im CBC-Modus wirkt dabei wie die sichere, offensichtlich konforme Antwort.

Die Policy bestand das Audit. Gemessen hat danach niemand. Der Tunnel lief monatelang mit halber Geschwindigkeit.

Es gibt einen zweiten Weg zum selben Ergebnis, den man kennen sollte, auch wenn man nie eine Custom Policy schreibt. Mit der Default Policy entscheidet Azure nicht, sondern verhandelt: Es sendet mehrere Proposals und kann als Initiator oder Responder auftreten. Welche Kombination gewinnt, hängt davon ab, was die Gegenstelle unterstützt und in welcher Reihenfolge sie ihre Proposals sendet. Viele Firewall-Defaults listen AES256 + SHA256 vor GCMAES256. Man landet auf dem langsamen Pfad, ohne dass jemand eine Entscheidung getroffen hätte.

Ein Punkt, der in jedem Compliance-Gespräch aufkommt und deshalb Betonung verdient: GCMAES256 ist nicht die schwächere Option. AES-GCM ist ein Authenticated-Encryption-Verfahren, das Vertraulichkeit und Datenursprungsauthentizität in einem Durchgang liefert, standardisiert für IPsec ESP in RFC 4106. Der Geschwindigkeitsvorteil kommt aus einem statt zwei Durchgängen, nicht aus weniger Kryptografie.

So prüfst du deine eigenen Tunnel

Azure zeigt dir die Policy, mit der es konfiguriert wurde. Die Firewall zeigt dir die Security Association, die tatsächlich ausgehandelt wurde. Wenn beide sich widersprechen, hat die Firewall recht.

1. Azure-Portal: Virtual Network Gateway → Connections → deine Verbindung → Configuration. Steht bei IPsec / IKE policy der Wert Default, lässt sich von hier aus nicht erkennen, was ausgehandelt wurde. Steht dort Custom, siehst du die konfigurierten Phase-1- und Phase-2-Algorithmen direkt.
2. Azure PowerShell: Get-AzVirtualNetworkGatewayConnection -Name "<ConnectionName>" -ResourceGroupName "<RG>" | Select-Object -ExpandProperty IpsecPolicies. Eine leere Ausgabe bedeutet: Default Policy aktiv.
3. Die Gegenstelle: Fortinet: diagnose vpn tunnel list. Palo Alto: show vpn ipsec-sa tunnel <name>. Cisco ASA/FTD: show crypto ipsec sa. pfSense/OPNsense: Status → IPsec. MikroTik: /ip ipsec installed-sa print.
4. Phase-2-SA lesen: dort sollte AES-GCM-256 beziehungsweise aes256gcm16 stehen. Erscheint stattdessen AES-256-CBC mit separatem Integritätsalgorithmus SHA256, hast du deinen Kandidaten gefunden.
5. Mit der richtigen Zeile abgleichen: kläre zuerst die Gateway-Generation. Generation 1 VpnGw2 endet auf dem langsamen Pfad bei 650 Mbit/s, Generation 2 bei 550 Mbit/s. Liegt dein gemessener Durchsatz wenige Prozent daneben, ist das kein Zufall.

Eine Falle bei der Umstellung: Bei GCM müssen für die IPsec-Integrität derselbe Algorithmus und dieselbe Schlüssellänge gewählt werden wie für die Verschlüsselung. GCMAES256 plus SHA256 ist keine gültige Kombination, der Tunnel kommt dann nicht hoch. Beide Seiten müssen gemeinsam umgestellt werden, plane die Neuaushandlung also ein.

Häufige Fragen

Warum zeigt die SKU-Tabelle 1 Gbit/s, mein Tunnel schafft aber weniger?
‍Die SKU-Tabelle nennt einen aggregierten Durchsatz-Benchmark für die gesamte Gateway-Instanz. Dieser Wert verteilt sich auf alle angeschlossenen Tunnel und wurde unter Idealbedingungen zwischen Azure-Regionen gemessen. Die Werte pro Tunnel stehen in einer separaten Tabelle auf derselben Seite, aufgeschlüsselt nach Verschlüsselungsverfahren.

Ist GCMAES256 unsicherer als AES256 + SHA256?
‍Nein. AES-GCM liefert Vertraulichkeit und Datenursprungsauthentizität in einem Vorgang und ist für IPsec ESP in RFC 4106 standardisiert. Es ist in regulierten Umgebungen anerkannt. Der Performancegewinn entsteht durch einen statt zwei Durchgänge.

Was, wenn meine Gegenstelle kein GCMAES256 unterstützt?
‍Dann ist AES256 + SHA256 dein praktisches Maximum, und du solltest das Azure-Gateway an der langsamen Zeile dimensionieren statt am Headline-Wert. Die meisten aktuellen Firewalls unterstützen AES-GCM mit Hardwarebeschleunigung. Ältere oder Einstiegsmodelle können es teilweise gar nicht oder nur ohne Beschleunigung, was den Vorteil aufhebt.

Mein Durchsatz ist niedrig, obwohl GCMAES256 aktiv ist. Was jetzt?
‍Prüfe im Datenblatt der Gegenstelle den IPsec-Durchsatz statt des Firewall-Durchsatzes, beobachte die CPU-Last während der Übertragung, setze TCP MSS Clamping auf etwa 1.350 Byte und stelle sicher, dass der On-Prem-Uplink symmetrisch ist.

Fazit

Die gewählte SKU legt eine Obergrenze fest. Die ausgehandelte Cipher-Suite entscheidet, wie viel von dieser Obergrenze tatsächlich ankommt. Auf einem VpnGw2 liegt zwischen den beiden dokumentierten Optionen mehr als der Faktor zwei, ohne Mehrkosten und ohne Sicherheitsnachteil.

Wenn ein Tunnel bei einem flachen, reproduzierbaren Wert deutlich unter seinem Rating steht: lies die ausgehandelte SA, bevor du irgendetwas zur Hardware eskalierst. Und wenn eine Custom IPsec Policy aus Compliance-Gründen existiert, miss sie einmal nach. Das Audit prüft die Algorithmen, nicht den Durchsatz.

Über den Autor Florian Lenz ist freiberuflicher DevSecOps Engineer, Cloud Architect und Microsoft Azure MVP. Er entwirft sichere, skalierbare Infrastruktur und verankert belastbare Security-Praktiken in Azure-Umgebungen.