The SNAT problem that needed solving
Here is a scenario that plays out in half the hybrid networks I have seen: traffic from Azure toward an on-premises range that is not one of the standard private ranges silently gets source-NATted by Azure Firewall. The on-prem firewall sees an unexpected source IP, a policy match fails, and someone spends an afternoon in packet captures before finding the culprit. The cause is predictable. Azure Firewall SNATs everything except the address ranges it knows about, and by default that exception list is just RFC 1918 and RFC 6598. Your own registered prefixes, announced over BGP from your datacenter, are not on that list.
The traditional fix was manual: work out which ranges should bypass SNAT, enter them as explicit No-SNAT ranges in the firewall policy, and then remember to update that list every time the network changes. It worked, and it rotted.
What auto-learn does
Auto-learn SNAT routes, now generally available, removes the manual list. The firewall periodically learns the registered and private destination prefixes known to Azure Route Server, currently on a 30-minute cycle, and applies them automatically as No-SNAT ranges. When your on-premises space changes or a new prefix comes online, the firewall picks it up without a policy edit. Traffic to those destinations keeps its original source IP end to end.
The Microsoft Learn documentation describes the mechanism and the dependency directly: the firewall needs an association with Azure Route Server to learn from. In a secured virtual hub, the Route Server piece is already there; in a hub VNet you deploy one alongside the firewall.
Enabling it
Enablement lives in the firewall policy, not on the firewall resource itself. In the portal it is a setting under the policy’s SNAT handling. In PowerShell, the policy SNAT object takes the auto-learn flag:
New-AzFirewallPolicySNAT \
-PrivateRange $ranges \
-AutoLearnPrivateRangeOr, in an ARM/Bicep template, set snat.autoLearnPrivateRanges to Enabled. Support covers Azure Firewall Standard and Premium. Basic is left out, which is worth checking before you promise this to a customer running Basic.
The routing context this assumes
Auto-learn leans on Azure Route Server, which is worth unpacking for anyone who has not deployed it. Route Server is a managed BGP endpoint that lets your network virtual appliances, SD-WAN gear, or on-premises routers exchange routes with the Azure VNet directly, without custom scripts or manual route tables. The firewall’s auto-learn feature piggybacks on that exchange: prefixes your on-premises side advertises show up in the Route Server’s routing table, and the firewall reads them from there.
That dependency shapes the deployment pattern. If you run Azure Firewall in a secured virtual hub under Azure Virtual WAN, the plumbing is largely in place and the feature is nearly turnkey. If you run a classic hub VNet topology, you are adding a Route Server deployment, its subnet, and BGP peering with your on-prem edge. That is not a huge lift, but it is not nothing, and if you have no other reason to run Route Server, the cost-benefit should be honest.
There is a subtle interaction with existing private range entries too. Any explicit private ranges already configured in the policy keep working alongside the learned prefixes. Teams should review the manual list after enabling auto-learn, because a stale hand-entered range and a learned range can both match traffic, and troubleshooting gets confusing when the effective No-SNAT set is the union of both sources and you are not sure which is which.
Why preserving source IPs matters
It is tempting to shrug at SNAT as plumbing. It is more than that. When internal traffic keeps its real source address, everything downstream that depends on that address gets easier: firewall rules and logs on the receiving side, security monitoring that groups flows by source, and any on-prem service doing its own IP-based allowlisting. Lost source IPs turn audit trails into guesswork.
The maintenance angle is the bigger win, though. Anyone who has inherited a network where the No-SNAT list was hand-typed three reorganisations ago knows that static lists do not stay correct. A feature that derives the list from the routing table, and refreshes it on a timer, cannot drift out of sync with reality the way a hand-edited policy can.
Two caveats
First, the 30-minute learning cycle means a freshly announced prefix will not bypass SNAT immediately. If you are doing a network change and testing from Azure in the same hour, expect the firewall to catch up after the next learning pass, not instantly.
Second, auto-learn only covers prefixes the Route Server actually knows. Anything that is not advertised over BGP and is not RFC 1918 still needs an explicit entry in the policy’s private ranges. Auto-learn complements the manual list; it does not retire it entirely.
For teams already running Azure Route Server for BGP peering, this is close to a free upgrade: enable the flag in the policy and stop maintaining the list. For everyone else, weigh whether the Route Server deployment is justified on its own merits first.