Photo by Anthony Reungère on Unsplash

Forced Tunneling in Azure Firewall

Thoroughfare

Azure Firewall is a fully stateful firewall as a service with built-in high availability and unlimited cloud scalability that manages both east-west and north-south traffic. In this article, I look at forced tunneling, which allows northbound traffic to be inspected by a local firewall before leaving the regional Azure gateway.

To assess the capabilities of the service properly in relation to its price [1], you should understand how infrastructure-based workloads – think virtual machines (VMs) – typically communicate with the outside world. In Azure, VMs are always deployed on virtual networks (VNets), where each VNet uses a freely selectable RFC 1918-compliant address range.

The VNet must have at least one subnet on which each VM uses the private IP address of its virtual network interface – that is, an address from the subnet's address range. Of course, the VM can also access multiple private IP addresses, either in the form of multiple IP configurations (one of which is always primary) or in the form of multiple network interfaces. The VN needs the VNet to communicate:

• with other VMs in the same network,
• with other Azure services that reside on the same virtual network with a service or private endpoint,
• with Azure VMs on other Azure VNets by VNet peering or IPsec virtual private network (VPN),
• with the local site by IPsec VPN or Microsoft Azure ExpressRoute,
• with other Azure resources by their public endpoint, or
• with the Internet.

Outgoing Internet communication worked automatically out of the box (up to September 30, 2025) without any further configuration – even without an explicit public IP. Microsoft refers to this implicit network address translation (NAT)-like procedure as standard outbound access. However, it was discontinued on the date mentioned above. Ever since, customers have had to configure