AzureFeeds

Background

The Basic SKU public IP addresses associated with Azure VPN Gateway are scheduled for retirement in September 2025. Consequently, migration to Standard SKU is essential. This document compares three potential migration methods, providing detailed steps, advantages, disadvantages, and considerations.

1. Using Microsoft’s migration tool (Recommended)

When using Microsoft’s migration tool, the gateway’s IP address does not change. There is no need to update the configuration information on the on-premises side, and the current configuration can be used as is.

The migration tool is currently available in preview for active-passive VPN gateways with VpnGw1-5 SKUs. For more details, refer to the documentation on Microsoft Learn: About migrating a Basic SKU public IP address to Starndard SKU

Steps:

1. Check the availability of the migration tool: Confirm the release date of the migration tool compatible with your VPN gateway configuration through Azure service announcements or VPN Gateway documentation.
   
   
   
   
   • 
     

     What’s new in Azure VPN Gateway?

     
     
   
   
   • 
     

     Migrating a Basic SKU public IP address to Standard SKU | VPN Gateway FAQ

     
     
   
   
   
   


2. Preparation for migration:
   
   
   
   • Verify the gateway subnet: Ensure the gateway subnet is /27 or larger. If it is /28 or smaller, the migration tool will fail.
   
   
   • Test: It is advised to evaluate the migration tool in a non-production environment beforehand.
   
   
   • Migration planning: Schedule maintenance periods and inform stakeholders.
   
   
   
   


3. Start the migration: Execute the migration tool provided by Microsoft using Azure Portal. Follow the documentation provided when the tool is released. Ref: How to migrate a Basic SKU public IP address to Standard SKU – Preview.


4. Monitor the migration: Monitor the gateway status through Azure Portal during the migration process.


5. Post-migration verification: Confirm that the VPN connection is functioning correctly after the migration is complete.

Advantages:

• Downtime is estimated to be up to 10 minutes.


• The migration steps are straightforward.

Considerations:

• The release date of the tool varies by configuration (Active-Passive: April-May 2025, Active-Active: July-August 2025).


• Gateway subnet size restrictions (/27 or larger required).

Cautions:

• Regularly check the release date of the tool.


• Verify and adjust the gateway subnet size before migration if necessary.

2. Deleting and recreating the VPN Gateway within the existing virtual network

Manual migration without using Microsoft’s tool is another option, though it will cause downtime and may alter the IP address of the gateway. This option becomes a viable alternative when the GatewaySubnet is smaller than /27 and the migration tool is unavailable.

Steps:

1. Collect current VPN Gateway configuration information:
   
   
   
   • Connection types (site-to-site, VNet-to-VNet, etc.)
   
   
   • Connection details (IP address of on-premises VPN device, shared key, gateway IP address of Azure VNet, etc.)
   
   
   • IPsec/IKE policies (proposals, hash algorithms, SA lifetime, etc.)
   
   
   • BGP configuration (ASN, peer IP address, if used)
   
   
   • Routing configuration (custom routes, route tables, etc.)
   
   
   • VPN Gateway SKU (record for reference)
   
   
   • Resource ID of the public IP address (confirm during deletion)
   
   
   
   

You can use the Azure CLI command below to fetch the VPN Gateway configuration.

1. 
   
   
   
   • % az network vnet-gateway show –resource-group –name
   
   
   
   


2. Delete the existing VPN Gateway: Use Azure Portal, Azure CLI, or PowerShell to delete the existing VPN Gateway.


3. Upgrade the public IP addresses to Standard SKU. Employ Azure Portal, Azure CLI, or PowerShell to upgrade disassociated public IPs. For a detailed walkthrough, please consult the Microsoft Learn documentation: Upgrade Basic Public IP Address to Standard SKU in Azure
   
   
   
   • Please be aware that the IP address may change if the original public IP was dynamic or if a new public IP address is created.
   
   
   • Refer also to Azure Public IPs are now zone-redundant by default
   
   
   
   


4. Create a new VPN Gateway (Standard SKU): Leverage Azure Portal, Azure CLI, or PowerShell to create a new VPN Gateway, ensuring the following criteria:
   
   
   
   • Virtual network: Select the existing virtual network.
   
   
   • Gateway subnet: Select the existing gateway subnet. If the gateway subnet is smaller than /27, it is advisable to expand it to prevent potential future limitations.
   
   
   • Public IP address: Opt for the Standard SKU public IP address upgraded or created in step 3.
   
   
   • VPN type: Decide between policy-based or route-based as per the existing configuration.
   
   
   • SKU: Select Standard SKU (e.g., VpnGw1, VpnGw2). If zone redundancy is required, select the corresponding zone redundant SKU (e.g., VpnGw1AZ, VpnGw2AZ).
   
   
   • Other settings (routing options, active/active configuration, etc.) should adhere to the existing configuration.
   
   
   
   


5. Reconfigure connections: Based on the gathered configuration information, reestablish VPN connections (site-to-site, VNet-to-VNet, etc.) for the new VPN Gateway. Reset IPsec/IKE policies, shared keys, BGP peering, etc.


6. Reconfigure routing: If necessary, adjust custom routes and route tables to direct to the new VPN Gateway.


7. Test and verify connections: Confirm all connections are correctly established and traffic flows as expected.

Advantages:

• Immediate commencement of migration: No need to wait for a migration tool.


• Completion within the existing virtual network: No need to create a new virtual network.

Considerations:

• Downtime occurrence: All VPN connections are disrupted between the deletion and recreation of the VPN Gateway. The duration of downtime depends on the creation time of the VPN Gateway and the reconfiguration time of connections.


• Manual re-entry of configuration information: Existing VPN Gateway configuration information must be manually collected and entered into the new VPN Gateway, which may lead to input errors.

Cautions:

• Consider this approach if downtime is acceptable.


• Record current configuration details before deletion.


• The IP address may be subject to change depending on the situation.


• All the VPN tunnels need to be reestablished.


• If there are firewalls in place, this new public IP must be whitelisted.

3. Setting up a Standard SKU VPN Gateway in a new virtual network and gradually migrating

One approach is to set up a Standard SKU VPN Gateway in a separate virtual network and transition to it gradually. This minimizes downtime by keeping the current VPN Gateway operational while establishing the new environment. Detailed planning and testing are essential to prevent routing switch errors and connection configuration issues.

Steps:

1. Create a new virtual network and VPN Gateway:
   
   
   
   • Create a new virtual network to deploy a new VPN Gateway with a Standard SKU public IP address.
   
   
   • Create a gateway subnet (/27 or larger recommended) within the new virtual network.
   
   
   • Assign a Standard SKU public IP address and create a new VPN Gateway (Standard SKU). Select the necessary SKU (e.g., VPNGW1-5) and zone redundancy if needed (e.g., VPNGW1AZ-5).
   
   
   
   


2. Configure connections between the new VPN Gateway and on-premises VPN device:
   
   
   
   • Configure IPsec/IKE connections (site-to-site VPN) based on the new VPN Gateway’s public IP address and on-premises VPN device information. Configure BGP if necessary.
   
   
   
   


3. Adjust routing:
   
   
   
   • Adjust routing so that traffic from the on-premises network to Azure goes through the new VPN Gateway. This involves changing the settings of the on-premises VPN device and updating the routing policies of network equipment.
   
   
   • Adjust Azure-side routing (user-defined routes: UDR, etc.) to go through the new VPN Gateway if necessary. In a hub-and-spoke architecture, establish peering between the spoke virtual networks and the newly created virtual network. Additionally, ensure that the “Enable ‘Spoke-xxx’ to use ‘Hub-yyy’s’ remote gateway or route server” option is configured appropriately.
   
   
   
   


4. Switch and monitor traffic:
   
   
   
   • Gradually switch traffic to the new VPN Gateway.
   
   
   • Monitor the stability and performance of VPN connections during the switch.
   
   
   
   


5. Stop and delete the old VPN Gateway:
   
   
   
   • Once all traffic is confirmed to go through the new VPN Gateway, stop and delete the old VPN Gateway associated with the Basic SKU public IP address.
   
   
   • Delete the Basic SKU public IP address associated with the old VPN Gateway.
   
   
   
   

Advantages:

• Minimizes downtime: Maintains existing VPN connections while building the new environment, significantly reducing service interruption time.


• Ease of rollback: Easily revert to the old environment if issues arise.


• Flexible configuration: Consider more flexible network configurations in the new virtual network.

Considerations:

• Additional cost: Temporary deployment of a new VPN Gateway incurs additional costs.


• Configuration complexity: Managing multiple VPN Gateways and connections may complicate the configuration.


• IP address change: The new VPN Gateway will be assigned a new public IP address, requiring changes to the on-premises VPN device settings.

Cautions:

• Detailed migration planning and testing are essential.


• New VPN tunnels must be established to the newly created Standard SKU public IP addresses.


• If there are firewalls in place, this new public IP must be whitelisted.


• Be cautious of routing switch errors.

Recommended scenarios:

• When minimizing downtime is a priority.


• When network configuration changes are involved.


• When preparing for rollback.

Comparison table of migration methods

Conclusion

If minimizing downtime is necessary, using Microsoft’s migration tool or gradually migrating to a new virtual network are options. The method of deleting and recreating within the existing virtual network involves downtime and should be evaluated thoroughly.

The choice of migration method should be based on requirements, acceptable downtime, network configuration complexity, and available resources.

Important notes (Common to all methods)

• Basic SKU public IP addresses are planned to be retired by September 2025. It is essential that migration to Standard SKU is completed by this deadline.


• Post-migration, the VPN Gateway SKU may be automatically updated to a zone redundant SKU. Please refer to the article on Gateway SKU migration for detailed information regarding the implications of these SKU changes.
  
  
  
  • To learn more about Gateway SKU consolidation and migration, see About VPN Gateway SKU consolidation and migration.