Why Adding an Azure VPN Prefix Drops the Connection

A prefix added on the wrong Azure object produces a connection that reports Connected and forwards nothing, which is the most expensive kind of mistake in this stack. Three resources are involved and only one of them owns the remote address space: the virtual network gateway, the local network gateway that describes the far side, and the connection that joins them. The prefix belongs to the local network gateway, the connection has to be rebuilt for the change to take effect, and the gateway itself is usually left alone. The order is not negotiable, and the portal only shows part of it.

Three objects, one of which holds the prefix

The virtual network address space answers a different question: what lives inside Azure. Adding a remote prefix there does not route traffic to it, it just widens the space the platform believes it owns, which can collide with the real remote range. The local network gateway is the object that holds the remote prefixes, and the connection references both gateways plus a pre-shared key.

There is a third reservation to keep straight. GatewaySubnet hosts the managed gateway instances, must carry exactly that name, and for non-Basic SKUs is expected to be at least a /27.

Nothing else belongs in that subnet, and a prefix change has no reason to touch it. A prefix missing from the local network gateway is unreachable regardless of what the connection status says, because the gateway only offers the prefixes it was told about when it negotiates the tunnel. That is why the symptom is asymmetric: the tunnel is up, the security association is fine, and one subnet never appears in the traffic selectors. If a single remote range is missing while its neighbours work, stop looking at the tunnel and read the local network gateway.

Why the connection is what gets removed

The connection object pins the negotiated configuration for its lifetime. Because of that, the documented procedure removes the connection first, updates the local network gateway, then recreates the connection with the same shared key. The gateway instances are not rebuilt for a prefix-only change, which keeps the outage bounded by the connection teardown instead of a gateway redeploy.

That deletion is the outage, so treat it as a scheduled change with a start and an expected end rather than a quick edit. In PowerShell the sequence is short: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, then Set-AzLocalNetworkGateway with the new -AddressPrefix array, then New-AzVirtualNetworkGatewayConnection with the same -SharedKey and the same gateways. Reusing the key matters, because the far side is not being reconfigured and a fresh key means coordinating with whoever owns the remote device. If another team runs that device, agree the window with them before you remove anything.

When the gateway itself has to be rebuilt

A second answer floating around this problem says the gateway must be recreated and the key re-exchanged. That is correct for a different set of operations: changing the gateway type or SKU, moving between point-to-site and site-to-site, or repairing a gateway whose own configuration is wrong. Those changes do alter the gateway resource, so a rebuild is genuinely required.

A gateway created for point-to-site cannot simply be handed a site-to-site connection. The point-to-site configuration has to be removed and the gateway recreated, which also produces a new shared key and a new client package.

The point-to-site package deserves its own note because it expires. The portal generates a file with a short lifetime, so the practical approach is to download it once and distribute it alongside the client certificate instead of sending users a portal link that will be dead by the time they click it. For the prefix question, none of this applies. Keeping the two procedures apart is the whole discipline: prefixes are a connection-level change, and gateway properties are a gateway-level change.

Read the state, not the portal badge

Read the state from the resource rather than from the badge in the portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 returns ConnectionStatus together with ingress and egress byte counters, and the counters are what separate a tunnel that is connected and carrying nothing from one that never established.

Counters that stop increasing in the middle of a transfer point at the path rather than at authentication. Counters that never move at all point at the prefix set or the shared key.

Timers explain a class of disconnects that get misattributed to the VPN. Azure's load balancer closes idle flows after its configured timeout, four minutes by default when these notes were written and configurable upward, so an OpenVPN server on a VM without keepalive can drop every few minutes while everything else looks healthy. A gateway that the platform is cycling can also interrupt a VNet connection to a Web App, and that failure sits on the platform side rather than in a client configuration. The tell is whether the disconnect follows a fixed interval or a change you made.

Keep the three objects and their values in one record: the virtual network address space, the local network gateway prefix list, and the connection's shared key reference. The site-to-site PowerShell article documents the local network gateway commands and the order they belong in. A prefix change compared against memory is how a working tunnel gets rebuilt twice.

Then verify in the order you changed: the local network gateway shows the new prefix list, the connection is back to Connected, and the counters move when you send traffic to a host in the new range. If the third step fails while the first two pass, the far side has not accepted the new traffic selector and the remote device needs the matching phase 2 entry. That is a conversation with the other end of the tunnel, not another change in Azure.