Hub and spoke network architectures are an increasingly adopted topology in Azure, and I tend to recommend to customers who are new to Azure, are above a certain size (medium – enterprise) and require hybrid connectivity to on-premises or other clouds.
Advantages:
- Cost effective for hybrid connectivity, being able to connect multiple VNets using one Virtual Network Gateway (VPN or ExpressRoute)
- Cost effective if using Azure Firewall and Bastion as these can be shared across all VNets
- Better security by segregating different workloads and whole applications into dedicated VNets
- Scalable – once configured, adding new VNets and workloads is relatively simple
Disadvantages
- Azure Firewall (and third-party alternatives) can be costly
- Complex to deploy, configure and manage (particularly if using third party firewalls)
The basis of the topology is a central “hub” VNet is deployed with several shared services deployed within (e.g. Virtual Network Gateway, Azure Firewall, Azure Bastion and Domain Controllers). Peered “spoke” VNets are then deployed with dedicated workloads in.
When designing this topology and deciding which workloads go where, it’s useful to think in terms of groups of servers or applications. For example, if a company has an application “App A” which has a front-end IIS server, a backend SQL server and reporting server, I would deploy a VNet for “App A” (VNet-A) with dedicated subnets for IIS, SQL and reporting respectively.
Similarly, if they had an Azure Virtual Desktop (AVD) deployment with FSLogix profiles and a Windows file server, I would deploy a second VNet (VNet-B) with a subnet for the FSLogix profiles (generally an Azure files storage account with private link), one for the AVD session hosts and then one for the Windows file server.
When designing a VNet with subnets it is best-practice to deploy a network security group (NSG) on each subnet (and overwriting the default rules – but that is a topic for another blog post). Traffic that travels in the same VNet between subnets will then be subject to the rules in these NSGs.
Should there be a requirement for VNet-B to communicate with VNet-A then a Firewall is required in the “hub” VNet.
Is a Firewall required in the hub VNet?
I would always recommend deploying an Azure Firewall if budget allows it (they can be expensive) as it forces all traffic between VNets (and from the VNet Gateway) to be filtered through a security appliance. It is also allows for services to be presented publicly through Azure firewall and provides (and filters) outbound internet access to all VNets.
If you do not deploy a Firewall (or alternative network virtual appliance) in the Hub VNet then spoke-spoke connectivity is not possible. Spoke – on-premises via the VNet Gateway is still possible.
Deploying a Hub VNet with GatewaySubnet and Firewall
In this example, I will show you how to configure a simple hub and spoke topology with an Azure Firewall and VNet Gateway connected to two spokes.
First create a VNet, I’ve created one using the 10.3.0.0/16 address space and two subnets as below:
To deploy an Azure Firewall, you need to have a subnet called AzureFirewallSubnet. Similarly, all Virtual Network Gateways need to be deployed to a subnet called GatewaySubnet.
NOTE: If deploying an Azure Firewall as part of the New Virtual Network Wizard, remove the AzureFirewallSubnet subnet from the IP tab as it will create you one automatically as part of the Azure Firewall deployment.
In the Security tab click Enable Firewall, assign name, address space and Public IP address.
Once deployed, take note of the private IP address of the Azure Firewall as we’ll need to route all traffic to this:
I have also created two “spoke” VNets with the following subnets:
AC-VNET-01
AC-VNET-02
Connecting the Spoke VNets to the Hub VNet
To implement the hub and spoke topology, the next step is to configure peering between the spoke VNets and the hub VNet. To do this, go to the hub VNet and choose ‘Peerings’ from the side bar. Click Add.
Give a name to each peering (note two peerings need to be made, one in each direction):
Ensure ‘Allow’ Traffic to remote network and from remote network is enabled on both peerings. If using a VPN or ExpressRoute Gateway in the hub VNet, ensure that ‘Use this virtual network’s gateway or route server’ is enabled on the Hub-Spoke peering.
Repeat the process for every spoke VNet required, in my example I have two VNets now peered to my hub:
Route Tables
Route tables then need to be created and attached to each subnet to force traffic through the Azure firewall. You can reuse the same route table on each subnet, but I recommend creating a single route table for each subnet in case routing requirements change in the future. Similarly, it is best practice to have a network security group on each subnet.
Once each route table is deployed, create a single route on each:
This is a default route (0.0.0.0/0), meaning it will send ALL TRAFFIC to the Azure Firewall. Ensure ‘Virtual Appliance’ is selected as the next hop type and the next hop IP address is the Azure Firewall IP address noted previously.
Once this route has been added to each route table (if creating one per subnet), then the next step is to associate the route tables with the subnets.
NOTE: Once you hit OK on the route table association, all traffic for this subnet will immediately start to route through the Azure firewall. If accessing a VM in one of these subnets through a public IP address attached to the VM you will lose access as the Azure Firewall will need to be configured to provide connectivity instead.
An additional step if using an ExpressRoute or VPN Gateway (which in this topology must be in the hub VNet) is to add another route table with the same default route (0.0.0.0/0 to the Azure Firewall private IP) to the GatewaySubnet in the hub VNet. This is because all traffic coming from the gateway (on-premises or other cloud traffic) also needs to be routed to the firewall.
Azure Firewall rule design and configuration is a topic for a different blog post, but here are the rules I’ve created in my example:
This allows all traffic between AC-VNET-01 and AC-VNET-02. Note also that similar rules need to be added to the Network Security Groups on each subnet (if the NSG is locked down – by default NSGs allow ALL private traffic).
I’ve also created a DNAT rule for RDP to a server in AC-VNET-01 (through the Azure Firewall Public IP as illustrated in the diagram above).
NOTE: The ‘Destination’ is the public IP address to the Azure Firewall.
Check the routing is working correctly
Once the route tables are in place and firewall rules are written then you can check routing is working correctly by:
- RDP to a server through the Azure Firewall (with a DNAT rule like above)
- Ping/RDP between servers in different spokes (Ping needs to be enabled on each server for this to work)
- Review Azure Firewall logs to see traffic being allowed through
Final thoughts
VNet peering is supported globally across all Azure regions, so you are not restricted to having hub or spoke VNets in the same region (in my example above the hub VNet and AC-VNET-01 are in North Europe, AC-VNET-02 is in UK South).
If you are testing this and want to reduce costs incurred with Azure Firewall, you can do so by deallocating/allocating the Firewall (stopping and starting) using Azure Powershell following the instructions below: https://docs.microsoft.com/en-us/powershell/module/az.network/set-azfirewall?view=azps-7.0.0#4–deallocate-and-allocate-the-firewall
If you’re interested in hub + spoke topology, you can additionally read about similar technologies; Azure Virtual WAN (hub + spoke as a service and more) and the recently released Virtual Network Manager (automating hub + spoke topology configuration) at the below links:
https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-about