Private IP DNAT Support (Preview) and Scenarios with Azure Firewall

Introduction

Azure Firewall is a cloud native security service to protect your workloads running in Azure. It is a stateful firewall as a service with built-in high availability and auto scale. Azure Firewall supports three rule types: DNAT, Network and Application rules.

 

In this blog, we will talk about enhancements to the DNAT rules. Up until recently, DNAT rules was only supported on the Firewall Public IP addresses, mostly used for incoming traffic. In this release, we have enhanced DNAT scenario to support port translation on Azure Private IP (VIP). This capability helps with connectivity between overlapped IP networks, which is a common scenario for enterprises when onboarding new partners to their network or merging with new acquisitions. DNAT on Private IP is also relevant for hybrid scenarios (connecting on-premises datacenters to Azure), where DNAT bridges the gap, enabling communication between private resources over non-routable IP addresses.

 

What is DNAT?

Destination Network Address Translation (DNAT) involves transforming the destination IP address and/or port of a packet that is routed and reverses this process for any responses. In other words, DNAT translates destination IP addresses.

 

How does a DNAT rule work on Azure Firewall?

You can configure Azure Firewall DNAT to translate and filter inbound Internet and/or Intranet traffic to your subnets. When you configure DNAT, the DNAT rule collection action is set to DNAT type. Each rule in the DNAT rule collection can then be used to translate your firewall public or private IP address and port to a different IP address and port.

 

DNAT rules are applied in priority before network rules. If a match is found, the traffic is translated according to the DNAT rule and allowed by the firewall. So, the traffic isn't subject to any further processing by other network rules. For security reasons, the recommended approach is to add a specific source to allow DNAT access to the network and avoid using wildcards. For more information about rule processing order, check out the following article: Azure Firewall rule processing logic | Microsoft Learn.

 

Setting up Private IP DNAT for Overlapping Networks - DNAT Rule on both Azure Firewalls (azfw1 and azfw2)

This section will show you how the Private IP DNAT feature on Azure Firewall can help resolve the problem of overlapping networks. In the example below we are creating a DNAT rule on both Azure Firewalls so we can establish a connection between vm2 and vm4.

 

The deployment consists of 4 VNETs:

• Vnet1: 10.10.0.0/23
• Vnet2: 192.168.0.0/24 (Overlap with Vnet4)
• Vnet3: 10.10.2.0/23
• Vnet4: 192.168.0.0/24 (Overlap with Vnet2)

 

Vnet1 and Vnet3 each have their own Azure Firewall deployments.

• Vnet1
  • Firewall Name: azfw1
  • Firewall Private IP: 10.10.0.68
• Vnet3
  • Firewall Name: azfw2
  • Firewall Private IP: 10.10.2.4

 

The dotted arrows show the data path of when vm2 starts a connection request to vm4 on port 80 (http).

 

Here is how the DNAT rules have been created on each Azure Firewall:

 

AZFW1

 

AZFW2

 

Since we are using DNAT rules on both Azure Firewalls, and there’s a VNET peering between vnet1 and vnet2, vm2 knows the routing path to take to the next hop (10.10.0.68). In this scenario no Route Tabe is required on vm2’s subnet.

 

Setting up Private IP DNAT Across Non-Routable Networks

 

This section will show you how Private IP DNAT can help you remove barriers between non-routable networks, where a resource from a remote network needs to communicate to another resource sitting in a different VNET (or vice-versa), with no direct routing between both networks. In this scenario the Azure Firewall will build the bridge allowing connections across the networks via Private IP DNAT rule.

 

The scenario deployed here consists of 3 VNETs:

• Remote-Network-1: 172.16.0.0/24 (Connected via VPN to VNET3)
• Vnet3: 10.10.2.0/23 (Connected via VPN to Remote-Network-1 and via VNET peering to VNET4)
• Vnet4: 192.168.0.0/24 (Connected via VNET peering to VNET3)

 

The issue we are solving here is the lack of direct connection between Remote-Network-1 and VNET4. The dotted arrows show the data path of RemoteVM1 starting a connection request to vm4 on port 80 (http).

 

Here is how the DNAT rules have been created on AZFW2:

 

Below is the Effective Routes from the virtual machine RemoteVM1’s NIC, where we can confirm there is no route to the network 192.168.10.0/24.

 

With the above configuration in place, we can establish connection from RemoteVM1 to VM4 through Azure Firewall’s DNAT rule, without having a direct routing between both networks.

 

All the DNAT rule logs can be saved by creating an Azure Diagnostic at Azure Firewall’s level. In this blog post we’ve enabled resource specific logs and we are saving them in our Log Analytics Workspace. To find the logs, we are looking into the table AZFWNatRule and this is how the log looks like:

 

Conclusion

In summary, DNAT facilitates secure communication, and efficient routing within complex network architectures. It’s a fundamental tool for managing traffic across private and public networks.

 

Resources

• What is Azure Firewall? | Microsoft Learn
• Tutorial: Deploy & configure Azure Firewall and policy using the Azure portal | Microsoft Learn
• Tutorial: Filter inbound Internet traffic with Azure Firewall DNAT policy using the portal | Microsoft Learn
• Azure Firewall rule processing logic | Microsoft Learn
• Azure Firewall known issues and limitations | Microsoft Learn
• Azure Firewall FAQ | Microsoft Learn