Internal Traffic: Comparing Network and Application Rule Sets

This article explores when to use Network Rules or Application Rules in Azure Firewall for internal network scenarios. I’ll walk you through a typical setup, a common issue, and practical ways to resolve it.

Types of Rules in Azure Firewall

Azure Firewall supports three rule types:

• DNAT Rules: These manage traffic that arrives from the internet, targeting a public IP attached to Azure Firewall, and then forward it to a private IP/port inside your Azure network. They work through a type of Network Rule. DNAT Rules aren’t frequently used today, since most apps use HTTP/S and connect through Application Gateway or WAF.
• Application Rules: These control outbound traffic for protocols like HTTP, HTTPS, or MSSQL, which includes Azure SQL and other Azure database solutions.
• Network Rules: These govern general traffic flow for any protocols, to and from any location.

Example Scenario

Consider an internal client such as:

• An on-premises user connecting via private networking
• A user connected through a point-to-site VPN
• A machine in an Azure Virtual Network, either the same as Azure Firewall or a peered virtual network

This client needs to securely connect, using SSL authentication, to a server in a separate virtual network or subnet. The network route goes through Azure Firewall, and to add complexity, the server is a PaaS resource accessed via a Private Endpoint. While this doesn’t change the fundamental problem, it can make troubleshooting more challenging.

Both NSG and firewall rules have been set up appropriately. The client communicates via HTTPS or MSSQL, and this is handled by an Application Rule.

Identifying the Issue

When the client tries to reach the server, the connection fails with application errors like timeouts or SSL/TLS authentication failures.

Your troubleshooting steps may include:

• Azure Firewall logs show the traffic is allowed to pass.
• NSG Flow Logs have no records. This might be confusing until you realize that Private Endpoints don’t create NSG flow logs. Using VNet Flow Logs might help you pinpoint the issue.

You make two key observations:

• If you remove the NSG from the subnet, the connection works—even though the rules seem correct. Traffic from the client should be permitted to the server’s IP/port, matching the Azure Firewall config.
• If you switch the Application Rule to a Network Rule (leaving the NSG as it is), the connection succeeds.

So, the real challenge lies with how Application Rules behave.

Understanding the Cause

Application Rules cause Azure Firewall to perform SNAT (Source Network Address Translation) on connections. This means the server will see the AzureFirewallSubnet’s IP address as the source—not the original client’s IP.

As a result:

• Connections work without the NSG, as there’s no NSG rule to block the SNAT’d source IP.
• The Network Rule works with the NSG because it does not perform SNAT, so the original client’s IP is preserved.

How to Fix the Issue

There are two main ways to fix this:

Option 1: Adjust Application Rules

If you want to stick with Application Rules, update the NSG rule so that its source IP range includes the AzureFirewallSubnet’s address.

However, this leads to:

• NSG and Azure Firewall rules not matching, lowering consistency.
• NSGs no longer allow you to tightly restrict access to only known, approved clients.

Option 2: Use Network Rules

Personally, I recommend using Network Rules for all internal (inbound and east-west) flows. You might lose some Layer-7 features, but essential protections, like IDPS in the Premium SKU, are still available.

With this approach:

• NSGs and Azure Firewall stay aligned, making maintenance easier.
• Traffic restrictions are enforced for specified, documented clients through both Azure Firewall and NSG.

Best Practices for Application Rules

My advice for using rules with Azure Firewall:

• Use DNAT rules only if internet clients need to access Azure resources via Azure Firewall’s public IP (a rare case).
• Use Application Rules specifically for outbound internet access, including Azure resources with public endpoints, through Azure Firewall.
• Apply Network Rules for all other internal traffic patterns.

This strategy helps avoid unexpected issues like the one discussed here and keeps NSG rules consistent and straightforward, with extra controls for traffic within your Azure virtual networks and subnets.