What changed

Microsoft made auto-learn SNAT routes generally available on 1 September 2026, describing it as automatically learning registered and private destination prefixes periodically and applying them as No-SNAT ranges to preserve original source IPs and simplify SNAT management. The firewall documentation, updated 31 August 2026, sets out the mechanics and the prerequisites. Learning runs every thirty minutes, and learned ranges are treated as internal so traffic to them is not SNATed. Both virtual network deployments and secured virtual hub deployments support the feature. Auto-learn requires the firewall to be associated with an Azure Route Server. For virtual network deployments the Route Server must be deployed in the same virtual network as the firewall, in a dedicated subnet named RouteServerSubnet of at least a /27; for secured virtual hub deployments a Route Server is already deployed and associated by default. In both models the feature must then be enabled in the Azure Firewall Policy after the association is complete. The same page records a tooling gap: the Azure CLI does not support configuring auto-learn SNAT routes, and the portal, Azure PowerShell or an ARM template must be used instead. The Route Server FAQ supplies the operational cost of the prerequisite. Creating or deleting a Route Server in a virtual network that contains a virtual network gateway, whether ExpressRoute or VPN, causes downtime that Microsoft says to expect to last ten minutes, and the deployment itself may take thirty to sixty minutes, so Microsoft recommends scheduling a sixty-minute maintenance window.

The risk is a change made on the assumption that it is small. Auto-learn SNAT routes reads as a firewall policy setting, and the work of enabling it is a policy setting. The prerequisite is not: it is a new Azure resource deployed into the same virtual network as the firewall, and in the topology where a firewall normally lives that virtual network also holds a VPN or ExpressRoute gateway. Microsoft states that creating or deleting a Route Server in such a network causes downtime. A change requested as a configuration tweak and delivered as a hub outage is how change control loses its credibility.

What the term means in plain language

Source network address translation, or SNAT, rewrites the source address of a packet as it leaves a device. Azure Firewall applies SNAT to all outbound traffic bound for public addresses, and by default it does not apply SNAT with network rules when the destination sits in a private address range under IANA RFC 1918 or the shared address space under RFC 6598. Application rules always use SNAT regardless of destination, through a transparent proxy. The default suits an estate whose private addressing follows the standard ranges. It suits an organisation using registered public address space internally rather less: to the firewall those destinations look public, so traffic to them is source-NATed to a firewall address and every downstream log, access control list and investigation loses the original client identity. Auto-learn SNAT routes is a mechanism for discovering those internal ranges automatically rather than maintaining a list by hand.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

Azure Firewall auto-learn SNAT routes reached general availability on 1 September 2026. The firewall learns registered and private address prefixes every thirty minutes and treats them as internal, so traffic to them is not source-NATed and original source addresses survive. The prerequisite, documented on the feature page, is that the firewall must be associated with an Azure Route Server in the same virtual network. The Route Server FAQ adds the part that decides scheduling: deploying one into a network that already holds a VPN or ExpressRoute gateway causes about ten minutes of downtime.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

The feature is worth having and the case for it is not really about SNAT management, it is about attribution. When a firewall rewrites the source address of internal traffic, every log on the far side records the firewall rather than the client, and the cost of that lands on the days you can least afford it: an incident investigation, an access review, an audit question about who reached a system. Preserving the original source address is the difference between an answer and an inference. Where an organisation uses registered address space internally, which is common in businesses that grew through acquisition or that carry addressing inherited from an older network, the default behaviour is actively working against them and maintaining the No-SNAT list by hand is exactly the kind of task that is correct on the day it is done and wrong six months later. Automatic learning is the right answer to that problem. The decision is therefore about sequencing and not about direction, and it turns on a fact that is not in the announcement. Enabling the feature is a policy change. Meeting its prerequisite is a deployment. Azure Route Server is a separate managed resource, it needs a dedicated subnet of at least a /27 in the firewall’s own virtual network, and Microsoft’s guidance is unambiguous that creating it where a VPN or ExpressRoute gateway already exists takes that gateway down for around ten minutes. A hub-and-spoke landing zone with a firewall in the hub almost always has a gateway in the same virtual network, because that is what the pattern is for. That inference is ours, but it describes the normal shape of the estates we see, and the consequence is that the prerequisite lands on the busiest network the organisation owns, the one carrying every site-to-site tunnel and every ExpressRoute circuit. Treat it accordingly. Two smaller points belong in the same conversation. If the firewall is built and maintained by a pipeline, the Azure CLI cannot enable this, so the pipeline needs an ARM or PowerShell path before the change is scheduled. And a Route Server brings its own constraints into the virtual network it joins, which are worth reading before it is deployed rather than after.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

The starting position is the firewall’s private range configuration, and it is worth confirming before changing anything, because auto-learn augments this rather than replacing it. Azure Firewall’s default private ranges expand from IANAPrivateRanges, and the important behavioural note is that the configuration applies only to network rules: application rules always use SNAT through a transparent proxy regardless of destination. Where custom ranges are specified, IANAPrivateRanges must be kept in the list to retain the defaults. Two special values exist and are occasionally useful: 0.0.0.0/0 configures the firewall never to SNAT traffic processed by network rules, which also prevents it routing directly to the internet, and 255.255.255.255/32 configures it always to SNAT. Firewalls associated with a firewall policy must set the range in the policy rather than through AdditionalProperties, and the PrivateRange property on the firewall itself is ignored in that case. For auto-learn on a virtual network firewall the sequence is fixed. Create a subnet named RouteServerSubnet in the firewall’s virtual network, at least a /27. Deploy Azure Route Server into that virtual network. Associate it with the firewall, either at creation with the RouteServerId parameter on New-AzFirewall, by setting RouteServerId on an existing firewall and calling Set-AzFirewall, or in an ARM template through the Network.RouteServerInfo.RouteServerID additional property. Then enable auto-learn in the firewall policy, with New-AzFirewallPolicySnat and the AutoLearnPrivateRange switch, or in a template by setting snat.autoLearnPrivateRanges to Enabled, or in the portal under the policy’s Private IP ranges (SNAT) blade. For a secured virtual hub the Route Server is already present and associated, and only the policy step applies. Verification is straightforward and should be part of the change record: Get-AzFirewallLearnedIpPrefix returns the learned prefixes, and the portal exposes the same list under the firewall’s Learned SNAT IP Prefixes blade. Before deploying the Route Server, read what it brings with it. Only one Route Server is permitted per virtual network and it must sit in the dedicated subnet. That subnet cannot carry a user-defined route or a network security group. Route Server does not support IPv6, and Microsoft states that deploying one into a virtual network that has an IPv6 address space breaks IPv6 connectivity. It requires public endpoints for the Azure management platform to reach it, which Microsoft explains and asserts is not an exposure of the virtual network. It accepts a maximum of four thousand routes from a single BGP peer and tears down the session above that. And capacity is priced: a Route Server deploys with two routing infrastructure units supporting four thousand connected virtual machines, with additional units available in increments of a thousand at a published per-hour rate that varies by region, so confirm the figure for your own region on the Azure pricing page rather than assuming the quoted example.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: The network lead who owns the hub virtual network and the Azure Firewall policy, with the change manager who owns the maintenance window, because this is a scheduling decision before it is a technical one.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Before anyone commits to enabling this, look at what else lives in the firewall’s virtual network. If there is a VPN or ExpressRoute gateway there, treat the work as a change window rather than a configuration change: Microsoft recommends scheduling sixty minutes and states to expect ten minutes of downtime when the Route Server is created. Confirm you have, or can create, a dedicated RouteServerSubnet of at least a /27, and check whether your firewall is deployed by a pipeline, because the Azure CLI cannot configure auto-learn.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The current SNAT private range configuration on the firewall policy before the change, the topology record showing what else occupies the firewall’s virtual network, the approved change window and the observed gateway downtime against Microsoft’s stated expectation, and after enablement the learned prefix list, which is retrievable and is the only proof that the feature is doing what was asked of it.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

What does auto-learn SNAT actually change?

The firewall discovers registered and private address prefixes every thirty minutes and treats them as internal, so traffic to those destinations is not source-NATed. The practical effect is that the original source address survives to the destination, which is what makes downstream logs and access controls meaningful.

Why would we need it if RFC 1918 ranges are already excluded by default?

You may not. It matters where an organisation uses registered, publicly routable address space on its internal network, which the firewall would otherwise treat as an external destination and SNAT. It also removes the maintenance burden of a hand-kept No-SNAT list, which is the kind of list that drifts.

What is the prerequisite?

An Azure Route Server associated with the firewall. For a virtual network deployment it must be in the same virtual network as the firewall, in a dedicated subnet named RouteServerSubnet of at least a /27. For a secured virtual hub, a Route Server is already deployed and associated by default and only the policy setting is needed.

Will deploying the Route Server cause an outage?

If the virtual network already contains an ExpressRoute or VPN gateway, yes. Microsoft states to expect downtime lasting ten minutes when a Route Server is created or deleted in such a network, that deployment may take thirty to sixty minutes, and recommends scheduling a sixty-minute maintenance window. If an ExpressRoute circuit is connected, its connections to other virtual networks are not affected.

Can we enable it from the Azure CLI?

No. Microsoft states that the Azure CLI does not support configuring auto-learn SNAT routes and directs you to an ARM template, Azure PowerShell or the portal. If the firewall is deployed by a CLI-based pipeline, that pipeline needs a change before this does.

How do we confirm it is working?

Get-AzFirewallLearnedIpPrefix returns the prefixes the firewall has learned, and the same list is visible in the portal under Learned SNAT IP Prefixes on the firewall. Capture it after enablement, because it is the only direct evidence that the feature is doing what was intended.

Does a Route Server bring any other constraints?

Several worth knowing first. One per virtual network, in its dedicated subnet, which can carry neither a user-defined route nor a network security group. It does not support IPv6 and Microsoft states that deploying one into a virtual network with an IPv6 address space breaks IPv6 connectivity. It requires public endpoints for platform management, and it accepts at most four thousand routes from a single BGP peer.

Is there a cost?

Yes, and it is capacity-based. A Route Server deploys with two routing infrastructure units, supporting four thousand connected virtual machines across its own and peered virtual networks, and additional units are available in increments of a thousand at a per-hour rate that Microsoft states varies by region. Confirm the South Africa North figure on the Azure pricing page rather than working from the United States example in the FAQ.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.