An Azure service that enables the connection of on-premises networks to Azure through site-to-site virtual private networks.
Hello Pavlos Bizimis
Why does the public IP show as Basic or appear as empty / null in the Azure portal?
This is a known portal/UI issue. The VPN gateway is using a Standard SKU public IP address internally, but the portal might still display:
- The old Basic SKU public IP address resource name
- A null or non-hyperlinked IP value
This is a cosmetic issue only and doesn't impact gateway functionality. In the meantime, use the JSON properties to view your IP.
Refer: Why does the public IP show as Basic or appear as empty / null in the Azure portal?
Meantime,
Here are the diagnostic steps and resolution paths to work through.
Step 1: Check for expired or stale Point-to-Site certificates.
One of the most common root causes for this exact error pattern is an expired client root certificate in the Point-to-Site configuration. The preflight validation succeeds, but when the deployment template tries to re-apply the gateway configuration during the reference removal, it hits the expired certificate and fails. To check and fix this:
- In the Azure portal, go to your Virtual Network Gateway.
- Under Settings, select Point-to-site configuration.
- In the Root certificate section, look for any expired certificates.
- Remove any expired or stale root certificates by selecting the three-dot menu next to each one and choosing Remove.
- Wait for the gateway update to complete (a few minutes), then retry the Delete Basic Public IP Reference operation.
Step 2: Verify no in-flight gateway operations are pending.
Sometimes a previous failed attempt leaves the gateway in a transitional state. Check the Activity Log for your VPN gateway resource to confirm there are no stuck or pending operations. If the gateway provisioning state is anything other than Succeeded, wait for it to fully settle before retrying.
To check this via PowerShell:
PowerShell
$gateway = Get-AzVirtualNetworkGateway -Name "<your-gateway-name>" -ResourceGroupName "<your-rg>"$gateway.ProvisioningState
Only proceed when this returns Succeeded.
Step 3: Check your gateway subnet for available IP addresses.
The migration operation requires at least three available IP addresses in your gateway subnet. If your subnet is /28 or smaller, the deployment may fail at the template apply step. Verify your GatewaySubnet has enough free address space before retrying.
Step 4: Retry after some time.
Community reports confirm this error has been intermittent for some gateways and resolved on its own after a few days, likely due to backend platform fixes rolling out. The fact that you received two different tracking IDs suggests the backend may be returning different error conditions on each attempt. Waiting 24 to 48 hours and retrying once more is a reasonable step before escalating.
“Delete Basic Public IP Reference” removes the association between your Basic SKU public IP resource and the Basic SKU VPN gateway. It’s not a migration of the VPN gateway SKU, and it shouldn’t impact VPN connectivity. Internally, Azure uses a Standard SKU public IP for the gateway after the reference is removed, but that Standard resource is internal and not customer-visible.
Because you mentioned the portal validation shows Succeeded but the deployment fails with:
PublicIPAddress SKU Name: Basic doesn't support DDoS Per-IP SKU Feature...
…it indicates the backend step is trying to apply or validate DDoS per-IP behavior that’s incompatible with Basic SKU public IP. The relevant public docs don’t include a specific workaround for this exact backend validation failure, so the recommended path is still to follow the documented portal workflow and validation logic.
Can you please update us if the action plan provided was helpful?
Should there be any follow-up questions or concerns, please let us know and we shall try to address them.
If these answer your question, click "Upvote" which may be beneficial to other community members reading this thread.