VpnGw1AZ gateway creation fails repeatedly with InternalServerError (empty error details)

Admin Saxena 0 Reputation points
2026-08-18T10:29:39.9866667+00:00

I'm trying to create/recreate a route-based VPN Gateway (SKU: VpnGw1AZ, Generation2) in North Central US, and every deployment attempt fails with a generic InternalServerError and no further diagnostic detail.

Environment:

  • Subscription type: MCPP Subscription
  • Region: North Central US
  • Gateway type: VPN, Route-based
  • SKU: VpnGw1AZ (Generation2)
  • Resource group: contains parentheses in name, e.g. MyRG(NEW)

Error returned (consistent across all attempts):

 

json

Plain Text

{"status": "Failed","error": {"code": "ResourceOperationFailure","message": "The resource operation completed with terminal provisioning state 'Failed'.","details": [{"code": "InternalServerError","message": "An error occurred."}]}}

What I've already verified/tried (all failed identically):

  1. Confirmed GatewaySubnet is correctly sized (/24, well above the /27 minimum).
  2. Confirmed Public IP is Standard SKU, zone-redundant (zones: null), correctly configured for an AZ SKU.
  3. Deleted the gateway cleanly and recreated it from scratch via Azure CLI (az network vnet-gateway create) — same InternalServerError.
  4. Created a completely new gateway with a different name and a separate, newly-created Public IP (to rule out resource-specific corruption) — same InternalServerError.
  5. Tried Azure's own Support diagnostic-recommended PowerShell remediation:

 

powershell

Plain Text

   Get-AzVirtualNetworkGateway -ResourceGroupName "MyRG(NEW)" -Name "MyGateway" | Set-AzVirtualNetworkGateway

Same result:

 

Plain Text

   Set-AzVirtualNetworkGateway: Long running operation failed with status 'Failed'.
   ErrorCode: InternalServerError
   ErrorMessage: An error occurred.

This has now failed 6+ times over multiple hours across three different deployment mechanisms (CLI create, CLI delete+recreate, PowerShell PUT), ruling out configuration issues on my end.

Has anyone else hit this recently with VpnGw1AZ in North Central US? Is this a known regional/platform issue? Any guidance on working around it, or should this go straight to a support ticket?

Thanks in advance.I'm trying to create/recreate a route-based VPN Gateway (SKU: VpnGw1AZ, Generation2) in North Central US, and every deployment attempt fails with a generic InternalServerError and no further diagnostic detail.

Environment:

  • Subscription type: MCPP Subscription
  • Region: North Central US
  • Gateway type: VPN, Route-based
  • SKU: VpnGw1AZ (Generation2)
  • Resource group: contains parentheses in name, e.g. MyRG(NEW)

Error returned (consistent across all attempts):

 

json

Plain Text

{"status": "Failed","error": {"code": "ResourceOperationFailure","message": "The resource operation completed with terminal provisioning state 'Failed'.","details": [{"code": "InternalServerError","message": "An error occurred."}]}}

What I've already verified/tried (all failed identically):

  1. Confirmed GatewaySubnet is correctly sized (/24, well above the /27 minimum).
  2. Confirmed Public IP is Standard SKU, zone-redundant (zones: null), correctly configured for an AZ SKU.
  3. Deleted the gateway cleanly and recreated it from scratch via Azure CLI (az network vnet-gateway create) — same InternalServerError.
  4. Created a completely new gateway with a different name and a separate, newly-created Public IP (to rule out resource-specific corruption) — same InternalServerError.
  5. Tried Azure's own Support diagnostic-recommended PowerShell remediation:

 

powershell

Plain Text

   Get-AzVirtualNetworkGateway -ResourceGroupName "MyRG(NEW)" -Name "MyGateway" | Set-AzVirtualNetworkGateway

Same result:

 

Plain Text

   Set-AzVirtualNetworkGateway: Long running operation failed with status 'Failed'.

This has now failed 6+ times over multiple hours across three different deployment mechanisms (CLI create, CLI delete+recreate, PowerShell PUT), ruling out configuration issues on my end.

Has anyone else hit this recently with VpnGw1AZ in North Central US? Is this a known regional/platform issue? Any guidance on working around it, or should this go straight to a support ticket?

Thanks in advance.

Azure VPN Gateway
Azure VPN Gateway

An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.


1 answer

Sort by: Newest
  1. GitaraniSharma-MSFT 50,287 Reputation points Microsoft Employee Moderator
    2026-08-18T15:32:56.86+00:00

    Hello @Admin Saxena ,

    I understand that you are attempting to create a route-based VPN Gateway (SKU: VpnGw1AZ, Generation2) in the North Central US region, but every deployment attempt is failing with a generic InternalServerError.

    Could you please confirm whether you are explicitly selecting Generation2 for the VPN Gateway?

    The VpnGw1AZ SKU currently supports only Generation1. If Generation2 is being specified during deployment, that may be contributing to the issue.

    Refer: https://learn.microsoft.com/en-us/azure/vpn-gateway/about-gateway-skus#benchmark

    User's image

    You should deploy the VpnGw1AZ VPN Gateway using Generation1 and a Standard Public IP address.

    The Gen1 to Gen2 migration will happen automatically.

    For gateways that already use a Standard public IP address: No customer action is required. These gateways are automatically upgraded to the next generation (Generation 2) as part of regular service updates, ~end of Mar'27. This process is seamless and doesn't involve downtime.

    Refer: https://learn.microsoft.com/en-us/azure/vpn-gateway/gateway-sku-consolidation#is-gen1-gateway-sku-being-retired

    Kindly let us know if the above helps or you need further assistance on this issue.


    Please "Accept the answer" if the information helped you. This will help us and others in the community as well.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.