Azure Firewall NAT Behaviors

[davidfrazee]

Introduction

The Azure Firewall is a cloud-native and intelligent network firewall security service that can be integrated into many different use cases. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability that provides both east-west and north-south traffic inspection. Depending on how traffic will flow through the Azure Firewall, there are expected NAT behaviors. NAT, or Network Address Translation, is a method of remapping an IP address into another by modifying network address information in the IP header of packets. When traffic passes through an Azure Firewall, the firewall can perform NAT to translate the source or destination IP addresses and ports of the packets. The specific NAT behavior will depend on the firewall’s configuration and the type of NAT being used. In this blog, we cover what behaviors to expect when traffic flows for inbound traffic, through DNAT rules, and for outbound traffic through the Network, and Application rules of the Azure Firewall.

DNAT Rules

Azure Firewall can translate inbound internet network traffic to its public IP address and filter it to the private IP addresses on your virtual networks or to another public IP. This is accomplished using DNAT (Destination Network Address Translation) rules in the Azure Firewall Policy. When a new flow matches against a DNAT rule on the Azure Firewall, both the source and destination IP addresses will be translated to new values. When the destination is a private IP address in the virtual network, the source IP address will translate to one of the IP addresses in the AzureFirewallSubnet of the virtual network, while the destination IP address will translate to what has been configured in the DNAT rule as the Translated address. Also, the source port used by the source machine will be maintained through the connection.

Below covers an example of a network flow that uses a DNAT rule targeting a virtual machine that hosts an IIS server and is listening on TCP port 80. The client machine is a virtual machine hosted in Azure that goes directly out to the internet to reach the Azure Firewall’s public IP. Below is the DNAT rule configuration that targets the backend IIS server.

The client sends an Invoke-WebRequest command to the FQDN (Fully Qualified Domain Name) that resolves to the public IP of the firewall, 40.122.188.187. The Invoke-WebRequest cmdlet sends HTTP and HTTPS requests to a web page or web service. It parses the response and returns collections of links, images, and other significant HTML elements.

From the client’s perspective, the packet capture provides pertinent information. The source IP is the private IP of the client virtual machine, 10.100.0.4, and the destination IP is of the Azure Firewall, 40.122.188.187. The packet capture also shows the source port, 56393, and the destination port, 80.

Once the Azure Firewall receives the flow, it logs the action to a configured log analytics workspace. The log below shows the source IP and port used by the client machine when it traverses the internet, 20.29.103.252:80, the destination IP and port, 40.122.188.187:80, and the translated IP and port, which is the private IP address of the target virtual machine in Azure, 10.200.0.4:80.

Now focus on the NAT behavior of the Azure Firewall by analyzing a packet capture taken from the target virtual machine. The packet captures shows that the source IP has been translated to a new value, 10.0.0.5. This IP is derived from the AzureFirewallSubnet within the virtual network. The destination IP has been translated as well to 10.200.0.4, the targeted virtual machine hosting IIS.

*Note: As a recommended best practice, in this configuration, if NSGs (Network Security Groups) are used in the environment, it is recommended to limit ingress traffic on the target port to the IP space of the AzureFirewallSubnet. Explicit Deny all rules in the NSG will cause this DNAT traffic to fail unless a higher prioritized NSG rule is configured with the AzureFirewallSubnet IP space.  

The Azure Firewall’s DNAT behavior is simple to follow and allows for simple troubleshooting when needing to follow a flow end to end. Although the source and destination IPs do get translated, and in some scenarios, the destination port will translate, there are values within the flow that are maintained that can help with identifying a packet for network troubleshooting. For instance, the Azure Firewall will maintain the source port, the IP identifier, as well as Sequence numbers when using actual values and not values generated by the packet capture application.

Network Rules

Azure Firewall allows for the central creation of allow or deny network filtering rules by source and destination IP address, port, and protocol. The firewall is fully stateful, so it can distinguish legitimate packets for different types of connections. Azure Firewall supports stateful filtering of Layer 3 and Layer 4 network protocols. When it comes to the NAT behaviors of the Azure Firewall through network rules, the behaviors are different depending on how the environment has been configured. In the following sections, we’ll cover different common scenarios of Azure Firewall and explain the NAT behaviors for each.

East-West Traffic Flow (IANA RFC 1918 & IANA RFC 6598)

East-west traffic flow refers to traffic between Azure virtual networks, either subnets within the virtual networks or between spoke virtual networks, and traffic between Azure virtual networks and on-premises networks via Virtual Private Network (VPN) or ExpressRoute (ExR) connections. When this traffic is within RFC 1918 or RFC 6598 address space and the flow is filtered through a network rule, the Azure Firewall will not SNAT (Source Network Address Translation) the flow. This means that all tuples of a network flow are maintained when passing through the Azure Firewall. This behavior can be manipulated through the Private IP ranges configuration on the Azure Firewall Policy. Within this configuration, changes can be made to adjust a variety of SNAT behaviors of the Azure Firewall for network rules.

• First, force the firewall to SNAT traffic flows that are destined for an RFC 1918/RFC 6598 address space to an IP address of the AzureFirewallSubnet.
• Second, prevent the firewall to SNAT any traffic, regardless of the destination. This configuration will prevent the Azure Firewall to route traffic directly to the internet. Use this when using the Azure Firewall in a forced tunneling configuration, where another network device will be the egress point.
• Finally, customize the IP address range that the firewall will not perform SNAT against. This configuration is where Non-IANA RFC 1918 & Non-IANA RFC 6598 address spaces are defined.

East-West Traffic Flow (Non-IANA RFC 1918 & Non-IANA RFC 6598 Private Address Space)

There are scenarios when organizations will need to use public IP address spaces to define their private networks. When this is done, the Azure Firewall will SNAT these network flows by default. When these public ranges are defined in Azure or on-premises, and the Azure Firewall has a direct route via virtual network peering or VPN/ExR connections, our destinations will see the IP addresses of those in the AzureFirewallSubnet. Since the firewall is aware of a private network path to this address space, it will use the IP of the AzureFirewallSubnet to SNAT rather than use its public IP.

Below covers an example of what the traffic looks like when using public IP address spaces in private networks. The client machine is a virtual machine hosted in Azure that goes through the Azure Firewall and is filtered through a Layer 3 network rule. The destination is a virtual machine hosted in Azure that uses a public IP space for its network. Below is the Network rule configuration that allows this traffic.

On the client machine, the client uses Test-NetConnection to send ICMP (Internet Control Message Protocol) traffic to the destination, 200.35.0.4. The Test-NetConnection cmdlet displays diagnostic information for a connection. It supports ping test, TCP (Transmission Control Protocol) test, route tracing, and route selection diagnostics.

From the client’s perspective, the packet capture shows the ICMP packet destined for 200.35.0.4, and the source IP of 10.100.0.4.

Once the Azure Firewall receives this flow, it’s filtered through the network rule and allowed through to the target destination. The log below shows the original source IP and destination IP, as well as the protocol defined as ICMP Type=8.

From the destination’s perspective, the packet capture shows SNAT being performed. The source IP address has changed from the original IP address, 10.100.0.4, to that of the AzureFirewallSubnet, 10.0.0.6, even though the destination is technically a private network.

This behavior is expected as the destination address space is a public IP space, even if it is being used a private network. Manipulating this behavior is simple and can be done by selecting For all IP addresses except those specified below and then defining the range in the Excluded Source-NAT (SNAT) addresses.

Below shows what the ping behavior looks like with the change above applied. Here is the new ping from the client machine once the change is made.

Here is the ping from the destination side. Notice SNAT is no longer being performed by the Azure Firewall.

North-South Traffic Flow

Network rules can also be used to filter North-South traffic instead of Application rules. North-south traffic refers to the traffic that flows in and out of a datacenter, or in this case, an Azure region. When using both Network and Application rules for HTTP/s filtering, Network rules will be applied against the flow before Application rules. In this case, the below NAT behavior is expected.

On the client machine, the client runs a Nslookup against the FQDN, cxefirewall.centralus.cloudapp.azure.com and then an Invoke-WebRequest against the same domain to initiate HTTP traffic across the firewall. The Nslookup returns a destination IP of 104.43.236.2, the public IP directly associated with a virtual machine hosting IIS.

From the client’s perspective, the packet capture shows the HTTP request destined to 104.43.236.2 with a source IP of 10.100.0.4.

When the Azure Firewall receives the flow, it’s matched against a Network rule and then egressed to the public internet. The log shows the original source and destination IP, and the original source and destination port.

On the destination server, the packet capture shows that the source IP has changed to the public IP of the Azure Firewall. The source port has also been changed because of the flow being filtered by a Network rule and then egressed to the internet. Other values are maintained in this scenario when Network rules are used for egress that can be helpful with end-to-end tracing, such as the Seq # and IP identifier.

FQDN Filtering (Public Facing & Internal Endpoints)

Azure Firewall can use FQDNs in network rules based on DNS resolution in Firewall policy. This capability allows the firewall to filter outbound traffic with any TCP/UDP protocol (including NTP, SSH, RDP, and more). DNS Proxy must be enabled when using FQDN filtering in Network rules. When FQDN filtering in Network rules is used, the Azure Firewall will perform SNAT against the flow, even if the destination is within RFC 1918 and RFC 6598 address space. Below covers an example of when FQDN filtering is used in Network rules and the destination IP is within the RFC 1918 address space.

On the client machine, the client runs a Nslookup against the FQDN, www.cxefirewall.net, and then an Invoke-WebRequest against the same domain to initiate HTTP traffic across the firewall. From the Nslookup, the destination IP is 10.200.0.4, a private IP.

From the client’s perspective, the packet capture shows the HTTP request destined to 10.200.0.4 with a source IP of 10.100.0.4.

Once the Azure Firewall receives this flow, it’s filtered through the network rule using FQDN filtering and allowed through to the target destination. The log shows the original source and destination IP, as well as the source and destination port. The logs generated when the network rule is using an FQDN instead of a defined IP space, will surface the destination as the IP and not the FQDN that is configured against the rule.

On the destination server, the packet capture shows the request has landed with a source IP of 10.0.0.6, an IP that’s part of the AzureFirewallSubnet. It also shows that the source port has been maintained through the Azure Firewall as well. Even with the destination being a private IP, this SNAT behavior is expected when using FQDN filtering in Network rules.

Application Rules

The Azure Firewall can limit outbound HTTP/S traffic or Azure SQL traffic to a specified list of FQDNs including wild cards using Application rules. When a flow matches against an Application rule, the Azure Firewall will always SNAT the traffic, regardless of what has been configured in the Private IP ranges function.

On the client machine, the client runs a Nslookup against the FQDN, cxefirewall.centralus.cloudapp.azure.com and then an Invoke-WebRequest against the same domain to initiate HTTP traffic across the firewall. The Nslookup returns a destination IP of 104.43.236.2, the public IP directly associated with a virtual machine hosting IIS.

From the client’s perspective, the packet capture shows the HTTP request destined to 104.43.236.2 with a source IP of 10.100.0.4. Notice the source port of 56067 and even the Seq #s in the Info column of the packet capture, as the SNAT behavior through Application rules is different than Network rules.

Once the Azure Firewall receives this flow, it’s filtered through the Application rule and then egressed to the public internet. The log shows the original source and destination IP, as well as the source and destination port.

On the destination server, the packet capture shows that the source IP has changed to the public IP of the Azure Firewall. The source port and Seq #s has also been changed because of the flow being filtered by an Application rule. This SNAT behavior is expected in this configuration.

Conclusion

As mentioned, there are many different use cases that the Azure Firewall can be used for and a variety of ways that network traffic can flow through the resource. Knowing what NAT behavior to expect when traffic flows across your Azure Firewall will equip you with a way to identify potential network issues quickly and to trace flows end to end.

Notice the simplicity of the logs used in the examples and want to learn more? Read about Azure Firewall’s Structured Logs here.

Resources

1. Azure Firewall Overview - What is Azure Firewall? | Microsoft Learn
2. Azure Firewall Manager Overview - What is Azure Firewall Manager? | Microsoft Learn
3. Azure Firewall SKUs - Choosing the right Azure Firewall SKU to meet your needs | Microsoft Learn
4. Azure Firewall SNAT documentation – Azure Firewall SNAT private IP address ranges | Microsoft Learn
5. Azure Firewall Policy FQDN filtering (Network rules) - Azure Firewall Manager filtering in network rules | Microsoft Learn
6. Azure Firewall Structured Logs - Azure Structured Firewall Logs (preview) | Microsoft Learn
7. Azure Firewall Limits - Azure subscription limits and quotas - Azure Resource Manager | Microsoft Learn

[James van den Berg]

Thank you @davidfrazee for Sharing this great Blogpost with the community 

[gibsonj1998]

Fantastic write-up, @davidfrazee . Appreciate you sharing this! 

[dongyue21]

Could you tell me how to configure and integrate azure firewall with NAT gateway, VPN, express route and Network appliance?

Thanks, @davidfrazee  for your excellent article. 

[SBrickeyRCS]

can you explain to me why the DNAT public IPs are also being used for outbound traffic?

I understand that doing so can help alleviate port exhaustion, but I would think that "how a firewall uses the public IPs assigned to it" should be minimally configurable and controllable.

I ask because outbound traffic may need to be coordinated with vendors / partners / AzureADConditionalAccessRules / etc for the sake of their firewalls, whereas we may prefer to scale inbound traffic for specific applications, and the default behavior to reuse inbound IPs for outbound traffic makes that difficult if not impossible to manage.

[davidfrazee]

Hey @SBrickeyRCS , all outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP. You can find that information here: Azure Firewall Standard features | Microsoft Learn. So any Public IP that is associated with the Azure Firewall, even if the intent was to use it only for DNAT, will be used for outbound SNAT. 

If you'd like to use a separate set of Public IPs for outbound traffic and to alleviate SNAT exhaustion, you can configure a NAT Gateway on the AzureFirewallSubnet so that the Public IPs associated with the Azure Firewall will be used for inbound only. To find more information about this, you can read more here: Tutorial: Integrate NAT gateway with Azure Firewall in a hub and spoke network - Azure NAT Gateway |...

Thanks

[SBrickeyRCS]

@davidfrazee - thanks for the response.

Currently the firewall is also used to provide policies for outbound traffic. As such the VNet's default route is the firewall. Is the expectation that the firewall forward outbound requests to the NAT Gateway? In that case, what's the point of the firewall's public IP, or can it be removed? Also, what would prevent a malicious VM admin from circumventing the firewall and using the NAT gateway directly?

Further, in our case specifically we would need to ensure that it's compatible with our vWAN configuration (I saw a note in your linked tutorial about the design being incompatible with a "secure vWAN" and I'm unsure of the differences)

Thanks in advance :)

[BlainePerry]

I am trying the scenario described in East-West Traffic Flow (Non-IANA RFC 1918 & Non-IANA RFC 6598 Private Address Space), but I can't seem to get it to work. I see in my logs that the Network rule is allowing the traffic to the public IP address of my destination VM, but my destination VM is not responding. It's not an NSG issue from what I can tell.

Just to make sure I'm understanding correctly, we can associate a public IP address with the NIC of a VM and then we should be able to connect to that VM using the public IP as the destination from a VM on a different subnet (with the following assumptions: source VM subnet has route table with route to Azure Firewall, NSG allows access from source subnet, and network rule is configured on firewall to allow traffic from source to destination)?

[davidfrazee]

@SBrickeyRCS, sorry for the delay in responding. 

We advise that Azure Firewall consumers utilize a NAT Gateway on the subnet of the Azure Firewall to prevent SNAT exhaustion. In this scenario, all outbound traffic is still processed through the firewall and inspected as needed, the only difference is that the outbound traffic will utilize an IP from the NAT Gateway rather than an IP from the Azure Firewall. There is no way to circumvent the path since the NAT Gateway is applied to the AzureFirewallSubnet.

With this scenario, you still need a Public IP on the Azure Firewall. This IP can be used for DNAT rules but is also used for management plane control with Azure Resource Manager (ARM). 

You are correct that NAT Gateway with Azure Firewall in VWAN Hubs is not supported. A way to work around this is to deploy an Azure Firewall on a spoke virtual network that is connected to the VHub and apply the NAT Gateway to the subnet of the firewall there. This Azure Firewall would be used primarily for outbound flows while E-W traffic is still processed through the Azure Firewall in the VHub.

[davidfrazee]

@BlainePerry, for this scenario, we are talking about environments that are not using a traditional RFC 1918 address space to define their virtual network address space. For example, the virtual network has an address space of 20.0.0.0/24, with the VMs pulling private IPs from this range. Although this range is technically in the public IP space, we can still utilize it in Azure for private network routing. 

If you want to apply a public IP to a VM and have a VM from another network access it through the Azure Firewall, you can still force the source VM to direct traffic towards the Azure Firewall. The Azure Firewall will egress this traffic out of its public IP and connect to the VM on that public IP. 

Hope this helps.

[BlainePerry]

Thanks for the response @davidfrazee! Yes, I believe we're talking about the same scenario. I have a situation where I need to use a public IP address (non RFC 1918 address) on our private virtual network. This public IP address should not be accessible from the internet. I believe the scenario you describe in East-West Traffic Flow (Non-IANA RFC 1918 & Non-IANA RFC 6598 Private Address Space) is the same thing, but I guess my main question is how to assign the public IP address to a resource and to confirm that the traffic will flow to the public IP address over the private network.

You said "Since the firewall is aware of a private network path to this address space, it will use the IP of the AzureFirewallSubnet to SNAT rather than use its public IP." SNAT is not a concern (although it's good to know that behavior can be modified), but I just want to confirm that the Azure Firewall will keep the traffic within the private network when connecting to our public IP address.

For the example configuration, you said "The destination is a virtual machine hosted in Azure that uses a public IP space for its network." Does that mean that the VM is assigned a public IP address just like you'd do if you wanted to make the VM accessible from the internet?

(By the way, I know this configuration is a silly way to design your network, but it's required by certain healthcare vendors I've worked with in the past. Previously, I've simply DNATed the public IP to the private IP within an NVA, but I was curious if I could achieve the same result with Azure Firewall.)

[davidfrazee]

@BlainePerry, to associate the non RFC 1918 address space to your VMs, you'll need to make some configuration changes to the Azure Virtual Network. If you go to your virtual network, you'll see 'Address space' on blade menu. Select that and you should be able to see an option to add an additional address range. You can put the public IP network there and then build out your subnets. You may be able to then navigate to the Network Interfaces of the VMs and move them over to the new subnets under the 'IP configurations' section. You can also create a new virtual network and define the public IP space there as the address range and build out the VMs again. I would recommend opening a support ticket if you run into any technical blockers with these moves.

[BlainePerry]

@davidfrazee Thanks so much! This is exactly what I was looking for. I've been working with Azure since before its Resource Manager days, and I'm ashamed to admit that it never occurred to me that you could assign public address space in your virtual networks. Sure enough it says it right there in the first sentence of the first bullet point in the virtual networks concepts documentation. Much appreciated!