Any major cloud provider will have a strong Networking offering for connecting and securing resources. It is an essential consideration in any cloud deployment, whether using IaaS, PaaS or SaaS services. Depending on the complexity or type of services being used, the administrator’s involvement will range from a general awareness through to a varying amount of planning, deployment and maintenance.
The networking products and services in Azure are vast and one could write a book on the subject – indeed many have. This is a single post so we will focus specifically on a core Azure networking service, the Virtual Network (VNet) and components and services that are specifically for the VNet.
Networking in the cloud is wonderous. Software defined networking abstracts what would-be managed switches, cables and network appliances and allows you to build them with the typing of a few commands or a few clicks of a mouse. Amazing!
Virtual Network (VNet)
The most prevalent part of most Azure architectures is the VNet. Typically deployed to a region where your users or customers are, they provide a base for many Azure services including VMs, Kubernetes clusters, private endpoints for services such as storage accounts, databases and many more. The VNet determines the available IP addresses for your own private network in the cloud. By using different workloads and services within the VNet, you can surface privately and publicly accessible resources to serve your users. A Virtual Network creates a boundary in which you can secure and segregate workloads to suit your requirements.
When a VNet is created, you need to specify at least one RFC1918 private IP range (10.x.x.x / 172.16.x.x / 192.168.x.x) or you can use a public in CIDR format. Whether the address range(s) you create are public or private, the address range is still only reachable only from within the virtual network, from peered VNets, or any on-premises networks that you’ve connected to the virtual network via a site-to-site VPN for example.
You can use IPV6 ranges as well but only in a dual stack setup. You have to have an IPv4 on the Virtual Network and subnets as well as IPv6. The subnets for IPv6 must be exactly /64 in size.
We shall walk through the products and services you may use within the VNet to maximise the benefit.
Subnets
For the VNet to be usable, you will need to create at least one subnet for each CIDR range you specified when going through the creation process. A subnet can cover the VNet CIDR length or be segregated into multiple subnets . You do not need to occupy the whole VNet range if not required, leaving room for new subnets at a later date.
There are some reserved subnet names that are reserved for special services. These include GatewaySubnet, BastionSubnet & FirewallSubnet which are responsible for VPN/ExpressRoute connectivity, VM secure remote access and for hosting the Azure Firewall service respectively. Some will have a minimum or recommended size so be sure to read the documentation before deploying.
Security
Security is a huge part of networking, whether in the cloud or on-premises. So, the provision of security apparatus for virtual networks is comprehensive. We will walk through some of the key security components now.
Firstly, the primary service for securing Azure VNets are Network Security Groups. NSGs contain a set of rules, passed in order of priority, that either allow or block inbound and outbound traffic at OSI layers 3 and 4 (IP address, port and protocol). These Network Security Groups can be assigned to a subnet. The NSG can be assigned to more than one subnet if the rules required for those subnets are the same. You can group VM NICs into an Application Security Groups (ASGs) which simplifies the creation and management of rules for a set of resources in the subnet. You can use service tags to allow or deny whole services within Azure, such as Storage, Backup or Logic Apps, further aiding ease of management.
NSGs can be assigned to a VM’s Network interface (NIC) but it is recommended to apply to the subnet where possible. If an NSG is assigned to the NIC and another to the subnet, the rules will be processed NIC first then subnet for outbound traffic, or Subnet then NIC for inbound. For example, if port 80 inbound is allowed on the NSG assigned to the subnet but blocked on the NSG assigned to the NIC, traffic on port 80 to that host will be blocked but allowed on other hosts who do not have an NSG blocking port 80 assigned to it’s NIC.
NSGs are powerful but are limited to layer 4 filtering. For looking at layer 7, at URLs and web traffic, there is Azure Firewall. Azure Firewall is not only more functional, but it also sits on a subnet of its own and can provide protection for subnets on the same VNet, on other VNets via peering, and for On Premises via a VPN/ExpressRoute connection. It can provide inbound and outbound firewall rules.
Azure Firewall is available in Basic, Standard and Premium SKUs, be sure to check the differences before deploying as they will have varying maximum throughput and features such as web content filtering not available on the Basic SKU and TLS inspection only available on the Premium SKU. Azure Firewall is a first-party Network Virtual Appliance (NVA) but there are other 3rd party NVAs available from the Azure Marketplace. Some allow you to bring an existing licence (BYOL) over so check out those options too.
DDos Protection is running on Azure as standard but there is a paid for service which allows for more features. You can purchase as Network Protection which covers VNets in a subscription, or you can buy per IP address. If you go for Network Protection you get additional features such as DDos rapid response support and cost of data transfer and scale out guarantee (Microsoft reimburses you the cloud consumption costs incurred by the attack).
For web application level DDos protection, you can activate DDos protection on the Azure Web Application Firewall (WAF) which in turn can be used with Application Gateway or Azure Front Door which are both described below.
Services to allow public access to your applications
Whilst it is possible to access a web application via a Public IP address assigned to a VM NIC, this is not considered best practice from a security standpoint, nor will it allow for load balancing or serving workloads that are not on a VM such as containerised services. For best practice, there are 4 main ways of managing inbound access each with their own use case.
First, we have Azure Load balancer. This is an OSI level 4 load balancer which can be set to load balance between different Availability Groups in a given region or across multiple Azure regions with the Global tier. It is a high performance, highly available service options to point to NICs on a VNet or you can specify IP addresses when using the Standard load balancer (the basic SKU has no SLA and isn’t recommended for critical workloads).
If you require regional load balancing but would prefer to work at OSI layer 7, so you can do things like route to different nodes in the server pool based on URL path or domain or want to take the SSL handshake burden off the nodes, then Azure Application Gateway is the service you need. With Azure App Gateway you can activate the Web Application Firewall (WAF) which is the Azure Firewall running within the Gateway. Additionally, in the WAF configuration you can activate DDos protection.
For globally distributed apps, content and websites, you could use Azure Front Door. Whilst not just for resources contained within a VNet, this is a popular use case. Microsoft also describes Front Door as a Content Delivery Network (CDN) because it can route users to the closest region of your app/website. Working at layer 7 it has many features found in Azure Application Gateway such as routing based on URL and having the ability run WAF on Front Door.
Lastly, there is Azure Traffic Manager which again doesn’t have to point to an endpoint contained within a VNet but it is certainly a use case. Traffic Manager is a DNS based load balancer that can work on a global scale. It monitors the endpoints for health like a usual load balancer but this one works by configuring a routing method including Priority which returns the DNS host(s) for a primary service endpoint with backup endpoints if the primary is offline, Performance which will return hosts with the lowest network latency, Weighted is for distributing traffic based on an endpoint’s configured weighting, Geographic will direct users to endpoints based on location which is good for compliance requirements, Multivalve returns all healthy endpoints and allows the client browser/app to select one and finally Subnet routes an end user’s IP address to a specific endpoint. It is worth noting that app traffic does not travel through the Traffic Manager, but Traffic manager serves the client with DNS responses based on the routing method selected from the list above.
Services to support VNet configurations
Azure NAT Gateway is used to give predictable results to outbound traffic for any subnets assigned to it. When setting up the service, you must create or assign a public IP address or an IP prefix to the service. The result of deploying NAT Gateway is you will know the IP address(es) that will be used for external traffic, so you can whitelist services or just know what IP will connect to to make connectivity. You use an IP prefix when your number of systems needing to gain outside access will cause SNAT port exhaustion. A single IP address provides 64,512 ephemeral ports to NAT gateway for connecting outbound. Azure NAT Gateway doesn’t require any custom routing – an assigned subnet is automatically updated with the appropriate routing.
For DNS within a subnet, Azure provides a free DNS service which will register any hostnames in a VNet automatically and take care of everything via the Azure global resolver IP address, 168.63.129.16. There is also Azure Private DNS which allows you to create private DNS zones so you can register DNS entries for multiple VNets for virtual machines, virtual machine scale sets and any other services based on VMs. A private DNS zone allows custom domains instead of the Azure standard ones such as xxx.internal.cloudapp.net. If you have specific needs, you could use your own DNS server solution.
Azure also has public DNS service where you can manage domain names in Azure and all your A, TXT, CNAME, MX etc. record types. You can get your DNS records managed in Azure either by setting up the DNS zone and pointing your domain name to Azure’s nameservers, or you can buy a new domain name in Azure if using Azure App Service.
Azure subnets have a set of default routes which may not suit the use case. You cannot delete the default routes, but you can override them with user defined routes. You can create a route table and assign it to a subnet or multiple subnets. For example, by default there is a 0.0.0.0/0 route that routes all non-internal traffic to the Internet. But say you want to route traffic via Azure Firewall, then a custom route which sets next hop to the NVA would suit this requirement.
If you need to connect two or more Vnets, then the most straightforward approach is to use Azure virtual network peering. Peering is very versatile, with the ability to connect two VNets in the same region or in different regions using global virtual network peering. All traffic travels securely via Microsoft’s backbone infrastructure. With the correct credentials, VNet peering can to VNets on different subscriptions, even different tenants.
To connect two virtual networks, you must ensure each network’s IP range doesn’t overlap, if it does, you must make amendments to one before setting up peering. A common use case for peering is creating a hub and spoke architecture, where one VNet is the hub, containing resources such VPN gateway, Azure Bastion and firewall and the spoke networks connect via the hub to provide connectivity to on premises clients or out to the Internet via the firewall.
Azure Bastion is a great way to securely access to your Windows (via RDP) and Linux VMs (via SSH) without exposing the VMs RDP port/ SSH port to the Internet or having to go via a VPN. Azure Bastion can replace the traditional Jump Box server by allowing secure login via the Azure portal or by creating a Bastion Shareable Link. Bastion works particularly well for administrators, allowing to remote access of individual virtual machines by RDP or SSH.
Secure connectivity to on prem servers and clients and remote workers
The most popular secure connectivity method is the VPN. There are two types of VPN in Azure: site-to-site and point-to-site. One is for connectivity to a whole remote network, and one is for individual client devices to connect to the Azure network. Both connect via a VPN gateway, which runs from a special subnet called Gateway Subnet. There are various SKUs for Azure VPN depending on if you require the VPN to be zone redundant and how much performance you require.
For a site-to-site VPN there are 4 components – a VNet with a subnet called GatewaySubnet. The subnet should be /27 or larger. If you are managing multiple VNets or even if you are preparing for changes later, it may be worth considering this VNet/subnet to be in the hub of a hub and spoke network for ease of management and better security. The main component is the VPN gateway which also provides the point-to-site VPN should you need users to access your Azure resources directly from their devices when, for example working from home. When creating the VPN Gateway, that is where you pick the SKU based on requirements. For each site you are connecting to, you will need to create a local network gateway. A local network gateway is a representation of the remote site. When creating, you will specify the public IP address and the address spaces on the remote LAN. This is what creates the routing to those ranges. Be sure not to overlap remote and Azure address ranges where there needs to be communication. Last step is creating a VPN connection where you configure encryption and security parameters to match your on-premises device configuration. You should ensure your IPSEC and IKEv2 settings give your organisation an acceptable level of encryption as the VPN tunnel will traverse the Internet.
The VPN gateway runs 2 VPN servers, and as default one is active and one is a standby for planned maintenance or should something fail (active-standby). You can however run active-active for more availability. For this configuration, you also need two public IP addresses, one per gateway VM. For maximum availability, you can have 2ll connections each with its own router/appliance at your premises, both connected to both Azure VPN gateway VMs.
Point-to-site connectivity can be to Windows, Mac or Linux devices, using OpenVPN, SSTP or IKEv2, depending on your operating system. Authentication can be done via certificate, Entra ID or an Active Directory Domain Server (using RADIUS).
ExpressRoute is an alternative to VPN where company or regulatory policies dictate no traffic can traverse the public Internet, regardless of encryption. It also allows more predictable results because of the fewer hops required. The connectivity varies from any-to-any (IPVPN) network, a point-to-point Ethernet connection, through a virtual cross-connection via an Ethernet exchange or ExpressRoute Direct. All will have various costs associated and most will require a 3rd party for the provision of the circuit. ExpressRoute connections are highly available and supports bandwidths from 50Mbs to 10Gbs. There are options to connect to a region and just use any resources within that region’s geopolitical area, or globally using ExpressRoute Premium. For cost effectiveness, you can opt to use for resources located in only one region using the ExpressRoute Local SKU which is limited to a single region (not the whole geopolitical area) and includes data egress at no extra cost. ExpressRoute can be used to connect to Azure services or Microsoft 365 services.
To simplify the rollout of connectivity solutions within Azure, you can use Azure Virtual WAN. Using Azure Virtual WAN, you can deploy and manage services from a single interface. Services available include site-to-site and point-to-site VPNs, ExpressRoute connections, interbranch connectivity (via connectivity automation from Virtual WAN Partner devices such as SD-WAN or VPN CPE), routing and Azure Firewall. For just using site-to-site VPN only, there is a basic SKU, for any other services the Standard SKU must be used when setting up Azure Virtual WAN.
Azure Virtual WAN is deployed as a hub-and-spoke architecture. Multiple Azure Virtual WAN deployments can be connected via hub-to-hub connectivity.
Monitoring and diagnostics
There are a multitude of solutions for monitoring and performing troubleshooting tasks for Azure networking. As is the case for most Azure services, Azure Monitor plays a big part in diagnostics and monitoring of the Networking elements of your cloud architecture. From within the Azure Monitor there is a Networks link in the Insights section of the navigation. Here we will look at the various tools available.
The first few tabs in Monitor > Networks are visualisations and summaries of various networking services. On the Health and Metrics tab you can see various services such as Bastions, Virtual Networks, Network Interfaces etc. in a visual form, to quickly see if any of the services are in a degraded or unavailable state. Connectivity is a visualisation of any Connection Monitor Tests created within the Diagnostics Toolkit section. Traffic is the 3rd tab, which is a graphical representation of NSGs that have been configured on an NSG flow log. You also get Traffic Analytics on this view.
The Diagnostic Toolkit menu links to various components contained within Network Watcher, which is a collection of services that help with network and connectivity troubleshooting as well as drive many of the Monitor views discussed previously. Let’s look at each service.
Packet Capture – A popular tool in network engineering, this Azure version provides packet capture for the VMs you specify. By analysing traffic at the packet level, you can understand what data is being sent back and forth from VMs to other resources.
VPN Troubleshoot – Allows you to test for problems with your VPN gateways or connection.
Connection Troubleshoot – This will check TCP connectivity between a VM and another VM, fully qualified domain name (FQDN), URI, or IP address.
Next hop – This feature is a sanity check to ensure routing for a given host is set up correctly. You choose a VM and specific NIC and you can see if the next hop will be Internet, VNet local, VNet peering, Virtual Network Appliance, Virtual Network Gateway or none. It will also inform you if a system or user defined route determined the resulting next hop.
IP flow verify – This will allow us to test if a TCP/UDP connection can be established between a VM’s NIC and a remote host. It uses 5 tuple information (source/destination IP, source/destination port and protocol) which will return if the selected criteria would have passed or been blocked and by what NSG rule or by Azure Virtual Network Manager admin rule.
Effective security rules – With this feature you specify a VM and which NIC on the VM you want to test. It will then calculate all NSG rules applied to the NIC or subnet for inbound and outbound traffic. From that you will be able to ascertain if a given port on a given source/destination IP would be allowed or blocked.
NSG & VNet Flow Logs – You can use these logs to provide visibility about what traffic is being sent from and to your resources. You can use the data to diagnose specific concerns or pipe to a SIEM solution such as Microsoft Sentinel.
Network Topology – This is a tool that will generate a visual representation of your network layout. From VNets and subnets down to the resources within them, you can see what your networking topology looks like and the relationship between resources.
Conclusion
This was an overview of the Azure Virtual Network and associated products and services. If you plan on using any Azure networking components, please check official documentation to ensure best practices and any product updates.
If you want to become highly competent in Azure networking, including but not limited to virtual networks, then following the Microsoft AZ-700 exam learning path is a great place to start. If after digesting the material on MS Learn and other resources such as an online course, you could choose to sit the the Exam. If you pass, you will become a Microsoft Certified: Azure Network Engineer Associate.
November 15, 2023 — 7:16 pm
Very well written and explained ! Great job.