VPN Gateway: Deployment Failure — Intermittent Error During Creation

AdamVogt-6110 hi & thx for join me at Q&A platform,

VmssGatewayDeploymentFailed usually means the failure occurred while Azure was provisioning the underlying infrastructure for the VPN Gateway. The "intermittent error" message is pretty generic, tho, and doesn't tell us whether the actual cause is regional capacity, an availability zone issue, or an internal provisioning failure.

A /24 GatewaySubnet is more than sufficient for VpnGw1AZ, and the fact that u don't have conflicting gateways or Route Server resources eliminates several common configuration issues.

I'd check a couple of things before trying again. Make sure the gateway uses a Standard SKU, Static allocation Public IP, and that the selected region supports availability zones for this gateway SKU. Also check whether any NSG, custom route table, or Azure Policy is affecting the GatewaySubnet or gateway deployment.

The most useful information should be in Resource Group > Deployments > Failed deployment > Operation details. Look for the full nested error rather than just VmssGatewayDeploymentFailed. Also check the Activity Log for failed Microsoft.Network/virtualNetworkGateways operations and capture their correlation IDs.

One thing that stands out is that multiple deployments have failed over 24 hours with the same supposedly intermittent error. At that point, I wouldn't keep recreating the gateway. This could be a persistent provisioning issue in the regional VPN Gateway infrastructure rather than something u can fix through the portal.

I'd raise a case with the Azure VPN Gateway networking team and ask them to investigate the underlying gateway infrastructure deployment. Include the region, subscription ID, gateway resource ID, exact SKU, UTC timestamps, and deployment correlation IDs.

If u can share the region and the full inner deployment error, we might be able to narrow this down further. But if Azure is failing to allocate or initialize the gateway infrastructure internally, Microsoft will need to investigate that on their side.

rgds,

Alex

p.s. if my answer is help - pls mark it as an answer

Resolved: VmssGatewayDeploymentFailed when creating a VpnGw1AZ gateway after deleting a Basic SKU gateway

Scenario: I was replacing a Basic SKU VPN gateway with VpnGw1AZ so I could use point-to-site VPN with Entra ID authentication. A Basic gateway can’t be resized to VpnGw1AZ, so I deleted it and created a new gateway in the same virtual network and GatewaySubnet. The region was East US.

Symptom: Every new gateway deployment failed during backend provisioning. The error was ResourceOperationFailure with the inner error VmssGatewayDeploymentFailed: “The gateway deployment operation failed due to an intermittent error. Please try again.” The behavior was consistent:

• Each attempt was accepted, sat in Updating, and failed roughly 12 minutes later.
• It failed the same way from Azure CLI and the Azure portal, with Generation1 and Generation2, with and without a point-to-site configuration, and under different gateway names.
• Deleting the failed gateway and retrying, and re-sending the gateway configuration to retry provisioning, both failed the same way.

What I ruled out:

• Subscription: standard Pay-As-You-Go, enabled, no spending limit.
• Policy and permissions: no policy assignments, resource locks or deny assignments.
• Quotas: well under the limits.
• Gateway settings: active-passive, no BGP, no NAT, private IP and Advanced Connectivity disabled.
• GatewaySubnet: a /24 with no NSG, route table, NAT gateway or delegation. After deleting the failed gateway, it had no remaining IP configurations, service association links or resource navigation links.
• Public IP: Standard, static, zone-redundant. It showed healthy.
• Service Health: no active events.

The isolation test that found it: I created a throwaway VpnGw1AZ gateway in a brand-new virtual network in the same subscription and region. It used the same SKU, generation and zone-redundant public IP setup, and it deployed successfully. That ruled out regional capacity and the subscription, and pointed at something specific to my existing virtual network.

The fix: I deleted the GatewaySubnet and recreated it on a new, never-used address range (a /27), then created the gateway again. I kept the same public IP, the same SKU and the same point-to-site configuration. It deployed in about 33 minutes and has worked since. The site-to-site connection was recreated with the original shared key.

Likely cause: I can’t confirm it, but the evidence points to stale state in Azure’s backend on the old GatewaySubnet, left over from the deleted Basic gateway. While the Basic gateway existed, the GatewaySubnet showed a delegation to Microsoft.Network/virtualNetworkGateways that I never configured. It disappeared when the gateway was deleted. Azure had also already moved that Basic gateway’s public IP to an Azure-managed internal resource as part of the Basic public IP retirement. My guess is that something from that gateway kept a hold on the old subnet’s address range in the backend. Nothing in the portal or the CLI showed it, and every new gateway deployed into that range failed.

If you hit this error repeatedly:

1. Create a test gateway of the same SKU in a new, empty virtual network in the same region.
   • If the test fails too, it’s probably a regional or capacity issue. Open a support case.
     • If the test succeeds, the problem is specific to your virtual network.
     1. If the subnet previously hosted another gateway, delete the failed gateway, then delete and recreate the GatewaySubnet on a new address range. If the subnet delete fails with an “in use” error, something in the backend still holds it, and support has to clear it.
2. If the new subnet doesn’t fix it, try a new public IP next.Resolved: VmssGatewayDeploymentFailed when creating a VpnGw1AZ gateway after deleting a Basic SKU gateway Scenario: I was replacing a Basic SKU VPN gateway with VpnGw1AZ so I could use point-to-site VPN with Entra ID authentication. A Basic gateway can’t be resized to VpnGw1AZ, so I deleted it and created a new gateway in the same virtual network and GatewaySubnet. The region was East US. Symptom: Every new gateway deployment failed during backend provisioning. The error was ResourceOperationFailure with the inner error VmssGatewayDeploymentFailed: “The gateway deployment operation failed due to an intermittent error. Please try again.” The behavior was consistent:
   • Each attempt was accepted, sat in Updating, and failed roughly 12 minutes later.
   • It failed the same way from Azure CLI and the Azure portal, with Generation1 and Generation2, with and without a point-to-site configuration, and under different gateway names.
   • Deleting the failed gateway and retrying, and re-sending the gateway configuration to retry provisioning, both failed the same way.
   What I ruled out:
   • Subscription: standard Pay-As-You-Go, enabled, no spending limit.
   • Policy and permissions: no policy assignments, resource locks or deny assignments.
   • Quotas: well under the limits.
   • Gateway settings: active-passive, no BGP, no NAT, private IP and Advanced Connectivity disabled.
   • GatewaySubnet: a /24 with no NSG, route table, NAT gateway or delegation. After deleting the failed gateway, it had no remaining IP configurations, service association links or resource navigation links.
   • Public IP: Standard, static, zone-redundant. It showed healthy.
   • Service Health: no active events.
   The isolation test that found it: I created a throwaway VpnGw1AZ gateway in a brand-new virtual network in the same subscription and region. It used the same SKU, generation and zone-redundant public IP setup, and it deployed successfully. That ruled out regional capacity and the subscription, and pointed at something specific to my existing virtual network. The fix: I deleted the GatewaySubnet and recreated it on a new, never-used address range (a /27), then created the gateway again. I kept the same public IP, the same SKU and the same point-to-site configuration. It deployed in about 33 minutes and has worked since. The site-to-site connection was recreated with the original shared key. Likely cause: I can’t confirm it, but the evidence points to stale state in Azure’s backend on the old GatewaySubnet, left over from the deleted Basic gateway. While the Basic gateway existed, the GatewaySubnet showed a delegation to Microsoft.Network/virtualNetworkGateways that I never configured. It disappeared when the gateway was deleted. Azure had also already moved that Basic gateway’s public IP to an Azure-managed internal resource as part of the Basic public IP retirement. My guess is that something from that gateway kept a hold on the old subnet’s address range in the backend. Nothing in the portal or the CLI showed it, and every new gateway deployed into that range failed. If you hit this error repeatedly:
   1. Create a test gateway of the same SKU in a new, empty virtual network in the same region.
      • If the test fails too, it’s probably a regional or capacity issue. Open a support case.
      • If the test succeeds, the problem is specific to your virtual network.
   2. If the subnet previously hosted another gateway, delete the failed gateway, then delete and recreate the GatewaySubnet on a new address range. If the subnet delete fails with an “in use” error, something in the backend still holds it, and support has to clear it.
   3. If the new subnet doesn’t fix it, try a new public IP next.