Upgrading VPN Gateway SKU to VpnGw1AZ fails with "Deployment Validation Failed"

Question

Upgrading VPN Gateway SKU to VpnGw1AZ fails with "Deployment Validation Failed"

JFNK 71

I am trying to upgrade our VPN Gateway from VpnGw1 to VpnGw1AZ, in line with Microsoft's notice that this should be done before the end of September.

The instructions for this are here...

https://learn.microsoft.com/en-gb/azure/vpn-gateway/gateway-sku-upgrade

.. and it should be a simple matter of selecting the correct SKU in the dropdown in the VPNGateway | Configuration menu.

When I do this, and click "Save" I get the following error:

"Deployment validation failed.

Additional details from the underlying API that might be helpful: The template deployment 'VirtualNetworkGatewayUpdate-20260705134433' is not valid according to the validation procedure.

The following resource provider(s) - 'Microsoft.Network/virtualNetworkGateways (2025-05-01)' reported preflight validation errors. Tracking id is 'cbb5658b-42d0-4cd3-b837-ff944d266873'. See inner errors for details."

I can't find any further details or logs of the failure (CoPilot directed me to "Deployments" in the relevant Resource Group, but no entries existed for the failed attempts).

Can anyone advise what the problem may be, and/or any workaround to get the change in place?

In the URL above, it says "You can upgrade a SKU in the Azure portal, or by using PowerShell or the Azure CLI". I would try the PowerShell method as an alternative but I can't find any guidance on how to do do this. The URL only describes the Azure Portal method. Can anyone provide any info on this?

Thanks

Jeremy

0 comments

1 answer

Your answer

Answer 1

Nathan Roberts (SN) 13,356 Student Ambassador Volunteer Moderator

Hey there, JFNK

I can't find any further details or logs of the failure (CoPilot directed me to "Deployments" in the relevant Resource Group, but no entries existed for the failed attempts).

I think what is happening is the upgrade is failing before the ARM creates a deployment. This would explain why nothing is showing under deployments in the resource group. So this shows it is the pre validation stage that is failing, which is why you got the following error:

The following resource provider(s) - 'Microsoft.Network/virtualNetworkGateways (2025-05-01)' reported preflight validation errors. Tracking id is 'cbb5658b-42d0-4cd3-b837-ff944d266873'. See inner errors for details."

When looking researching this, it looks as though the ARM API blocked it before deployment, which happens when the existing gateway configuration is incompatible with the AZ SKU.

This means that your gateway subnet maybe too small. to upgrade the VPN Getaway SKU, it requires the gateway subnet to have at least a /27 or larger subnet. This is because it must have at least 3 available IP addresses. More information on this can be found here: https://learn.microsoft.com/en-us/azure/vpn-gateway/basic-public-ip-migrate-about#considerations

It may be worth checking your subnet to see if it is /27 or larger. The article mentions creating multiple prefixes for a submit from within the article linked.

n the URL above, it says "You can upgrade a SKU in the Azure portal, or by using PowerShell or the Azure CLI". I would try the PowerShell method as an alternative but I can't find any guidance on how to do do this. The URL only describes the Azure Portal method. Can anyone provide any info on this?

While the article does suggest you can upgrade the SKU using the PowerShell, I can't find any documentation that tells you how to do this. However, I did come across this article which may be useful: https://learn.microsoft.com/en-us/azure/vpn-gateway/gateway-sku-consolidation

Also, for future readers, upgrading the SKU does not change the public IP address, the gateway keeps the same IP address.

Hope this helps,
Nathan

JFNK 71 Reputation points

2026-07-06T14:05:45.7666667+00:00

Thanks Nathan

The gateway subnet is a /27. Can you think of any other reason why an existing, working gateway configuration would be incompatible with the AZ SKU?

I'm keen to avoid having to create a completely new gateway, given the risk of disruption to live operation.

Thanks again, Jeremy
Nathan Roberts (SN) 13,356 Reputation points Student Ambassador Volunteer Moderator

2026-07-06T18:03:44.7566667+00:00
Hey there, JFNK

If the gateway subnet is \27, then technically it should be enough. However, this will also depend on how many IP addresses are being used. It could also be something else that is blocking the migration.

Just have a few questions:

Does your gateway only have 1 IP configuration?

how many IP addresses in your gateway subnet are currently in use?

Do you have any custom IPsec or IKE policies?

Thanks,
Nathan
JFNK 71 Reputation points

2026-07-07T10:06:22.44+00:00

Hi Nathan

The Azure portal doesn't indicate how many addresses are in use on that subnet - it just says "availability dependent on dynamic use" - but I can say that the gateway is the only device on there.

I'm not quite sure what you mean by does it "only have only 1 IP configuration". It has two site-to-site VPN connections configured, if that's what you mean.

Regarding your third question, yes those connections are configured with custom IPsec/IKE policies. This was necessary because the default DH Group used by Azure was deprecated by Cisco devices some time ago. Could that be the issue? I wonder if the Azure default has been changed since then.

Thanks, Jeremy
Nathan Roberts (SN) 13,356 Reputation points Student Ambassador Volunteer Moderator

2026-07-08T19:59:21.65+00:00

Hey there, JFNK

Sorry for the delay in response. I literally need to read and digest the articles, then post a reply.

yes those connections are configured with custom IPsec/IKE policies. This was necessary because the default DH Group used by Azure was deprecated by Cisco devices some time ago. Could that be the issue? I wonder if the Azure default has been changed since then.

From what I have read, this could be the issue with why it is not allowing you to upgrade, because you may be using a DH group that isn't supported for the upgrade. Microsoft have a list of cryptographic algorithms & key strengths here: https://learn.microsoft.com/en-us/azure/vpn-gateway/ipsec-ike-policy-howto#cryptographic-algorithms--key-strengths

It is maybe worth checking which DH group your Cisco devices are using and comparing it against the supported list in the article above. If you do find you are using a DH that isn't supported, there may be a way you can change the DH group you are using to a supported one and seeing if this allows you to upgrade.

Hope this helps,
Nathan
JFNK 71 Reputation points

2026-07-12T15:59:57.1133333+00:00

Hi Nathan

Thanks for your efforts on this. I can confirm that the DH Group and other parameters we are using are included in the compatibility list you provided. Maybe it just doesn't like upgrading GW's which are using Custom policies. Seems wrong that this should be the case, but I could try setting to Default (which will drop the vpn connections), try the migration and, if that works, switch back to the Custom settings after.

It's a little risky, and too late on a Sunday for me to try now, but can maybe try on another weekend. Unless you have any other thoughts on what might be causing the failure?

Thanks again

Jeremy
JFNK 71 Reputation points

2026-08-08T11:03:00.1633333+00:00

Finally got round to trying this. Set all connections back to "default" IPsec/IKE policy and tried to do the migration to the AZ SKU. Same result. Set back to custom and confirmed VPNs came back up ok, but no nearer a solution. I suspect I'm going to have to delete the VPN Gateway and create a new one.

Thanks

Jeremy