Blog Post

Azure Network Security Blog
4 MIN READ

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

gusmodena's avatar
gusmodena
Icon for Microsoft rankMicrosoft
Sep 03, 2024

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

Updated Sep 30, 2024
Version 8.0
  • Gfelli's avatar
    Gfelli
    Copper Contributor

    Great new feature as it was only possible with SNAT before. But if I send translated packages over another firewall, I have to open the whole Azure Firewall subnet as source? As far as we have tested it, the source ip of the package gets not translated to the AZFW instance IP, instead it is using a random IP out of the firewall subnet range (or maybe one of the scaled instances ip). Is that correct or are we missing something.

    Example:
    AZFW subnet: 172.31.0.192/26
    AZFW instance IP: 172.31.0.196

    We see packages with source ip 172.31.0.197, 172.31.0.199 and others...


    Would be good if the translated package are keeping the instance ip (or at least a static ip) to open the IP flow on other firewalls behind it.

    Thanks

  • sotos's avatar
    sotos
    Copper Contributor

    This is a great new feature of Azure firewall and an awesome write up! Well done and thank you sir!

  • Gfelli that's correct. You will see the IP address of one of the active Azure Firewalls instances as the source. Since there's no way to predict how many instances are currently deployed and what IP addresses are in use, you have to allow traffic coming from the AzFW subnet.

  • Seems like one scenario not mentioned here is using Private Endpoints. It was previously possible to use Private endpoints over AzFw, but only with Application Rules, that implicitly did the same - they performed NAT.

    Now should be possible to use another types of traffic, besides HTTPS (NFS drives, SQL TDS connections and so on).

     

    Correct me if I'm wrong.

  • zukako's avatar
    zukako
    Copper Contributor

    This private DNAT can be one solution for IP addresses shortage. We can use it as another time of private link service (LB) concept.

  • DavidZ1250's avatar
    DavidZ1250
    Copper Contributor

    Looks really cool, thanks for the overview!

     

    One question regarding some extended example: How could this configuration scale, e.g. if I want to reach multiple servers on the other side? To build on top of the example from above: What if there's a VM4, VM5, VM6, etc. all of which I want to reach from VM2, preferably via nice, clean FQDNs from the client's side?