Microsoft Azure offers a feature called “Forced Tunneling”, which allows you better manage and control your outbound internet traffic from resources within your Azure virtual networks through your Organisation’s on-premise firewall via an established VPN connection or an ExpressRoute circuit.
Why do I need it?
Resources deployed in an Azure VNET needing to access the Internet will use the default system defined routes to use the Azure backbone. This does not provide options to audit or inspect this outbound traffic which could have sensitive or data that should not be allowed out in the first place without inspection. Organisations want better control and management of this traffic and most cases, prefer to route this via their established and managed on-premises firewall infrastructure.
A couple of key points to understand the flow of Internet traffic in Azure, with routes precedence:
A UDR (User-Defined Route) will allow you to control the flow of Internet traffic based on your requirements eg: Outbound Internet access via your on-premises infrastructure.
Using an ExpressRoute circuit will use the BPG routes to go out to the Internet
The default route (system defined) to the Internet is to go out via the Azure backbone
How do I configure it?
When considering Azure Forced Tunneling, we have two options:
Option #1 – Using a VPN Gateway
Using UDRs, all Internet traffic can be redirected traffic to an on-premise site as the default route using an Azure VPN Gateway (site to site VPN)
For this site to site VPN model, forced tunnelling works requires dynamic (route based) gateway
The diagram below (courtesy of Microsoft) describes how Forced Tunneling works from an Azure VNet connected to on-premises infrastructure via a site to site VPN connection
Figure 1 – Forced tunnelling via VPN GW: Microsoft
Key observations from this configuration:
The Frontend subnet (web or DMZ) is not Forced tunnelled, which means all outbound traffic from this subnet to the internet goes directly through the Azure backbone.
The Backend & Mid-tier subnets will not be allowed Internet access via the Azure backbone and outbound connections from these subnets will be routed (Forced) back to on-premise site via the VPN Gateway
Option #2 – Forced tunnelling via Azure Firewall
This method is currently in Public preview
An Azure firewall management subnet, with a public IP address & Azure Firewall subnet must be created.
Once you configure Azure firewall to support Forced tunnelling, this configuration cannot be reverted.
All Service Management traffic is separated from customer traffic on the Azure Firewall appliance. Service Management traffic contains Azure Firewall and platform updates.
Only the Azure Firewall Management subnet has direct access to the Internet and UDR and BGP routes are disabled.
The Azure Firewall subnet can include routes like UDR to the on-premises firewall or virtual network appliance (NVA) to process the network traffic before it is passed on to the Internet.
The diagram below describes how forced tunnelling works with Azure firewall:
Figure 2 – Forced tunnelling via Azure Firewall
Key points in this configuration:
Outbound traffic from the web subnet is not forced tunnelled, which means connections from this subnet to internet goes directly via the Azure backbone.
Outbound traffic from the Azure firewall management subnet is also not forced tunnelled, which means connections from this subnet to the Internet goes directly via the Azure backbone.
Outbound Traffic from the App and Data subnets are forced tunnelled meaning connections from these subnets will be routed (Forced) back to on-premise site via the Azure Firewall subnet.
Additionally, ExpressRoute Forced tunnelling is not configured via this mechanism, but it is enabled by advertising the default route via BGP routes.
Santhosh has over 15 years of experience in the IT organization. Working as a Cloud Infrastructure Architect and has a wide range of expertise in Microsoft technologies, with a specialization in public & private cloud services for enterprise customers. My varied background includes work in cloud computing, virtualization, storage, networks, automation and DevOps.
