One of the recommended azure architectures is a hub and spoke network setup. This architecture consist of the following azure components:
- 1x Hub Virtual Network
- 2x Spoke Virtual Networks
- 1x Azure Firewall
- 2x Route Tables
- 2 Virtual Machines
The reason for this architecture is to help centralize all your shared resources in one central location as much as possible. Also from a management standpoint you can create an azure firewall to route spoke vnets through the hub vnet. In the previous article here we setup this entire hub and spoke network. This article completes the setup in creating an azure firewall to allow azure spoke to spoke communication.
What is an azure firewall
Azure firewall is a fully managed solution offered by azure that gives you the ability to secure and connect azure resources to the internet, internally, and on prem networks. The azure firewall offers three skus which are standard, premium, and basic.
The standard azure firewall supports layer 3 through layer 7 filtering that gets its threat intelligence directly from Microsoft Cyber Security. This helps ensure that your always up to date on the latest threats that Microsoft sees across the world and not only your network.
We will be focusing on the standard version, which for our lab does not really matter the features that it support or does not support. Each sku has a different pricing level and options that it offers.
The same techniques applied in this article can be utilized with the other skus as well.
Deploying an azure firewall using terraform
In a hub and spoke network that needs spoke to spoke communication, the azure firewall will need to sit somewhere each network can communicate with. In our last article we created 3 vnets. The azure firewall will sit in the hub vnet.
The full terraform code can be found in my github repository here. The firewall.tf shows the code needed to deploy the azure firewall portion of the network. When deploying a azure firewall you need the following basic requirements:
- Azure resource group to deploy it to
- Virtual Network
- A subnet created that has to be called “AzureFirewallSubnet”
- An outside IP address that gets attached to the firewall.
resource "azurerm_subnet" "firewall" {
name = "AzureFirewallSubnet"
resource_group_name = azurerm_resource_group.main.name
virtual_network_name = azurerm_virtual_network.hubnetwork.name
address_prefixes = ["10.2.2.0/24"]
}
resource "azurerm_public_ip" "firewall" {
name = "testpip"
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
allocation_method = "Static"
sku = "Standard"
}
resource "azurerm_firewall" "firewall" {
name = "testfirewall"
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
sku_name = "AZFW_VNet"
sku_tier = "Standard"
ip_configuration {
name = "configuration"
subnet_id = azurerm_subnet.firewall.id
public_ip_address_id = azurerm_public_ip.firewall.id
}
}This configuration will deploy the firewall without any configuration. Next we will need to add a route collection to allow the azure firewall to route the spoke vnets through the hub.
Creating azure user defined route tables
Now that we have the azure firewall created we need to have the spoke vnets send traffic destined to the other network to the hub network. This is done by creating azure route tables. Subnets that are not associated with a route table become associated with a default route table created by azure to allow various networking task.
Go to the azure portal and search for “route table” and create a route table in the region your resource group and vnet lives in. Then add a route with a destination ip of the other spoke vnet and the next hop being the azure firewall ip address to route your transitive traffic. You want to do this for both spoke vnets.
Conclusion
That is all that’s needed to allow and azure firewall to route spoke vnets using the hub vnet. This network architecture makes it a lot more simple to manage how your networks communication with each other because:
- The traffic can be centrally managed at the hub vnet
- No complicated peering connections across multiple vnets
- Azure firewall can be utilized to secure an analyze traffic going out to the internet
