This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

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