Hub-n-Spoke vs Forced Tunneling

Hub-n-Spoke Topology

Date: 2022-11-18
Author: Simon Jackson

Many of you already know what a Hub-n-Spoke network is; but for those who don't here goes.

Microsoft publishes a series of Reference Architectures. These form as part of their wider onboarding material made available for customers/partners undergoing a cloud adoption journey.

Customers willing to read the Microsoft Cloud Adoption Framework (CAF) quickly learn that there are several proven-network-topologies that work.

Google Cloud, AWS, Oracle and Alibaba all have their own version of this CAF material too.

The most common reference architecture found in SMEs is the Enterprise Scale Landing Zones (ESLZ) called Hub-n-Spoke. The name comes from a simple concept of a `wheel of networks` (VNETs), all peered together in the center. The central VNET is referred to as the `HUB`.

Enterpise-Scale-Landing-Zones →

I'm writing this blog; as I experienced configuration issues when building my first customer Landing Zone earlier on this year. Keep reading and you may be able to dissect the problems I had, to overcome them before reaching a near-production state.

Below, is my interpretation, of some of the typical network services found within an Azure landing zone. In trying to keep the diagram relevant to just the network components, to aid quickly reading and understanding of this blog.

Do you know what a User Defined Route (UDR) is yet? If not, see here before proceeding.

VNET Peering

Peering VNETs together is a form of BGP routing; with just a small number of check boxes to enable/disable.

Having worked with IP networking equipment for a long time; I'm now finding familiarities with `what we configure in the console` vs `what would traditionally happen on site-to-site running VTIs with BGP`. Microsoft's documentation does cover it all here.

For ease of discussion, i'm only referencing the main VNETs.
I wrote down exactly how i intended to configure my vnet peering.

Before moving away from VNET Peering. Consider capturing the HUB VNET IDs, and then introducing a deny Azure Policy, preventing peerings to be created within your organisation, that do not include the HUB IDs.

Default Route Tables

The VNETs all have a Default Route Table, managed by Microsoft, and assigned to each Subnet you create, by default. The default route-table looks as follows:

Effective Routes: no UDR, single VNET

Effective Routes: Empty UDR, Route Propagation enabled, VNET Peered (1a above)

BGP Reflection:
When VNET peering with the network's hub, BGP reflection comes into play.

Explanation:
BGP reflection involves the re-advertisement of routes received by the hub, from the new peered-network, advertised out to all other peered-networks.
Any User Defined Route (UDR) with propagation enabled will receive these new advertised-routes (reflected) within 15-20 seconds of first establishing a connection.

Hassle Free:
If you haven't intended to use propagation, there's no need to worry. The default internet route in the forced-tunnelling scenario, described in more detail below, will incorporate all peered networks.

Concept: Forced Tunnelling

For anyone who has dealt these Firewall appliances in the past, that operate separately to the network routers (or layer 3 switches); you might be familiar with this concept of forcing all traffic to the firewall, by routing the traffic'.

... "just go down this tunnel over here"...

This is achieved quite simply using "User Defined Routes".

User Defined Route Tables

SPOKE UDRs:

Each spoke VNET will need a single UDR, that will route all traffic to the hub firewall:

This UDR needs to be associated with ALL subnets.

First complication to consider is the fact a smaller CIDR will override a larger CIDR. So we cannot simply add one `0.0.0.0/0` route to govern all traffic. It's a little more complex. We have to consider each peered-network CIDR, and match the subnet-mask.

Spoke Routes To Add:

0.0.0.0/0 > Azure Firewall IP (assume AzureFirewallSubnet .4 IP)

HUB UDRs:

The HUB of the network is MUCH more complex. In my opinion, the following subnets, need their own UDRs:

BastionSubnet
GatewaySubnet (Vnet Gateway / vWAN Gateway or Express-Route Gateway)
AzureFirewallSubnet (or your own virtual firewall appliance)
Application Gateway (or your own network load balancer)
VM Scale-Sets (if you host them in a shared-environment, that are environment/spoke agnostic)
Jumpbox/DevBox Subnet

WORDS OF WARNING: Asymmetric traffic is not logged by the Azure Firewall!

Asymmetric routing happens when incoming and outgoing traffic follow different paths, bypassing the firewall's stateful inspection mechanisms, causes the session to timeout. By defining UDRs to enforce consistent traffic flow through the firewall, organisations can ensure that all network traffic undergoes proper inspection and filtering, maintaining security and compliance standards. Failure to implement UDRs can result in traffic bypassing the firewall, exposing the network to security risks and compromising its integrity. Therefore, it's crucial to configure UDRs appropriately to prevent asymmetric routing and ensure effective traffic management within the network infrastructure.

HUB UDR Considerations

The rest of this article will discuss the Implementation of Hub specific services, and explain the UDR rules necessary for those subnets.

Azure Bastion

Azure Bastion is a fully managed platform-as-a-service (PaaS) offering that provides secure and seamless remote access to virtual machines (VMs) in your Azure network without exposing them to the public internet. By eliminating the need for public IP addresses and minimizing exposure to potential security threats, Azure Bastion enhances the overall security posture of your network infrastructure.

Key Features:

Enhanced Security: Bastion provides a secure and private connection to VMs over TLS.
Centralised Authentication: Seamlessly integrates with Azure AD for user authentication, streamlining access management and enhancing security. Centralised logging too!
Managed Service: Fully managed by Azure, Azure Bastion handles infrastructure management, patching, and scaling, reducing operational overhead for administrators.
Zero Trust Model: Enforces a zero-trust security model by routing all inbound RDP/SSH traffic through Azure Bastion, restricting access to authorised users and devices.

Routing Considerations:

Selective Routing: Instead of routing all traffic, consider selectively routing traffic only to target subnets, maintaining a secure posture and reducing unnecessary network exposure.

Bastion UDR

This UDR is relatively simple.

Route 10.0.0.0/8 via AzureFirewallIP
Route 172.16.0.0/12 via AzureFirewallIP
Route 192.168.0.0/16 via AzureFirewallIP

Deploying NAT Gateway on Azure Firewall Subnet

Having a NAT gateway is essential for providing outbound connectivity from resources within a virtual network (VNet) while ensuring security and compliance by translating internal private IP addresses to a public IP address.

When deploying Azure Firewall, it's essential to set up a Network Address Translation (NAT) Gateway on the firewall subnet to facilitate outbound connectivity for resources within the virtual network (VNet). Here's a step-by-step guide to deploying NAT Gateway:

NAT Gateway UDR RULE

This UDR is really simple.

Route 0.0.0.0/0 via Internet

NOTE THIS UDR RULE IS TO BE ATTACHED TO THE AZURE FIREWALL SUBNET, NOT THE NAT GATEWAY APPLIANCE!

Steps:

Create a Public IP Address: Begin by creating a public IP address resource in the Azure portal. This public IP address will serve as the external address for the NAT gateway appliance, allowing outbound communication to external networks and services.
Deploy NAT Gateway Appliance: Provision the NAT gateway appliance in your Azure subscription. Ensure that you select or create a dedicated subnet within your virtual network (VNet) to host the NAT gateway appliance during the deployment process.
Configure NAT Gateway Subnet: Navigate to the subnet settings of the subnet designated for the NAT gateway appliance. Associate the public IP address created in step 1 with this subnet. This configuration enables the NAT gateway appliance to perform network address translation for outbound traffic.
Configure NAT Rules: Within the configuration settings of the NAT gateway appliance, define NAT rules to specify the translation between internal private IP addresses and the public IP address associated with the NAT gateway. Configure these rules to allow outbound traffic from the VNet to external destinations.
Test Connectivity: After configuring the NAT gateway appliance and NAT rules, perform connectivity tests to verify that internal resources within the VNet can access the internet and external services using the public IP address assigned to the NAT gateway.
Monitor and Troubleshoot: Continuously monitor the performance of the NAT gateway appliance, including metrics such as throughput and connection counts. Utilize Azure Monitor and network monitoring tools to troubleshoot any connectivity issues and ensure that traffic is being translated and forwarded correctly by the NAT gateway appliance.

Azure Firewall

When deploying the Azure Firewall, several key considerations should be taken into account to ensure optimal performance, security, and scalability of your network infrastructure.

Steps:

Preparation: Before deploying Azure Firewall, ensure that you have the necessary permissions and resources available in your Azure subscription. This includes having appropriate role-based access control (RBAC) permissions to create and manage resources, as well as an existing virtual network (VNet) where you intend to deploy the firewall.
Create Azure Firewall: In the Azure portal, navigate to the Azure Firewall service and initiate the creation process. You'll need to specify details such as the firewall name, the subscription and resource group where it will reside, and the region. Check the SKU (Standard or Premium), ensure Public IP address assignment, and configure threat intelligence settings.
Monitoring and Logging: Enable logging and monitoring for the Azure Firewall to track traffic, detect threats, and troubleshoot issues - logging to a Azure Analytics Workspace.
Configure diagnostic settings to stream logs to Azure Monitor or other monitoring solutions for analysis.
Testing and Validation: After deploying and configuring the Azure Firewall, perform thorough testing to ensure that traffic flows as expected and that security policies are effectively enforced. Conduct penetration testing and vulnerability assessments to identify any weaknesses in the firewall configuration.
Ongoing Management: Regularly review and update the firewall configuration and logs (especially drops) to adapt to changes in your network environment (this is essential during the adoption phases) and evolving security threats.
Monitor firewall logs and alerts for suspicious activity and take appropriate action to mitigate risks.

Azure Firewall UDR RULES

Two clear scenarios:

Enabling BGP Route Propagation

Route BastionSubnet via VNET
Route AppGatewaySubnet via VNET

No custom routes needed for each spoke vnet.

Disabled BGP Route Propagation

Route VNGW S2S VPN remote subnets via VNET Gateway IP.

Route BastionSubnet via VNET

Route AppGatewaySubnet via VNET
Route each spoke vnet via VNET Peering

Don't forget to include the NAT Gateway Default route from earlier!

Firewall Policies and Inheritance

In Azure Firewall, firewall policies are sets of rules that define how traffic is allowed or denied based on specified criteria such as source and destination IP addresses, ports, protocols, and application types. These policies provide granular control over network traffic flowing through the firewall, allowing organisations to enforce security requirements and compliance standards.

Azure Firewall supports the concept of policy inheritance, where multiple firewall policies can be associated with a single firewall instance. When multiple policies are applied, Azure Firewall evaluates traffic against each policy in a specific order to determine the action to take.

The order of precedence for firewall policies is as follows:

Explicit Rules: These are rules defined explicitly within a specific policy. They take precedence over any other rules defined in inherited policies.
Parent Policy Rules: If a firewall policy inherits rules from a parent policy, those rules are evaluated next. Parent policies can contain common rules that apply to multiple firewalls or environments, providing a centralised way to manage security policies.
It's a good practice to add global allow-list/deny-list rules in a parent policy.
Default Rules: If no matching rules are found in the explicit or parent policies, Azure Firewall applies default rules defined at the firewall level. These default rules specify the default action to take for traffic that doesn't match any explicit or inherited rules.

Azure Firewall Policy-Related UDR RULES

Why am i even mentioning this?

Well if you are like me, and your Azure Firewall is processing millions of outbound packets just to drop them, such as Global deny-list entries.

You could consider moving those 'frequent offending public IPs' and add them to the Azure Firewall UDR, setting the destination to NONE.

Deploying Virtual Network Gateway (VNGW)

Deploying a Virtual Network (VNet) Gateway in Azure is a fundamental step in establishing secure connectivity between Azure Virtual Networks (VNets), on-premises networks, and other cloud environments. Follow these installation steps to set up a VNet Gateway efficiently:

Steps:

Navigate to Virtual Network Gateway: In the Azure portal dashboard, navigate to the "Create a resource" option and search for "Virtual Network Gateway" in the search bar.
Create New Gateway: Click on "Virtual Network Gateway" from the search results, then click the "Create" button to initiate the creation process.
Configure Basics: In the "Basics" tab, specify the following details:

Subscription: Select the Azure subscription to use for the VNet Gateway.

Resource Group: Choose an existing resource group or create a new one for the VNet Gateway.

Region: Select the Azure region where the VNet Gateway will be deployed.

Gateway Type: Choose between VPN and ExpressRoute based on your connectivity requirements.

VPN Type (if applicable): Select the VPN type (Route-based or Policy-based) for VPN gateways.

Configure Gateway Settings: In the "Settings" tab, configure additional settings such as:

Gateway SKU: Choose between Basic and Standard SKU based on performance and feature requirements.

Virtual Network: Select the Azure VNet to associate with the VNet Gateway.

Gateway Subnet: Specify the subnet within the selected VNet to deploy the gateway.

Configure Connectivity: If setting up a VPN gateway, configure connectivity settings such as:

VPN Type: Select the VPN protocol (IKEv1 or IKEv2) and encryption algorithms.

Public IP Address: Choose to create a new public IP address or use an existing one for the gateway.

Review and Create: Review the configuration settings to ensure accuracy, then click the "Create" button to initiate the deployment process.
Monitor Deployment: Monitor the deployment progress in the Azure portal. Once the deployment is complete, the VNet Gateway will be ready for use.
Configure Connection: After the VNet Gateway is deployed, configure connections to on-premises networks or other VNets as needed. This may involve setting up Site-to-Site VPN connections, Point-to-Site VPN connections, or VNet peering.

Virtual Network Gateway UDR RULES

We have 2x scenarios again:

Enabling BGP Route Propagation:

Route BastionSubnet via VNET
Route AppGatewaySubnet via VNET
No custom routes needed for each spoke VNET.

Disabled BGP Route Propagation:

Route VNGW S2S VPN remote subnets via VNET Gateway IP.
Route BastionSubnet via VNET
Route AppGatewaySubnet via VNET
Route each spoke VNET via VNET Peering

If you are enabling/disabling route-propagation here, then the Azure Firewall Subnet UDR also needs an identical route-propagation setting!

Summary

In summary, adhering to peering configurations and enforcing User Defined Routes (UDRs) is essential for achieving "forced tunneling" in a Hub-and-Spoke network topology.

By carefully configuring VNet peering relationships and deploying UDRs, are carefully planning the deployment of HUB based resources (and their respective UDRs) then organisations can route all traffic through designated pathways, ensuring centralised security enforcement and minimising exposure to external threats.

This approach enhances network isolation, streamlines access management, and strengthens overall security posture. However, successful implementation requires meticulous planning, ongoing monitoring, and adherence to best practices to effectively harness the full potential of the Hub-and-Spoke model in Azure.

Page updated

Report abuse