AWS has recently launched Transit Gateway service that natively connects two or more virtual private cloud (VPC) to connect common gateway service to connect to on-premise. However, these connections are often unmanaged in terms of policies and rules that needs to be applied centrally before connections are made. Example using security groups to allow/block inbound/outbound traffic. This is not central configuration but is done at individual AWS accounts.
Azure is no different. You would connect multiple Virtual networks to Express Route directly or via Hub virtual network to on-premise network. What on-premise network access is allowed or blocked is not managed at Express route configuration or at Hub virtual network but is managed at individual Virtual network’s Inbound / outbound Network Security Group (NSG) configurations.
Let us see an example how it might look below –
Question now is how do implement AWS Transit Gateway like feature in Azure? Answer is combination of VNET peerings, Azure firewall and route tables, where traffic is allowed to pass-through only if it is allowed and managed centrally. Let us see the design.
In the target design, we have deployed Azure firewall in the HUB Virtual network, configured UDR on each source network (VNET 1 and VNET 2) to use Azure Firewall Private IP address as target. Once done, Azure Firewall rules are used to allow/deny traffic between approved endpoints on knows Ports.
Let us see the configuration –
Virtual Network – VNET 1 – 192.168.0.0/24
Virtual Network – VNET 2 – 172.16.0.0/24
Virtual Network – HUB – 10.0.0.0/24
VNET Peerings –
VNET 1 <–> HUB (Allows gateway transit and forwarded traffic)
VNET 2 <–> HUB (Allows gateway transit and forwarded traffic)
Azure Firewall configuration
Azure Firewall has 3 type of rules – 1. NAT Rules 2. Network Rules 3. Application rules.
Go to network rules and create rules as shown below –
This complete the Azure Firewall configuration, pretty simple. Now create route tables for each Virtual Network like shown below and attach them to each subnet in the Virtual Network
Now let us validate if route tables have taken into effect. Go to the NIC on of the Virtual machine that is using the subnet where route table is applied –
Route table of VM in VNET 2 is not shown here but the configuration is similar. Route tables are configured to route traffic to Azure Firewall IP (10.0.0.4) for VMs on remote Virtual Network
Now final testing –
We have seen that VNET 1 and VNET 2 are not peered to each other directly but instead are peered to HUB VNET which has Azure Firewall deployed, and UDRs in the VNET 1 & 2 are pointing to each other via Azure FW IP address.
Let us change the Azure Firewall configuration to deny the traffic (just one change and see what happens)