Azure GatewaySubnet Setup: Reserve It Before the Gateway

Open the virtual network in the portal and look at the address space before you touch the subnet blade. If that /24 is already carved into workload subnets with nothing free, there is no room for a /27 reservation, and you will end up either re-carving or widening the VNet, which is a different change with a different review. Settle the space first, then create the subnet.

That order matters because the gateway subnet is not a workload subnet with a special name. It is the address reservation for managed gateway instances, and Azure will refuse the gateway if the reservation is wrong.

Start with the address space

Write the VNet prefix, the workload subnets and the gateway reservation on one line before typing anything. A VNet on 10.60.0.0/16 has room; pick a range at the end so workload growth stays contiguous.

For example, 10.60.255.192/26 leaves 64 addresses for the gateway while workloads stay in 10.60.0.0/20. That is an address-planning example, not a sizing promise. Microsoft currently requires /27 or larger for non-Basic VPN gateways, where larger means more addresses: a /26 gives 64, while a /28 gives 16. Round up, never down, while the address plan is still moving.

Create the subnet with the exact name

In the portal, add a subnet and type the name GatewaySubnet exactly, capital G and capital S, with no spaces or suffix. Azure matches that string, so Gateway-Subnet or gateway produces a subnet the gateway service will not use.

The same step from the CLI, which is easier to put in a review:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

Leave the subnet empty. No VM, no private endpoint, no service delegation. If something already lives there, the deployment fails and the error rarely names the resource in the way, so check the subnet's resource list before you start.

Keep the managed subnet free of workload rules

Do not attach a network security group to this subnet; Microsoft marks that unsupported. Do not associate a route table whose default route sends 0.0.0.0/0 somewhere, because that can break gateway operation, and keep gateway route propagation enabled.

Put the access restrictions you actually wanted on the workload subnet or at an inspection boundary. Treating GatewaySubnet like a normal subnet is the mistake that produces a gateway which deploys cleanly and then passes no traffic.

Forced tunnelling has its own documented design. An improvised default route on the gateway subnet is not it.

Check the dependencies the portal does not show

Before you press create, walk the list: exact name, prefix inside the VNet space, no overlap with on-premises ranges, no workload resources inside, no NSG, and no route table with a default route. Each of those has broken a real deployment. Then confirm the wider design: the local network gateway for the on-premises side, the address spaces you expect to route, and whether active-active or coexistence is planned. Those choices change the sizing conversation, and they are much cheaper to settle now.

The Azure gateway settings reference is the page to quote when someone asks why the subnet cannot hold a VM.

If the gateway already exists

Resizing or replacing a gateway subnet is not a mask edit. Check the supported change procedure for the gateway SKU and generation first, and list the dependent objects: connections, public IPs, routing and any recovery requirement.

If the procedure requires recreating the gateway, plan it as a service migration with a window and a rollback. Record the reservation you chose, the reason for the size, and the rules you deliberately did not attach, so the next reviewer does not fix the empty subnet by adding an NSG.