Azure IP Address Limitations & Reserved Ranges (What You Can’t Use and Why)

Azure VNets block multicast/broadcast and certain ranges. Also, each subnet loses 5 IPs to Azure reservations. Special Azure infrastructure IPs (like 168.63.129.16) power DNS/DHCP/health and must be allowed.

Ranges you can’t add to a VNet address space

Azure prevents adding these IPv4 ranges to VNet address space:

224.0.0.0/4 – Multicast
255.255.255.255/32 – Broadcast
127.0.0.0/8 – Loopback
169.254.0.0/16 – Link-local/APIPA
168.63.129.16/32 – Azure platform DNS/host services
These are explicitly listed in Microsoft’s VNet FAQ.

Tip: For private address space, Microsoft recommends RFC1918 (10/8, 172.16/12, 192.168/16) and also supports RFC6598 shared space (100.64/10) in Azure. Plan to avoid overlap with on-prem.

Azure reserves 5 IPs in every subnet

Within each subnet, Azure reserves the first four IPs and the last IP. Example for 192.168.1.0/24:

.0 network address
.1 default gateway (Azure)
.2 and .3 map Azure DNS into your VNet
.255 broadcast address
So a /29 leaves only 3 usable IPs; size subnets accordingly.

Special Azure infrastructure IPs you’ll see

168.63.129.16 – static, Microsoft-owned virtual public IP used for Azure DNS, DHCP, health probes/host communication. Allow outbound to this IP in local firewalls; only the Azure platform can source it.
169.254.169.254 – Azure Instance Metadata Service (IMDS) inside the VM (non-routable). Don’t proxy it; used by agents and scripts.

Multicast/broadcast support

Azure VNets don’t support multicast or broadcast (Layer 2). Use unicast alternatives (e.g., Azure Load Balancer, message brokers) or specialized partner solutions if you truly need multicast.

Choosing the right address space (best practices)

Use large enough RFC1918 blocks to avoid future overlap; keep some space unassigned for growth.
Avoid tiny subnets like /29 unless you’re absolutely sure; remember the 5 reserved addresses.
Document and reserve ranges for peering/ExpressRoute to prevent conflicts down the road.

Common mistakes & fixes

Error creating VNet/Subnet due to disallowed range: Re-plan CIDR to an allowed block; avoid the 5 restricted ranges above.
Health probes/DNS failing from the VM: Make sure outbound to 168.63.129.16 isn’t blocked by host firewall.
IMDS calls failing: Call http://169.254.169.254 directly (no proxy).

Quick verification (Portal & CLI)

Portal: VNet → Address space shows your CIDRs; ensure none are in the blocked list. Subnets → check size vs needed hosts.
Azure CLI:

az network vnet show -g <rg> -n <vnet> --query "addressSpace.addressPrefixes" az network vnet subnet list -g <rg> --vnet-name <vnet> --query "[].{name:name, prefix:addressPrefix}"

FAQ

Q: Can I bring public IP ranges into a VNet?
A: Azure allows various address spaces, but Microsoft recommends RFC1918/private (and RFC6598) to avoid conflicts. Public ranges can work but are rarely advisable for enterprise networking.

Q: Why does my VM talk to 168.63.129.16? Is it safe?
A: Yes. It’s a Microsoft-owned, fixed IP used by the Azure platform for DNS/DHCP/health—only Azure can source packets from it. Don’t block outbound to it.