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

Announcing Azure Cosmos DB Integration with LangChain.js!

Announcing Azure Cosmos DB Vector Store Integration with LangChain.js! We’re simplifying AI app development by integrating Azure Cosmos ...

2 days ago

Scale Your Database Workloads with Multishard Clusters in vCore-based Azure Cosmos DB for MongoDB

We’re excited to introduce significant enhancements to vCore-based Azure Cosmos DB for MongoDB with the release of multishard clusters preview...

2 days ago

Transform Your Azure Container Apps with Bulletproof Security

In this post, we explore how to transform your Azure Container Apps with unshakable security. Learn how to master secrets management, optimize...

3 days ago

Optimize Azure Landing Zone with Azure Virtual Network Manager IP Address Management

Optimize Azure Landing Zone with Azure Virtual Network Manager IP Address Management What you will learn from this blog This blog explores how...

3 days ago

Announcing UNLIMITED Public Preview of Metadata Caching for Azure Premium SMB/REST File Shares

Azure Files is excited to announce the Unlimited public preview of Metadata Caching for the premium SMB/REST file share tier.  Unlimited ...

3 days ago

Dominate your industry and boost performance using Azure AI tools and skilling

As AI technologies continue to rapidly evolve, developers have the exciting opportunity to stay ahead by continually learning and adapting. Wi...

4 days ago

Azure DevOps – EPICS vs FEATURES vs USER STORIES vs Tasks vs Bugs

Today, we’re diving into Epics, Features, User Stories, Tasks and Bugs and the main differences between them. You will learn when to use...

4 days ago

Discover the New Azure Cosmos DB Samples Gallery!

We are thrilled to introduce the Azure Cosmos DB Samples Gallery —your ultimate destination for top-tier Azure Cosmos DB samples, technical gu...

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