Azure Virtual Hub - Security Configuration

AFAIK, your understanding is correct. “Private traffic prefixes” is different from the Azure Firewall SNAT private ranges configuration. SNAT private ranges control which destination IP ranges should not be source-NATed by the firewall. “Private traffic prefixes” in Routing Intent defines what the Virtual WAN considers as private traffic for the purpose of routing decisions inside the Virtual Hub.

In a Virtual WAN with Routing Intent enabled, the hub classifies traffic into two logical categories: Internet traffic and Private traffic. Internet traffic is generally 0.0.0.0/0. Private traffic is defined by the list in “Private traffic prefixes.” By default, this contains RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). The classification determines whether traffic is forwarded to the Internet security configuration or the Private security configuration. Since you have Private traffic set to “Send via Azure Firewall,” all traffic matching those private prefixes is steered to the firewall.

This setting does not filter traffic at the firewall and it does not restrict which prefixes are allowed through the firewall. It only influences how the Virtual Hub decides whether a given destination is treated as “private” or “internet” for routing intent purposes.

When Routing Intent is enabled, Virtual WAN automatically manages and protects certain system routes, including the RFC1918 defaults. In many configurations, especially when branches or VNets are connected and advertise RFC1918 ranges, the platform keeps those default private prefixes in the route table even if you attempt to reduce them. That is why after saving, the prefixes revert to the default values. The service enforces RFC1918 as the baseline private definition unless you are extending it (for example, adding public IP space used internally) or enabling forced tunneling by adding 0.0.0.0/0.

If your goal was to ensure that only 172.16.0.0/12 traffic is sent to the firewall, that is not how this feature works. With Routing Intent enabled and Private traffic set to “Send via Azure Firewall,” all traffic classified as private according to the defined prefixes will be sent to the firewall. You cannot reduce the default RFC1918 set to a single private block in this model because Virtual WAN still needs consistent private classification for all connected networks.

If you need more granular control over which prefixes are inspected by the firewall, you would need to move away from Routing Intent and instead use custom route tables and UDR-based routing design within Virtual WAN, where you explicitly control which prefixes point to the firewall next hop.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin