TL;DR
- A production site-to-site tunnel plateaued at around 500 Mbps on a VpnGw2 gateway with a rating well above 1 Gbps.
- The issue was not the on-premises firewall, the internet line, or the MTU. The issue was the negotiated cipher suite: AES256 + SHA256 instead of GCMAES256.
- On a VpnGw2, this setting alone is worth roughly 2.3 times the throughput. 550 Mbps versus 1.25 Gbps (Microsoft Learn, updated June 11, 2026).
- The cause was a custom IPsec policy written to satisfy a compliance requirement. It passed the audit. However, nobody benchmarked it afterwards.
- Check the negotiated security association on the firewall rather than the configured policy in the Azure portal.
The symptom
A regulated financial services customer in Germany set up a site-to-site VPN between an on-premises data center and Azure. The Azure side was a VpnGw2 gateway sized for over 1 Gbps.
Users reported that large transfers to Azure were slower than expected. Measurements confirmed this: the tunnel consistently plateaued in the region of 500 Mbps. Not erratically and not under load. It was a hard ceiling at roughly half of what the gateway was rated for.
Consistency is the useful signal here. Congestion produces variance. A saturated device produces variance under load and recovers when the load drops. A flat line at the same number every time means that a limit is being enforced rather than a system struggling to keep up.
What we assumed and why we were wrong
The first theory was the on-premises firewall. It usually is, and it’s usually the best place to start. Most firewalls deliver far less IPsec throughput than their advertised firewall throughput. The two numbers appear on the same datasheet page, with a 3–5× gap between them.
However, the firewall’s CPU remained at a comfortable level throughout the transfers. Nothing was working hard.
Therefore, we tested whether we were measuring the wrong thing. A single TCP stream over a tunnel with real latency rarely reaches the tunnel’s ceiling because TCP window sizing limits it long before encryption does. Running iperf3 -P 8 distinguishes a genuine ceiling from a measurement artifact.
However, the parallel streams didn’t meaningfully impact the aggregate. Eight streams reached roughly the same result as one stream.
This combination of an idle firewall, no gain from parallelism, and a flat, repeatable number rules out the two most common causes and points to a specific location: a fixed limit inside the tunnel itself.
What it actually was
The connection negotiated AES256 for encryption and SHA256 for integrity, rather than GCMAES256.
This puts the tunnel on the documented slow path. Microsoft publishes per-tunnel performance measurements broken down by algorithm, and they differ significantly:
Source: Microsoft Learn: About gateway SKUs
The observed ~500 Mbps fell within a few percent of the documented figure for that SKU and algorithm. This proximity turned a hypothesis into a diagnosis.
After switching to GCMAES256 for IPsec encryption and integrity at both ends, the throughput increased to over 1 Gbps. The change took minutes.
Note that these were operational measurements taken during a live incident, not a controlled benchmark with fixed stream counts and repeated runs. The documented table is harder evidence, and our numbers confirm its accuracy. It is also the reason we knew where to look.
Why it happened
This is the part that is worth carrying over to your own environment.
The customer had a custom IPsec/IKE policy that was deliberately configured. Regulated environments often require specific cryptographic parameters, such as a minimum Diffie-Hellman group, a particular key length, or an approved algorithm list inherited from an older standard.
In Azure, custom policies are all-or-nothing. You must specify every algorithm and parameter for both IKE Main Mode and IPsec Quick Mode because partial specification isn’t allowed. Filling out every field requires you to make a decision about the IPsec encryption algorithm. CBC-mode AES appears to be the safe, compliant answer.
The policy passed the audit. However, nobody benchmarked it afterwards. The tunnel ran at half speed for months.
There is another route to the same outcome that is worth knowing, even if you never write a custom policy. With the default policy, Azure negotiates rather than chooses. It sends a set of proposals and can act as the initiator or responder. The winning combination depends on what the on-premises device supports and the order in which it proposes. Many firewall defaults list AES256 + SHA256 ahead of GCMAES256. You can end up on the slow path without anyone making a decision.
It’s worth stressing because it comes up in every compliance conversation. GCMAES256 is not the weaker option. AES-GCM is an authenticated encryption mode that provides confidentiality and data origin authentication in a single operation. It is standardized for IPsec ESP in RFC 4106. Its speed comes from one pass instead of two, not from less cryptography.
How to Check Your Own Tunnels
Azure shows you the policy with which it was configured. The firewall shows you the security association that was negotiated. If they disagree, the firewall is correct.
To view this information, go to the Azure portal, select Virtual Network Gateway, then select Connections, then select your connection, and then select Configuration. If the IPsec/IKE policy reads “Default,” you cannot tell from here what was negotiated. If it reads “Custom,” the configured Phase 1 and Phase 2 algorithms are visible.
Use Azure PowerShell to run the command:
Get-AzVirtualNetworkGatewayConnection -Name "" -ResourceGroupName "" | Select-Object -ExpandProperty IpsecPolicies
An empty output means the default policy is in use.For the on-premises device, use Fortinet’s diagnose vpn tunnel list command. Palo Alto: show vpn ipsec-sa tunnel . Cisco ASA/FTD: show crypto ipsec sa; pfSense/OPNsense: Status → IPsec. MikroTik: /ip ipsec installed-sa print.
Read the Phase 2 SA. You want AES-GCM-256 or AES256GCM16. If it shows AES-256-CBC with a separate SHA256 integrity algorithm, you have found your culprit.
Match it with the correct row. First confirm your gateway generation. Generation 1 VpnGw2 tops out at 650 Mbps on the slow path, and Generation 2 tops out at 550 Mbps. If your measured throughput is within a few percent of the documented figure, it’s no coincidence.
One thing to watch out for when switching is that with GCM, the same algorithm and key length must be used for IPsec integrity as for encryption. GCMAES256 plus SHA256 is not a valid combination, so the tunnel won’t come up. Both ends must change together, so schedule the renegotiation.
FAQ
Why does my Azure VPN show 1 Gbps in the SKU table, yet less per tunnel?
The SKU table lists an aggregate throughput benchmark for the gateway instance. This benchmark is shared across all connected tunnels and is measured under ideal Azure-to-Azure conditions. Per-tunnel figures are listed in a separate table on the same page and are broken down by encryption algorithm.
Is GCMAES256 less secure than AES256 + SHA256?
No, because AES-GCM provides both confidentiality and data origin authentication in one operation, and it is standardized for IPsec ESP in RFC 4106. It is accepted in regulated environments. The performance gain comes from doing one pass instead of two.
What if my on-premises device doesn’t support GCMAES256?
In that case, AES256 + SHA256 is your practical limit, and you should size the Azure gateway based on the slow-path rate rather than the maximum rate. Most current-generation firewalls support AES-GCM with hardware acceleration. Older or entry-level models may not support it, or they may support it without acceleration, which negates the benefit.
My throughput is low, yet the cipher is GCMAES256. What should I do next?
Check the IPsec throughput figure in the on-premises datasheet rather than the firewall throughput. Watch the device CPU during the transfer. Set the TCP MSS clamping to about 1,350 bytes. Confirm that the on-premises upstream bandwidth is symmetric.
The takeaway
The SKU you select establishes a limit. The cipher suite you negotiate determines how much of that ceiling you receive. On a VpnGw2, the difference between the two documented options is greater than twofold, with no additional cost or security risk.
If a tunnel sits at a flat, repeatable number well below its rating, review the negotiated security association (SA) before escalating any hardware issues. If a custom IPsec policy exists due to a compliance requirement, benchmark it once; the audit checks the algorithms, not the throughput.
About the author: Florian Lenz is a freelance DevSecOps engineer, cloud architect, and Microsoft Azure MVP. He designs secure, scalable infrastructure and embeds rigorous security practices into Azure environments.
Top comments (0)