Azure VPN Gateway Public IP Change and Subscription Move

Three different objects answer to "the gateway address" in Azure. The private address is allocated from GatewaySubnet. The public address is a separate public IP resource that the gateway's IP configuration points at. The subscription and cloud environment are the context your shell uses to find either one. Change one and the other two stay where they were, which is why address work so often stops halfway.

I run these changes in four stages: inventory the objects, decide whether the public IP moves on the existing gateway or the gateway gets rebuilt, apply the change while the old address is still in hand, then verify every tunnel from both ends before deleting anything. The inventory is the stage people skip.

Which of the three objects you are actually changing

Name the object before you open the portal. A VPN gateway takes its private address from a subnet that must be called exactly GatewaySubnet, and Azure allocates it from that prefix; there is no general field for pinning it. The address looks stable only because the subnet is stable. Re-address the subnet or rebuild the gateway and it moves with them.

The public address is editable, but SKU rules decide whether the edit is legal. A Basic gateway pairs with a Basic dynamic public IP, VpnGw SKUs need a Standard static one, and a zone-redundant gateway needs a Standard public IP carrying the same zones. The wrong SKU is rejected before a tunnel drops.

Inventory before anything moves

Prove the subscription first, because the rest of the inventory is worthless without it. Capture the gateway, its IP configurations and every connection that terminates on it, and keep the output beside the change record.

Get-AzContext | Select-Object Subscription, Tenant, Environment
Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub |
  Select-Object Name, Sku, EnableActiveActive, IpConfigurations
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName rg-hub |
  Select-Object Name, ConnectionStatus, ConnectionType

Resource IDs matter more than names. A connection holds references to the gateway and to a local network gateway, and those IDs show up in scripts, alerts and policy assignments nobody remembers. List what sits outside Azure too: the DNS name that resolves to the address, the partner permit list, the branch firewall that pins the old IP.

Swapping the public IP on the running gateway

Create the replacement address first, in the same region and with the zone set that matches the gateway, and leave the old resource in place. Then rebuild the IP configuration and push the update in one call. That call replaces the whole configuration collection, so an active-active gateway needs both configurations or you keep one tunnel and lose the other.

$gw = Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub
$pip = New-AzPublicIpAddress -Name pip-gw-hub-2 -ResourceGroupName rg-hub `
  -Location westeurope -AllocationMethod Static -Sku Standard
$conf = New-AzVirtualNetworkGatewayIpConfig -Name gwipconfig1 `
  -SubnetId $gw.IpConfigurations[0].Subnet.Id -PublicIpAddressId $pip.Id
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -IpConfigurations $conf

Tunnels drop while the gateway reprovisions. The remote side needs the scheduling: a peer firewall keeps offering the old address until someone edits it, and a connection whose remote end expects the previous IP stays down however healthy Azure looks. Lower the DNS TTL before the window.

Point-to-site clients need a fresh profile, since the downloaded package carries the endpoint. A custom DNS name in front of the gateway spares you the redistribution: keep the name, change the record.

Moving the gateway to another subscription

A resource move relocates a set, and the gateway alone is its least useful member. The virtual network, public IP resources, local network gateways and connections travel together because each holds a reference to another. The target subscription must sit in the same tenant, Microsoft.Network must be registered there, and you need write access on both sides.

Validation runs before anything changes, so a rejected move leaves the resources in place. That is why the move deserves an attempt before a rebuild: a successful move carries the public IP along, so peers and allowlists keep working, while a rebuilt gateway rarely returns the same address.

az resource move --destination-group rg-hub `
  --destination-subscription-id 00000000-0000-0000-0000-000000000000 `
  --ids /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

Read a validation failure instead of retrying it. The usual causes are a dependency left behind, a resource type that cannot move, or a lock on either resource group. If the move is impossible, rebuild in the target and cut over: confirm routing and authentication from a test subnet, stop the old connections rather than deleting them, then remove the old path in a later window.

When the gateway looks missing, check the context

The not-found error is usually a scope error. An account with several subscriptions points a cmdlet at the wrong one, and the message blames the resource. Look the object up by its full resource ID instead: the ID carries its own subscription, so if it resolves, nothing is missing and your default context is wrong.

Two more mismatches read the same way. A commercial-cloud gateway does not exist in a session aimed at a government or China environment, and older module versions miss resource shapes the API already returns. Pin the subscription, match the environment, then open a case.

Set-AzContext -SubscriptionId 11111111-1111-1111-1111-111111111111
Get-AzResource -ResourceId /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

Verify from both ends before cleaning up

Connected is a state, not evidence. Check tunnel status per connection, BGP peer state if you run dynamic routing, and effective routes on a workload subnet. Then push one real request through an application that depends on the tunnel. A connection can report connected while the prefix you need is absent from the route table.

Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName gw-hub -ResourceGroupName rg-hub
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-app -ResourceGroupName rg-app

Keep the old public IP disassociated rather than deleted until the fallback window closes, and write down the peer and firewall edits so they can be reversed in order.

• Context pinned to the subscription that owns the gateway
• Old public IP kept, its dependants written down
• Every connection green plus one real request through it
• Point-to-site users moved to the refreshed profile
• DNS record changed and its previous value recorded