This article is contributed. See the original author and article here.
For people new to networking, creating Azure Virtual Network subnets can be tricky. Learn how CIDR notation works to segment ranges of IP addresses.
When you create an Azure virtual network, you’ll get default IP addresses that look something like this:
This gives you a private address space at 10.1.0.0 with 65,536 addresses to use. Great!
(Note: These private IP addresses are not routable across the internet. If your devices need to be accessible on the public internet, visit Public IP addresses).
Now it’s not recommended to put all of your resources into that same address space. It’s inefficient from a network routing perspective, and it makes it harder to secure traffic and limit it between devices. A good security principle that applies to networking is to limit “lateral movement”, that is the ability for a hacker or infected device to easily communicate with other systems in your network. If we left this without any subnets, one compromised device could talk to the other 65,535 devices in our network.
Azure suggests that we add a subnet called default, with a Subnet address range of 10.1.0.0/24. What does that mean?
Well, subnets (literally sub networks) carve up or segment a bigger address space into smaller sections. We can then limit traffic in and out of this subnet (to the devices in this address space segment) by configuring a network security group. We can also add a network security group to the network interface of a specific virtual machine, to gives us another layer of network security control. To learn how this works, visit How network security groups filter network traffic.
Imagine your virtual network is a round, decorated birthday cake. You’ve carved out one segment of that birthday cake as a subnet, so it contains a smaller amount of those 65,536 addresses. How many does it contain? That depends on what CIDR notation you’ve used!
CIDR (Classless Inter-Domain Routing) is a method for allocating IP addresses. It’s the /x number, and that number determines how many IP addresses will be available in that subnet.
Stay with me if you want to go down the math rabbit hole of IP addressing for a moment, or skip to the next part. IP addresses (v4) are written as a set of four numbers, like 192.168.1.0.
These are converted to binary (the ones and zeroes that computers use), to look like this:
11000000 10101000 00000001 00000000.
We create a subnet by adding a “mask” to this number, telling the computer how many of the digits we want to read and keep the same (left to right).
With a /24, we’re saying “grab the first 24 digits” for this subnet, so that keeps the 192.168.1 and leaves us the “.0” on the end as a pool of addresses we can use in this subnet.
Those last 8 binary digits can only add up to 255 (with binary being a base 2 system) AND including zero as a possible value, that has defined our available 256 addresses we can use in this subnet – 0 to 255.
If we’d used a /29, keeping the first 29 digits, we’d only have 8 available IP addresses in this subnet, because 11000000 10101000 00000001 00000xxx leaves us just 000 left – a maximum binary value of 7 plus our zero value equals 8 IP addresses.
If you’re old school and are used to specifying subnet masks like 255.255.255.0, that’s a /24 CIDR notation, with its range of 256 IP addresses (255.255.255.0 to 255.255.255.255).
Skipped to here? Let’s continue!
The CIDR number is like specifying how large you want the slices of cake to be. Fortunately you don’t have to do the math, because there are a ton of free CIDR notation tables and calculators on the internet that will tell you how many addresses you’ll have in your subnet if you use a /28 or a /18 for example. When you add a subnet to your Azure virtual network, you’ll also get a note as you create it, telling you how many addresses will be available with the values you have entered.
Just remember, a subnet segments those address from the pool of your total available addresses. Segment two large subnets and you may not have room to add any more subnets.
In our example, the recommended default 10.1.0.0/24 gives us a subnet of 256 IP addresses EXCEPT Azure reserves 5 of these (the first and last address in each subnet for protocol conformance and 3 additional addresses for Azure service usage), so we have 251 available in Azure. This bundles up addresses 10.1.0.0-10.1.0.255.
So what if we want to add another subnet to this virtual network? Now we have to make sure we don’t overlap that subnet we already have!
Azure will suggest we use 10.1.1.0/24. Generally /24 is a good size for a subnet, and now we’d have:
Default 10.1.0.0 to 10.1.0.255
Subnet2 10.1.1.0 to 10.1.1.255
Again, keeping the first 3 parts of the IP address (24 digits in binary) the same.
Now we can keep on carving up our virtual network into different subnets, within the original 10.1.0.0 to 10.1.255.255 addresses (our 10.1.0.0/16 address space). Or, on reflection, we could have used a smaller CIDR notation for the original Azure Virtual Network, and created multiple different Vnets, each with their own subnets. There are just a couple of extra things to note …
Azure Virtual Network disallowed address spaces
The following address spaces cannot be used:
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)
168.63.129.16/32 (Internal DNS, DHCP, and Azure Load Balancer health probe)
Learn more at Create a virtual network
On-premises networks
IP addressing has to be unique – you can’t have two resources with the same IP address. If you’ve configured a Site-to-Site VPN to allow connectivity to/from an on-premises network, consider which private IP address spaces are in use in that on-prem environment, so your Azure vnets and subnets don’t conflict.
Gateway subnet
Speaking of VPN connections, if you’re using an Azure VPN Gateway it also needs gateway subnet of IP addresses. There are some rules around the configuration of this particular type of subnet – it must only contain your virtual network gateway resources, it must be named GatewaySubnet and it must be sized appropriately. You can’t change this sizing once you’ve deployed it, so Microsoft recommends a CIDR notation of /27 or “larger” (e.g. /26) to give you room for growth.
For more information on VPN Gateways, visit About VPN Gateway configuration settings
Want to learn more?
Secure and govern workloads with network level segmentation
Plan virtual networks – subnets
Add, change or delete a virtual network subnet
Gateway subnet guidance – About VPN gateway configuration settings
Azure Virtual Network and Azure VPN Gateway modules on Microsoft Learn
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments