Multi Hub and Spoke Topology using Azure Firewalls

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Introduction and Purpose: 

 

The fundamental model for Network Connectivity in Azure is Hub and Spoke. As compared to Azure Virtual WAN, the end user has more granular control of the routing and the ability to deploy shared resources on the Hub to be consumed by the Virtual Network (VNet) peers attached to it (Spokes). However, the existing official documentation to attain a Multi Hub and Spoke topology refers to models that include dynamic routing in the Hub using Azure Route Server and Network Virtual Appliances (NVA) which requires a level of complexity as a Network Administrator including the use of protocols like Border Gateway Protocol (BGP) and Virtual extensible Local Area Network (VxLAN). The official documentation has left out a simpler way to attain this Inter Hub connectivity with static routes.   

 

This article describes a simple Inter Hub and Spoke topology and walks through its implementation.  

 

Diagram:

 

Mauricio_Rojas_0-1683078041816.png

Baseline Architecture for Multi  Hub and Spoke

 

The main purpose of the Azure Firewall, besides securing and inspecting traffic, is routing. The Azure Firewall is a managed resource that will have the routes automatically created by the platform (system routes) to the local Spokes, the Hub, and the on-premises prefixes learned by its local Virtual Network Gateway. When you place an NVA on the Hub and query the effective routes, you would find a resultant route table that is similar to what you would find within the Azure Firewall. 

 

Since this is a static routing architecture, the shortest path to another Hub can be accomplished using Global VNet peering between the Hubs. That way, the Hubs know about each other, and each local Firewall will contain the route table of each directly connected Hub. However, only the local Hubs know about their local Spokes. Additionally, these Hubs can be in the same region or different region.  

 

Routing on the Firewall Subnets:

 

On the other hand, the local Firewall needs to know how to reach the other Spokes, so we must place User Defined Routes (UDRs) in the Firewall subnet. In order to achieve this, the Firewall requires a default route of any type to be able to add more specific routes towards Spoke 4 and Spoke 5. A concrete example on CLI will look like this: 

 

 

maroja@Azure:~$ az network route-table route list -g $rg --route-table-name $rt -o table
AddressPrefix    HasBgpOverride    Name            NextHopIpAddress    NextHopType       ProvisioningState    ResourceGroup
---------------  ----------------  --------------  ------------------  ----------------  -------------------  ----------------
10.1.0.0/16      False             to-Spoke-1-FW1  10.0.1.4            VirtualAppliance  Succeeded            spoke-2-rg-exr-2
10.2.0.0/16      False             to-Spoke-2-FW1  10.0.1.4            VirtualAppliance  Succeeded            spoke-2-rg-exr-2
0.0.0.0/0        False             default                             Internet          Succeeded            spoke-2-rg-exr-2

maroja@Azure:~$ az network route-table route list -g $rg --route-table-name $rt -o table
AddressPrefix    HasBgpOverride    Name        NextHopIpAddress    NextHopType       ProvisioningState    ResourceGroup
---------------  ----------------  ----------  ------------------  ----------------  -------------------  ---------------
10.202.0.0/16    False             to-spoke-4  10.200.1.4          VirtualAppliance  Succeeded            Whathehack
10.203.0.0/16    False             to-spoke-5  10.200.1.4          VirtualAppliance  Succeeded            Whathehack
0.0.0.0/0        False             default                         Internet          Succeeded            Whathehack

 

 

Routing on the spokes:

 

The benefit of implementing this topology is that with traffic going from one Hub to another, we can reach the next hop that is directly connected via the global peering. 

 

As illustrated in the diagram, it is better to place a UDR in the subnets of the Spokes that have a 0/0 with Next Hop of the Local Firewall. This is because it locks in a single exit point which next hop is the local firewall, and also to reduce the risk of asymmetric routing should it learn more specific prefixes from your on-premises environment that might cause the traffic to bypass the firewall. To understand this further, I encourage the reader to explore the following resources:  

 

https://blog.cloudtrooper.net/2020/11/28/dont-let-your-azure-routes-bite-you/ 

 

 

maroja@Azure:~$ az network nic show-effective-route-table -g $rg -n $nic -o table
Source    State    Address Prefix    Next Hop Type      Next Hop IP
--------  -------  ----------------  -----------------  -------------
Default   Active   10.1.0.0/16       VnetLocal
Default   Active   10.0.0.0/16       VNetPeering
Default   Invalid  0.0.0.0/0         Internet
User      Active   0.0.0.0/0         VirtualAppliance   10.0.1.4

 

 

Conclusion:  

 

The benefit of implementing this topology is that with traffic going from one Hub to another, we can reach the next hop that is directly connected via the global peering.  

 

You can also achieve this type of connectivity by substituting the Azure Firewall with a Network Virtual Appliance of your choice. In order to achieve this implementation, additional configuration within the NVA would be needed, therefore it is intended for future content.  If you wish to explore that implementation, please comment. 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.