Loading...

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

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.

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

Episode 395 – Getting Started with VDI in Azure with Azure Virtual Desktop

Welcome to Episode 395 of the Microsoft Cloud IT Pro Podcast. In this episode, we dive into Azure Virtual Desktop (AVD) and how it enables org...

2 days ago

Azure AI Agents are in the Public Preview

AI agents are becoming a key enabler for businesses looking to streamline processes, automate repetitive tasks, and empower their employees to...

3 days ago

Simplify your .NET data transfers with the new Azure Storage Data Movement library

This post announces the new and improved Azure Storage Data Movement library for .NET. The post Simplify your .NET data transfers with the new...

3 days ago

External REST Endpoint Invocation in Azure SQL Managed Instance is now in Public Preview

External REST Endpoint Invocation is available in Azure SQL Managed Instance with the Always-up-to-date update policy configured. Call Azure S...

3 days ago

Announcing the end of support for Node.js 18.x in the Azure SDK for JavaScript

After July 10, 2025, the Azure SDK for JavaScript will no longer support Node.js 18.x. Upgrade to an Active Node.js Long Term Support (LTS) ve...

4 days ago

February Patches for Azure DevOps Server

Today we are releasing patches that impact our self-hosted product, Azure DevOps Server. We strongly encourage and recommend that all customer...

4 days ago

Primer: Using Exchange Online PowerShell in Azure Automation Runbooks

In this primer, we cover how to create and execute Azure Automation Exchange Online runbooks (scripts) using cmdlets from the Exchange Online ...

6 days ago

Azure Developer CLI (azd) – February 2025

This post announces the February release of the Azure Developer CLI (`azd`). The post Azure Developer CLI (azd) – February 2025 appeared...

8 days ago

Using Azure AI Foundry SDK for your AI apps and agents

Design, customize and manage your own custom applications with Azure AI Foundry right from your code. With Azure AI Foundry, leverage over 1,8...

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