Why is my Basic SKU P2S IKEv2 gateway dropping IKE_SA_INIT after the Feb 28, 2026 legacy deadline?

Question

Why is my Basic SKU P2S IKEv2 gateway dropping IKE_SA_INIT after the Feb 28, 2026 legacy deadline?

Sepehr Soltanieh 45

We have a P2S IKEv2 VPN gateway (Basic SKU, westus region) that worked reliably for months but stopped accepting connections around March 3-5, 2026. The issue affects all client machines (both Linux/strongswan and Windows 11 native VPN client).

Gateway configuration

SKU: Basic (Generation1)
VPN type: RouteBased, IKEv2
Public IP: Standard SKU, Static
P2S auth: Certificate (EAP-TLS)

What happened

We discovered through IKE client logs that the DNS record for our gateway hostname changed without any customer-initiated action:

The azuregateway-*.vpn.azure.com hostname previously resolved to our gateway's assigned public IP (let's call it IP-A)
It now resolves to a completely different IP (IP-B) that does not respond to IKE

IKE client logs confirm this:

Last successful connection (March 2, 2026):

charon-nm: initiating IKE_SA to IP-A
charon-nm: IKE_SA established

First failed connection (March 5, 2026):

charon-nm: initiating IKE_SA to IP-B
charon-nm: destroying IKE_SA in state CONNECTING without notification

The IKE_SA_INIT is sent but no response is received. The client retransmits 4 times over 60 seconds, then times out. Neither IP-A nor IP-B currently responds to IKE.

What we've ruled out

Client certificates are valid (not expired)
Root CA cert uploaded to Azure matches the local cert exactly
DNS resolution is consistent across all resolvers (Google, Cloudflare, Azure authoritative DNS)
No NSG on GatewaySubnet
Azure Resource Health reports gateway as "Available"
No changes in Azure activity logs for 90 days (no customer-initiated modifications)
Gateway reset via az network vnet-gateway reset — did NOT fix the issue
Tested connecting directly to the gateway's assigned public IP (IP-A) — also does not respond
Reproduced on both Linux and Windows 11 — same failure

Suspected cause

The timing of the breakage (March 3-5) aligns with infrastructure changes Microsoft began after the February 28, 2026 legacy SKU support deadline [1]. We suspect internal platform changes related to the legacy SKU migration timeline may have inadvertently affected our Basic SKU gateway's IKE service and DNS mapping.

We also note contradictory documentation regarding Basic VPN Gateway and public IP SKU compatibility:

[1] states: "The VPN Gateway Basic SKU currently supports only the Basic SKU public IP address resource."
[2] states: "No, you can't create a Basic SKU VPN gateway with a Basic SKU public IP address after June 2025. New Basic SKU VPN gateways require a Standard public IP address SKU."

Our gateway uses a Basic VPN Gateway SKU with a Standard public IP — a configuration that worked correctly for months and appears to be required by [2], yet is contradicted by [1].

Questions

Has anyone else experienced their Basic SKU P2S VPN gateway breaking around March 3-5, 2026?
Is this related to Azure infrastructure changes after the Feb 28, 2026 legacy SKU deadline?
Why would the azuregateway-*.vpn.azure.com DNS record change to a different IP that doesn't serve IKE?
What is the recommended path to restore P2S connectivity for a Basic SKU gateway in this state?
Can Microsoft clarify the contradictory documentation about Basic VPN Gateway and public IP compatibility ([1] vs [2])?

References

Venkatesan S 6,920 Reputation points Microsoft External Staff Moderator

2026-03-10T20:55:17.5766667+00:00
Hi Sepehr Soltanieh,

It looks like what you’re seeing is a side effect of Azure’s automatic migration efforts that kicked off right after the February 28, 2026, legacy‐SKU deadline. Here’s the gist and what you can do:

What likely happened
• Azure began auto-migrating legacy VPN Gateway SKUs (Standard→VpnGw1AZ, HighPerf→VpnGw2AZ) and also started deprecating Basic-SKU public IPs by end of March 2026.
• During that process your gateway’s “azuregateway-*.vpn.azure.com” name was repointed to a placeholder IP that doesn’t answer IKE, so clients time out.

Is this related to the Feb 28, 2026, deadline?
Yes. Although the Basic-SKU gateway itself isn’t retired, its Basic-public-IP support is being phased out. The backend infrastructure was realigned around the deadline, which inadvertently broke your IKE endpoint until you migrate.

Why the DNS switch?
To prepare for IP‐SKU consolidation, Azure changes the DNS entry to a holding address while it transitions your gateway’s IP resource. Until you run the migration, that IP won’t respond to IKE packets.

How to restore P2S connectivity
• Migrate your Basic-SKU public IP to a Standard SKU using the Basic IP migration tool (Portal, CLI or PowerShell).
PowerShell example:

Invoke-AzVirtualNetworkGatewayPrepareMigration -InputObject (Get-AzVirtualNetworkGateway …) -MigrationParameter (New-AzVirtualNetworkGatewayMigrationParameter -MigrationType UpgradeDeploymentToStandardIP)

Invoke-AzVirtualNetworkGatewayExecuteMigration -InputObject <YourGateway>

Commit with Invoke-AzVirtualNetworkGatewayCommitMigration once connectivity’s back.
• This retains your existing IP address, takes about 5–10 minutes of downtime, and will update the DNS back to the IP that serves IKEv2.
• Optionally, at the same time upgrade your gateway SKU to VpnGw1AZ (or higher) to ensure full future compatibility.

About the contradictory docs
• The VPN Gateway FAQ states “Basic SKU currently supports only the Basic SKU public IP resource.”
• The migration docs note that after June 2025 new Basic gateways require a Standard public IP.
• The reconciliation is this: while Basic‐SKU gateways remain supported, any Basic-public-IP asset must be migrated to Standard by end-Mar 2026. Once you run the Basic IP migration, your gateway continues to be “Basic SKU,” but with a Standard-SKU IP, and DNS will map correctly again.

Give the migration a shot and let us know if your IKEv2 sessions come back to life!

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

Please “up-vote” if the information helped you. This will help us and others in the community as well.
Sepehr Soltanieh 45 Reputation points

2026-03-10T22:00:35.3933333+00:00
Thank you for the detailed explanation. The root cause you described — Azure repointing the DNS to a placeholder IP during the post-Feb-28 IP-SKU consolidation — aligns exactly with the charon-nm log evidence we collected.

However, there's a critical detail about our configuration that changes the remediation path: our public IP is already Standard SKU, not Basic.

$ az network public-ip show --name vpn-gw-ip --resource-group MainRG -o table Name ResourceGroup Location SKU Tier AllocationMethod IpAddress --------------- --------------- ---------- -------- --------- ------------------ ------------- vpn-gw-ip MainRG westus Standard Regional Static <IP-B>

So the PowerShell migration commands you suggested (Invoke-AzVirtualNetworkGatewayPrepareMigration, etc.) don't seem applicable here — there's no Basic IP to migrate from.

Additionally, the gateway's migration status shows no migration has been initiated or is in progress:

"virtualNetworkGatewayMigrationStatus": { "errorMessage": "", "phase": "None", "state": "None" }

Given this, I have a few follow-up questions:

Is there an internal "Basic IP reference" on the gateway that's separate from the actual public IP resource SKU? The article Remove the Basic Public IP Reference from a Basic SKU VPN Gateway describes a portal-only "Delete Basic Public IP Reference" button under the gateway's Settings > Configuration page. Could this internal reference still exist even though the public IP resource itself is already Standard? If so, could Azure's consolidation process be acting on this stale reference?

If the "Delete Basic Public IP Reference" button does not appear on our gateway's Configuration page (since the IP is already Standard), what is the correct remediation for a Basic SKU gateway that already has a Standard public IP but had its DNS broken by the consolidation process?

Would recreating the gateway (delete and create a new Basic or VpnGw1 gateway on the same subnet with the same Standard public IP) be the only remaining option if the internal state can't be corrected?

Can Microsoft manually fix the DNS mapping for this specific gateway on the backend, since the breakage was caused by an Azure-initiated infrastructure change and not by any customer action?

Any guidance on how to proceed given that the IP migration step has effectively already been completed (or was never needed) would be greatly appreciated.
Venkatesan S 6,920 Reputation points Microsoft External Staff Moderator

2026-03-11T00:36:38.01+00:00
Hi Sepehr Soltanieh,

Thanks for all the details. It does look like your gateway still has an internal “Basic public IP reference” flag even though the actual Public IP resource is already Standard. That flag is what triggers the back-end migration pipeline (and the temporary DNS-to-placeholder change) after the Feb 28, 2026 legacy-SKU deadline. Here’s what you can try:

Remove the stale Basic-IP reference via the official migration tool

In the Azure portal, go to your VPN gateway > Settings > Configuration. You should see a Delete Basic Public IP Reference button. Hitting that will invoke the backend migration and update your gateway’s DNS back to the real IP that answers IKE.

If the button doesn’t appear, use PowerShell to drive the same pipeline:
$gw = Get-AzVirtualNetworkGateway -Name <YourGwName> -ResourceGroupName <YourRG> $migParams = New-AzVirtualNetworkGatewayMigrationParameter -MigrationType UpgradeDeploymentToStandardIP Invoke-AzVirtualNetworkGatewayPrepareMigration -InputObject $gw -MigrationParameter $migParams Invoke-AzVirtualNetworkGatewayExecuteMigration -InputObject $gw Invoke-AzVirtualNetworkGatewayCommitMigration -InputObject $gw
Even though your public-IP SKU is already Standard, this sequence forces the gateway’s internal state to reconcile and resets the DNS entry to your real IP.

Verify DNS & IKE respond After you commit the migration, confirm that azuregateway-*.vpn.azure.com again resolves to your IP-A and that IKE_SA_INIT packets get replies.

As a last resort, you can delete/recreate the gateway (or upgrade to a VpnGw1/AZ SKU) on the same subnet, reattach your existing Standard IP, then push new P2S configs. That will rebuild the correct DNS mapping.

Manual DNS fixes aren’t supported – the only supported path is running the Basic-IP migration pipeline or rebuilding/upgrading the gateway. If you hit any errors during the PowerShell steps or the portal button truly doesn’t appear, you’ll need to log an Azure support case so the service team can correct your gateway’s internal state.

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

Please “up-vote” if the information helped you. This will help us and others in the community as well.

Sepehr Soltanieh 45

Thanks for your help. Unfortunately, I wasn't able to fix the issue and encountered issues by following the step #1 of your instructions.

In Azure Portal > VPN Gateway > Settings > Configuration > Delete Basic Public Ip Reference, I see:

Since the button didn't appear, I tried running the PowerShell scripts which yielded the following:

  ~
  $ pwsh
  PowerShell 7.5.4
  
  PS /home/sepehr> Get-InstalledModule -Name Az
  
  Version              Name                                Repository           Description
  -------              ----                                ----------           -----------
  15.4.0               Az                                  PSGallery            Microsoft Azure PowerShell - Cmdlets to manage resources in Azure. This module is compatible with PowerShell and Windows PowerShell.…
  
  PS /home/sepehr> $gw = Get-AzVirtualNetworkGateway -Name vpn-gw -ResourceGroupName MainRG
  PS /home/sepehr> $gw
  
  ResourceGroupName Name       Location GatewayType VpnType    EnableBgp DisableIPsecProtection EnablePrivateIpAddress ActiveActive ProvisioningState Sku Name ExtendedLocation VNetExtendedLocationResourceId EnableBgpRouteTranslationForNat
  ----------------- ----       -------- ----------- -------    --------- ---------------------- ---------------------- ------------ ----------------- -------- ---------------- ------------------------------ -------------------------------
  MainRG            vpn-gw     westus   Vpn         RouteBased False     False                  False                  False        Succeeded         Basic                                                    False
  
  PS /home/sepehr> $migParams = New-AzVirtualNetworkGatewayMigrationParameter -MigrationType UpgradeDeploymentToStandardIP
  PS /home/sepehr> $migParams
  
  ResourceUrl MigrationType
  ----------- -------------
              UpgradeDeploymentToStandardIP
  
  PS /home/sepehr> Invoke-AzVirtualNetworkGatewayPrepareMigration -InputObject $gw -MigrationParameter $migParams
  Invoke-AzVirtualNetworkGatewayPrepareMigration: Migration type UpgradeDeploymentToStandardIP not allowed for the gateway /subscriptions/<my-subscription-id>/resourceGroups/MainRG/providers/Microsoft.Network/virtualNetworkGateways/vpn-gw
  StatusCode: 400
  ReasonPhrase: Bad Request
  ErrorCode: UpgradeDeploymentToStandardIPMigrationNotAllowedForGateway
  ErrorMessage: Migration type UpgradeDeploymentToStandardIP not allowed for the gateway /subscriptions/<my-subscription-id>/resourceGroups/MainRG/providers/Microsoft.Network/virtualNetworkGateways/vpn-gw
  OperationID : 4fa92ca2-67ba-4616-95cd-0ff6131c0c89
  
  # And of course, the following did run into errors as well:
  
  PS /home/sepehr> Invoke-AzVirtualNetworkGatewayExecuteMigration -InputObject $gw
  Invoke-AzVirtualNetworkGatewayExecuteMigration: Current Virtual network gateway migration state is None, it can not continue with migration state:Execute
  StatusCode: 400
  ReasonPhrase: Bad Request
  ErrorCode: CannotContinueMigrateGatewayWithIncorrectState
  ErrorMessage: Current Virtual network gateway migration state is None, it can not continue with migration state:Execute
  OperationID : 0c579d9f-0be7-4239-8d0e-8a55fef762e1
  
  PS /home/sepehr> Invoke-AzVirtualNetworkGatewayCommitMigration -InputObject $gw
  Invoke-AzVirtualNetworkGatewayCommitMigration: Current Virtual network gateway migration state is None, it can not continue with migration state:Commit
  StatusCode: 400
  ReasonPhrase: Bad Request
  ErrorCode: CannotContinueMigrateGatewayWithIncorrectState
  ErrorMessage: Current Virtual network gateway migration state is None, it can not continue with migration state:Commit
  OperationID : 0848560b-df09-4495-b75e-ffbcd11ca0a4

As shown above, every documented remediation path has been exhausted:

Portal: "Delete Basic Public IP Reference" tab shows "No migration necessary. Your Gateway does not have a PublicIpAddress reference or is using a PublicIpAddress with Standard Sku. No migration is necessary."
PowerShell: Invoke-AzVirtualNetworkGatewayPrepareMigration fails with UpgradeDeploymentToStandardIPMigrationNotAllowedForGateway — confirming there is nothing to migrate.
Gateway reset: Already attempted, did not fix the issue.
Direct IP connection: Tried connecting to the gateway's assigned public IP directly (bypassing DNS) — also does not respond to IKE.

The gateway is in a state where Azure's own tooling says no action is needed, yet the IKE endpoint is completely unresponsive and the DNS record still points to the wrong IP. This appears to be an internal platform-side inconsistency that cannot be resolved through any customer-facing tool.

@Venkatesan S — Could you please escalate this to the Azure VPN Gateway service team? The gateway's internal state needs to be corrected on the backend, as there is no customer-accessible path to fix this. Alternatively, if the service team confirms this cannot be repaired, I'd appreciate knowing that so I can proceed with recreating the gateway.

Venkatesan S 6,920 Reputation points Microsoft External Staff Moderator

2026-03-11T21:29:23.6033333+00:00

Hi Sepehr Soltanieh,

Could you please share the requested details via private message?
Sepehr Soltanieh 45 Reputation points

2026-03-11T23:22:40.25+00:00

@Venkatesan S — I've replied to your private message with the requested details and my availability.

Answer accepted by question author

1 additional answer

Your answer

Venkatesan S 6,920 Reputation points Microsoft External Staff Moderator

2026-03-11T21:29:23.6033333+00:00

Hi Sepehr Soltanieh,

Could you please share the requested details via private message?
Sepehr Soltanieh 45 Reputation points

2026-03-11T23:22:40.25+00:00

@Venkatesan S — I've replied to your private message with the requested details and my availability.

Answer 1

Hello **Sepehr Soltanieh
**I understand you're experiencing connectivity issues with the Point to Site VPN, where the connection keeps dropping.

Here are some suggestions to help resolve the problem:

First, check whether the certificate configuration is set up correctly both in the portal and on your local machine.
If everything is configured properly but the issue persists, try re-downloading the P2S VPN client file and remove the existing client file from your local machine and test it.
If the problem still isn't resolved, delete your current VPN configuration and re-create the point -to- site setup. Once that's done, download the new P2S VPN client file, test the connection, and let me know the outcome.

Additionally, you mentioned that after recreating the point-to-site configuration, your issue was resolved.

I hope the above answer helps you! Please let us know if you have any further questions.

Please don't forget to "accept the answer" and "upvote" where the information provided will help you, this can be beneficial to other members of the community.

Answer 2

The behavior described cannot be fully explained from the available documentation, but several points are clear from the context.

Similar reports or a specific incident around March 3–5, 2026 are not documented in the provided material. There is no explicit statement that Basic SKU gateways or their DNS mappings were changed or broken on those dates.
The documented platform changes around this timeframe concern:
- Retirement and migration of legacy VPN Gateway SKUs (Standard, High Performance) and Basic SKU public IP addresses, not the Basic VPN gateway SKU itself.
- Automatic migration of gateways that still use Standard or High Performance SKUs after March 2026, including SKU upgrades and IP handling. These changes are described for Standard/High Performance SKUs and Basic public IPs, not for a Basic gateway SKU with a Standard public IP. The context does not state that Basic SKU VPN gateways with Standard public IPs would be disabled or have DNS remapped as part of the legacy SKU deprecation.
The documentation in context does not describe any scenario where the azuregateway-*.vpn.azure.com FQDN is remapped to an IP that does not serve IKE, nor any automatic DNS change behavior tied to the February 28, 2026 legacy deadline. DNS behavior for gateway hostnames is not covered in the provided material.
Recommended recovery paths that are documented for legacy SKUs and Basic IP retirement are:
- Use the Azure portal migration tool to migrate Basic public IP addresses and associated gateways to Standard public IP and newer gateway SKUs that are supported by availability zones. As part of Basic IP migration, legacy SKUs (Standard, High Performance) are automatically migrated to newer SKUs such as VpnGw1AZ or VpnGw2AZ, with improved performance and no IP change when using the portal migration path.
- For Resource Manager deployments, when changing from a legacy gateway SKU to a new SKU, delete the existing VPN gateway and create a new VPN gateway, then recreate connections.
While these steps are documented for Standard/High Performance and Basic IP scenarios, they illustrate the supported pattern to restore service when a legacy configuration is affected by retirement: migrate to a current VpnGw* SKU and Standard public IP, or recreate the gateway on a supported SKU. In a situation where a Basic SKU gateway no longer responds to IKE and a reset does not help, the documented, supported path that aligns with current guidance is to:
- Plan to move off the Basic SKU to a supported VpnGw* SKU (for example, VpnGw1/VpnGw1AZ), and
- Recreate the gateway and P2S configuration on that SKU, then redistribute the new P2S configuration package to clients.
On the apparent documentation contradiction about Basic VPN Gateway and public IP compatibility:
- The context explicitly states that Basic SKU public IP addresses are being retired and that new gateways must use Standard SKU public IP addresses starting December 1, 2023, with the note that this limitation does not apply to creating a Basic gateway SKU that uses a Basic public IP address. It also states that Basic gateway SKU does not support IPv6 and does not support RADIUS.
- A separate Q&A item confirms that the final retirement date for Basic SKU public IP addresses has been extended to the end of March (previously January 31, 2026), and recommends using the migration tool in the Azure portal to migrate Basic public IPs and associated gateways to Standard SKU public IP before that date.
- The legacy SKU article in context focuses on Standard and High Performance SKUs and their migration to VpnGw1/VpnGw2/VpnGw1AZ/VpnGw2AZ, and on Basic IP migration; it does not explicitly restate all combinations of gateway SKU vs. public IP SKU.
From the provided material, the consistent, supported direction is:
- Basic public IP is being retired; customers must migrate Basic public IPs (and associated gateways) to Standard public IP before the retirement deadline, using the migration tool.
- As part of that migration, legacy gateway SKUs (Standard, High Performance) are automatically upgraded to newer VpnGw*AZ SKUs.
- The Basic gateway SKU itself is still listed as a valid Generation1 SKU, with P2S SSTP support and no IKEv2/RADIUS support today, and with a note that Basic SKU will start supporting IKEv2 in November 2025.
The context does not provide a direct, authoritative statement resolving the specific wording conflict between two external articles about “Basic gateway SKU currently supports only Basic public IP” versus “new Basic gateways require Standard public IP after June 2025.” It only clearly documents:
- Retirement of Basic public IPs and the requirement to migrate them.
- That new VPN gateways (in general) must use Standard public IPs starting December 1, 2023, with an exception for creating Basic SKU VPN gateways that still use Basic public IPs.

Given the limitations of the available documentation, the only supported remediation path that aligns with current guidance is to:

Move away from the affected Basic SKU gateway by creating a new VPN gateway on a supported VpnGw* SKU with a Standard public IP, and
Reconfigure P2S (and S2S, if any) on that new gateway, then distribute updated client configuration.

For clarification of the DNS behavior and the specific Basic SKU + Standard IP combination, and to investigate the suspected platform-side issue around March 3–5, 2026, opening a support case with Azure Support is necessary; this level of incident detail is not covered in the documentation provided.

References:

Share via

Why is my Basic SKU P2S IKEv2 gateway dropping IKE_SA_INIT after the Feb 28, 2026 legacy deadline?

Gateway configuration

What happened

What we've ruled out

Suspected cause

Questions

References

1 additional answer

Your answer