Once deployment is finished, you have different management options available. Locate your resource group and open the VNet blade. In the Overview tab, you can see different information about your VNet, such as resource group, subscription location, and so on.
In settings, we have multiple options that are available for configuration: Address space, Connected Devices, Subnets, DDoS protection, DNS servers, Peering, and Service endpoints. Properties, locks, and automation scripts are available for every resource in Azure and aren't limited only to Azure VNet. Properties have read-only information about your resource, and locks point out if there are any services in dependency to this service. The automation script will generate an ARM template for resource redeployment. Note that this option generates an ARM template for a complete resource group, not only for a specific resource. The automation script can be used for future redeployment, in case we need to replicate resources for a new client or a new environment.
In address space, we can edit an existing address space or add additional ones. There are two restrictions: address spaces can't overlap and you can't change an address space to be smaller than the subnets using that address space. For example, if you created address space 10.1.0.0/16 and subnet 10.1.0.0./16, the address space can't be changed to less than 10.1.0.0/16 unless the subnet is changed first. It's important, how you use an address space; in terms of future VPN connection, you cannot connect Azure VNet to a network (Azure or physical) using the same address space. Adding a new address space can be seen in the following screenshot. Make sure the new address space doesn't overlap with the existing one:
In the subnet blade, you have two options: to change the existing subnet or to add a new one. For both options, you have to use existing address spaces, and subnets can't overlap. An existing subnet can't be changed to use less address space than already in use. For example, if you have an address space of 10.1.0.0/24 and have 200 VMs on the subnet already, then you can't change to anything less than /24, as /25 has only 128 addresses available.
Another thing to note is that you don't have the complete IP range available on your subnet; five IP addresses are reserved for Azure-provided network roles such as DNS or DHCP. Speaking of DHCP, having a custom DHCP solution in Azure is not supported, you have to use an Azure-provided DHCP. This is not the case with DNS; by default, you use the Azure DNS service, but can use a custom solution as well.
To add a new subnet, you need to provide similar information to when you created the default one during VNet deployment, but you have a couple of additional options. Again, you need to provide a name for your subnet and IP address range that must use the existing IP address range of your VNet and must not overlap with other subnets on your VNet. Note that here you get information about the reservation of five IP addresses for Azure networking services. A similar VNet deployment is the service endpoint option, which allows you to add PaaS services to your subnet. You can assign a Network security group to the subnet level and assign Route table.
NSGs are your main tool to control traffic on Azure Vnets, and we'll discuss them in more detail later. Azure routes traffic automatically between all subnets on the same VNet, but you can create custom route tables to override the default options. This can be useful in cases when you have VPN or virtual appliance (third-party firewalls in Azure). An example of adding a new subnet to VNet is shown in the following screenshot:
The DNS blade allows us to add a custom DNS solution to our VNet. As mentioned before, this is Azure-provided by default but you can use your own DNS, either a VM with DNS or public DNS.
If you have a Site2Site connection to your local network, this can be DNS for your local network. If this is the case, I would recommend using a replica of your DNS in Azure. This will make the response faster and DNS available on your Azure VNet in case the VPN connection or your local network is down for some reason. The option to provide custom DNS is shown in the following screenshot. You need to provide the IP address of the DNS server, the public IP in case you choose public DNS, or a private one if you deploy DNS on your VNet:
We had the option to add service endpoints to our VNet during deployment, but we can add them at any time using the service endpoint blade, shown in the following screenshot. As adding these services starts a provisioning process that will set up routing and rules, it can take up to 15 minutes for the process to complete. The service endpoint option is available on at the VNet and subnet levels, so you can enable endpoints either for a complete network or on a single subnet. Using a single subnet gives you more control and the ability to separate the PaaS service from rest of your virtual network:
Peering allows you to connect your VNet to other VNets in order to exchange traffic. This is available only for VNets in a single Azure tenant (but available across subscriptions in that tenant). You need to give a name to the connection and then select the appropriate subscription and virtual network. You have some additional options to define if needed, like if you want traffic forwarding, allowing gateway transit, and use of remote gateways. By default, only traffic coming from one VNet will go to the second VNet. Traffic coming from outside VNets that are connected by peering (coming from a second peer, only one of the VNets is involved in or coming over gateways) will not be forwarded unless you specify these options.
For example, let's say we have three VNets: A, B, and C. A is connected to B, and C is connected to B, but there is no direct connection between A and C. By default, traffic would be allowed for A to B, from B to A, from B to C, and C to B. No traffic would go from A to C or from C to A. If we enable traffic forwarding, traffic from A to C and C to A would go through.
A similar thing goes for virtual gateways. Let's say we have networks A and B and peering between these VNets. VNet A has a virtual gateway and is connected to our on-premises network. By default, traffic would be allowed from A to B, B to A, from the on-premises network to A and from A to on-premises network. No traffic would be allowed from on-premises network to B and from B to on-premises network, unless we allow this traffic using extra options that allow gateway transit and the use of remote gateways.
Another way to achieve this is to create a virtual gateway for each VNet and create a Site2Site connection, the same one that you would use in case you wanted to connect to your on-premises network (we'll discuss this in the hybrid cloud chapter). The big difference between the two approaches is that peering is free and you pay for a virtual gateway. If you want to connect two VNets that are located on different tenants, you need to use a virtual gateway; peering is available only for VNets on the same tenant.
To connect different networks, either VNet to VNet or VNet to local network, IP address spaces/subnets must not overlap. If you have the same subnet for both networks, you won't be able to create this connection as this would create confusion and make routing impossible. It would be impossible to distinguish which device is on which network and where traffic should go. How to connect your VNet to another VNet in your subscription is shown in the following screenshot:
Where we have multiple networks connected either by peering or Site2Site, it's recommended to use route tables. Custom route tables allow us to create and forward traffic in specific cases and define rules concerning where traffic should go in each situation.