Loading...

Private IP DNAT Support and Scenarios with Azure Firewall

Private IP DNAT Support 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 only 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.

gusmodena_0-1724793596501.png

 

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).

gusmodena_1-1724793719862.png

 

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

 

AZFW1

gusmodena_2-1724793759043.png

 

AZFW2

gusmodena_3-1724793778382.png

 

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).

gusmodena_4-1724793849252.png

 

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

gusmodena_5-1724793876677.png

 

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.

gusmodena_6-1724793914910.png

 

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.

gusmodena_7-1724793941499.png

 

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:

gusmodena_8-1724793972341.png

 

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

Published on:

Learn more
Azure Network Security Blog articles
Azure Network Security Blog articles

Azure Network Security Blog articles

Share post:

Related posts

How to create Microsoft Azure 30 days trial?

Microsoft Azure is a comprehensive cloud computing platform developed by Microsoft. It provides a wide range of cloud services, including comp...

5 hours ago

Azure SDK Release (April 2025)

Azure SDK releases every month. In this post, you find this month's highlights and release notes. The post Azure SDK Release (April 2025) appe...

16 hours ago

Getting Started with Azure Cosmos DB Using the Python SDK

If you’re new to Azure Cosmos DB and looking to build applications with Python, you’re in the right place. I’ve created a four-par...

17 hours ago

Azure Developer CLI (azd) in a real-life scenario

This post shares some useful tips and lessons learned while using azd during a migration. The post Azure Developer CLI (azd) in a real-life sc...

1 day ago

Webinar: Translate Dynamics 365 Data in Real-Time using Azure AI Translator with our New App!

Is your business operating across multiple regions? Managing multilingual CRM data in Microsoft Dynamics 365 can lead to communication gaps, d...

1 day ago

Spring Cleaning: A CTA for Azure DevOps OAuth Apps with expired or long-living secrets

Today, we officially closed the doors on any new Azure DevOps OAuth app registrations. As we prepare for the end-of-life for Azure DevOps OAut...

2 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy