Azure Firewall continues to evolve with capabilities that simplify the design of secure network architectures in Azure. One feature that has recently become generally available is the ability to configure Destination Network Address Translation (DNAT) using the firewall’s private IP address.
This capability may seem like a small enhancement at first glance, but it opens new architectural possibilities. In many enterprise environments, traffic flows do not always originate from the public internet. Instead, connections may come from internal networks, private connectivity environments, or hybrid infrastructures.
Supporting DNAT directly on the private IP address of Azure Firewall helps address these scenarios in a more flexible way.
Understanding DNAT in Azure Firewall
DNAT allows incoming traffic targeting a specific IP address and port to be redirected to another internal destination. This technique is widely used in network architectures to expose internal services while keeping them protected behind security controls.
In Azure Firewall, DNAT rules traditionally allowed traffic arriving on the firewall’s public IP address to be forwarded to internal resources such as virtual machines or application servers.
The new capability extends this behavior to the firewall’s private IP address. This means traffic arriving from internal or connected networks can also be redirected to specific workloads through controlled DNAT rules.
Where private DNAT becomes useful
Many enterprise architectures rely on centralized network inspection through hub virtual networks. In these designs, Azure Firewall is commonly deployed in a hub environment that controls traffic flowing between different virtual networks, on-premises environments, or connected services.
When traffic arrives through private connectivity such as VPN gateways, ExpressRoute circuits, or virtual network peering, it typically reaches the firewall through private addressing. Being able to apply DNAT rules directly to the private IP address allows the firewall to redirect traffic to the appropriate backend service without requiring public exposure.
This approach helps organizations maintain consistent security controls while supporting internal service publishing scenarios.
Example architecture scenario
A common design involves publishing an internal application that must be accessed from a connected on-premises environment. Instead of exposing the application through a public endpoint, traffic can be directed to the private IP address of Azure Firewall.
The firewall then performs DNAT and forwards the traffic to the correct backend service hosted within the virtual network.
This pattern allows the firewall to remain the central inspection and routing point for inbound traffic while keeping application endpoints private.
Operational considerations
While the feature introduces additional flexibility, architects should still design firewall policies carefully. DNAT rules should be defined with clear port restrictions and target destinations to avoid unnecessary exposure of internal services.
Logging and monitoring also remain important elements of the architecture. Azure Firewall integrates with Azure Monitor and Log Analytics, allowing administrators to observe DNAT rule usage, traffic patterns, and potential anomalies.
Proper network segmentation and routing design should also be considered so that traffic flows predictably through the firewall when DNAT rules are applied.
Closing thoughts
The ability to perform DNAT on Azure Firewall private IP addresses expands the range of architectures that can be implemented using native Azure networking components. It enables more flexible service publishing models while maintaining centralized security inspection.
For organizations operating hybrid environments or complex hub-and-spoke architectures, this capability simplifies the design of private connectivity patterns and strengthens control over inbound traffic flows.