This blog serves to provide a quick high-level overview of what’s required to build out a basic Azure network infrastructure.
VIRTUAL NETWORK ADDRESS SPACE AND SUBNETS
Before any Azure VM’s can be deployed, a virtual network (VNET) must first be implemented within your Azure tenant. During the VNET provisioning process, you will also be required to specify a resource group for the VNET to exist in. Resource groups are logical containers for Azure objects.
When deciding on your Azure VNET, keep in mind that this VNET must be unique and cannot overlap with existing network ranges. If you have an on-prem network of 10.10.0.0/24 for example, your Azure VNET address space can be 10.20.0.0/16, which ensures that each virtual subnet you provision within Azure remains unique and routable.
Azure subnets are carved out of your configured VNET address space. Utilizing a /16 address space will provide you with a large enough range to accommodate your design requirements. From the 10.20.0.0/16 address space example above, additional subnets of 10.20.1.0/24, 10.20.2.0/24, 10.20.3.0/24 and so on, can be provisioned.
The subnets provide network segmentation like that of an on-prem infrastructure utilizing VLAN’s. VM’s can be deployed within each subnet based on their tier (i.e. front-end web server, application, database) and then segmented and secured using network security groups.
By default, subnets within a VNET have complete access to communicate with one another. To restrict access between subnets, a network security group (NSG) must be deployed and associated to each subnet where access control is needed (apply directly to VM interface for per VM access control). NSG’s can also be used to restrict or limit access between Azure subnets and On-Prem networks.
ON-PREM TO AZURE CONNECTIVITY
On-prem to Azure connectivity can be quickly achieved by deploying Azure’s virtual network gateway (VNG). The VNG acts as a public gateway for site-to-site connectivity using IPSEC VPN tunneling. It’s also important to note that the VNG is strictly for site connectivity and does not provide any security features.
For added security, it is recommended that a virtual security appliance / firewall be deployed in Azure and used as the VPN gateway instead. A virtual FortiGate for example would provide site-to-site IPSEC VPN connectivity as well as the usual UTM features like AV, IPS, web and application filtering.
When a virtual security appliance is used to secure the perimeter of the Azure network, a user defined route (UDR) must also be implemented. The UDR allows Azure traffic to be routed through the virtual security appliance.
