Private IP DNAT Support and Scenarios with Azure Firewall

introduction

Azure Firewall is a cloud-native security service that protects workloads running on Azure. It is a stateful firewall as a service with built-in high availability and auto-scaling capabilities. Azure Firewall supports three types of rules: DNAT, network, and application rules. This blog covers the enhancements to DNAT rules. Until recently, DNAT rules worked only on the firewall public IP address used primarily for incoming traffic. In this release, we have enhanced the DNAT scenario to support port translation on Azure Private IP (VIP). This capability helps with connectivity between duplicate IP networks, a common scenario when enterprises onboard new partners to their networks or merge with new acquisitions. DNAT on Private IP is also relevant for hybrid scenarios (connecting on-premises datacenters to Azure), where DNAT bridges the gap and enables communication between private resources over non-routable IP addresses.

In this blog post, we will dive deeper into the DNAT feature for private IP addresses for traffic between overlapping private IP addresses across your network and traffic between non-routable private IP addresses.

What is DNAT?

Destination Network Address Translation (DNAT) involves translating the destination IP address and/or port of a routed packet and reversing this process for all responses. In other words, DNAT translates the destination IP address.

How do DNAT rules work in Azure Firewall?

You can configure Azure Firewall DNAT to translate and filter incoming Internet and/or intranet traffic to your subnet. When you configure DNAT, the DNAT rule collection action is set to type DNAT. You can then use each rule in the DNAT rule collection to translate a firewall public or private IP address and port to another IP address and port.

DNAT rules take precedence over network rules. If a matching rule is found, the traffic is transformed according to the DNAT rule and allowed through the firewall. Therefore, the traffic is not subject to further processing by other network rules. For security reasons, the recommended approach is to add specific sources to allow DNAT to access the network and avoid using wildcards. For more information on rule processing order, see the following article. Azure Firewall Rule Processing Logic | Microsoft Learn.

Setting up private IP DNAT for overlapping networks – DNAT rules for both Azure Firewall (azfw1 and azfw2)

In this section, we will show you how the Private IP DNAT feature of Azure Firewall can help you resolve network duplication issues. In the example below, we will create DNAT rules on both Azure Firewalls to enable connectivity between vm2 and vm4.

The deployment consists of four VNETs.

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

Vnet1 and Vnet3 each deploy their own Azure Firewall.

• Bnet 1
  • Firewall Name: azfw1
  • Firewall Private IP: 10.10.0.68
• Vnet 3
  • Firewall Name: azfw2
  • Firewall Private IP: 10.10.2.4

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

Here’s how DNAT rules are created on each Azure Firewall:

AZFW1

AZFW2

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

Setting up private IP DNAT on non-routable networks

This section shows how Private IP DNAT helps to remove barriers between non-routable networks, where resources in a remote network need to communicate with other resources in a different VNET (or vice versa), and there is no direct routing between the two networks. In this scenario, Azure Firewall builds a bridge that allows connectivity between the networks through Private IP DNAT rules.

The scenario deployed here consists of three VNETs.

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

The problem we are trying to solve here is that there is no direct connection between Remote-Network-1 and VNET4. The dotted arrow shows that the data path from RemoteVM1 initiates a connection request to vm4 on port 80 (http).

Here’s how DNAT rules are created in AZFW2:

Below are the valid routes coming from the NIC of the virtual machine RemoteVM1, and here we can see that there is no route to the network 192.168.10.0/24.

Applying the above configuration will enable connectivity from RemoteVM1 to VM4 via Azure Firewall’s DNAT rule without directly routing between the two networks.

All DNAT rule logs can be saved by creating Azure Diagnostic at the Azure Firewall level. In this blog post, we will enable resource-specific logs and save them to a Log Analytics Workspace. To find the logs, look at the AZFWNatRule table and the logs are as follows:

conclusion

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

resources