Understanding and Creating NAT Rules in Azure Firewall

DNAT

Most people will use the phrase of NAT to describe sharing a service through a firewall, but Microsoft calls it Destination Network Address Translation (DNAT) in their documentation, but a NAT rule in the Azure Portal; I will just use the regularly employed NAT term.
The goal of NAT is to publish an otherwise private service, through a firewall, via an IP address. Typically, a NAT rule will contain settings such as:

• External interface: The interface on the firewall that the rule is being associated with.
• External port number: The port that the rule will be associated with. Note that there is a 1:1 association between a rule and a port on a single interface. External ports cannot be shared.
• Internal address: This is the address that the firewall will send the traffic to; this is the internal address of the shared service, such as an internal load balancer for a web service.
• Internal port number: This is the port that the connection is being translated to. For example, an application might be shared to the Internet with TCP 8080 as the external port number, but the web service might be running on the server(s) on TCP 443.

Using different external port numbers allows an internal port number to be used across many services. For example, TCP 3389 on Server1 might be shared as TCP 50001 on the firewall, and Server2 might be shared as TCP 50002. The remote desktop client will connect to TCP 50002 on the firewall’s external address to connect to Server2.

NAT Rule

A NAT rule contains the following criteria to pattern match traffic coming into the firewall. If traffic matches the protocol and source and destinations patterns, then it will be forwarded to the translated address and port:

• Name: This is a human-friendly label for the rule.
• Protocol: The rule can listen for TCP or UDP traffic.
• Source Addresses: You can specify one or more (comma separated) addresses in the form of wildcard (*) for every possible source, an IP address or a CIDR block.
• Destination Addresses: This is the external IP address of the firewall. If dealing with the Internet, then you should copy/note the IPv4 address of the firewall’s public IP address before creating rules.
• Destination Ports: This is the port that the firewall will listen to on the external interface.
• Translated Address: Here you can specify a single IP address that resides behind the firewall and hosts the service that you are creating a NAT rule for.
• Translated Port: This will be the port that the service is listening to behind the firewall.

NAT Rule Collection

NAT rules are grouped into NAT rule collections; even a single NAT rule must reside in NAT rule collection. I have not seen any best practices from Microsoft on this part of the design, but I would suggest placing similar rules together in a single NAT rule collection.
The NAT rule collection has the following two properties:

• Name: A human-friendly label that should indicate the purpose of the contained NAT rules.
• Priority: A way to order NAT rule collections, using 100 to 65000.

Priority allows you to list collections in order from high priority (specific rules) to low priority (general rules). A typical good practice is to stagger the priorities, such as 100, 200, 300, so you can drop in a rule with a priority of 150 without having to renumber existing rule collections.

Creating NAT Rules

You can create NAT rules in the Azure Portal; start by opening the Public IP Address (PIP) resource of the Azure Firewall and noting it’s address – you will need this to create the NAT Rules.
Open your Azure Firewall resource and browse to Rules. Open NAT Rule Collection (the default location in Rules) and click + Add NAT Rule Collection.
Enter the properties of the NAT Rule Collection, specifying its name and priority versus other NAT Rule Collections.
Then add a rule for each NAT rule that you require. In the below example, I am publishing two services to the Internet. I am only allowing connections from a specific range of IPv4 addresses (the CIDR block of my on-premises firewall). RDP (TCP 3389) will be listened to on TCP 50001 of the firewall’s PIP, and SSH (TCP 22) will be listened to on TCP 50002 on the firewall’s PIP. Both connections will be forwarded to different “jump box” virtual machines.

Implicit Network Rules

When traffic is coming into your firewall and a matching NAT rule is found, an implicit network rule is created to allow the traffic. If you wish, you can create Network Rules (in Network Rules Collections) to allow this traffic or to create very granular deny rules.