文章讨论了在Azure Firewall中使用Network Rules或Application Rules处理内部流量的情况，包括规则类型、常见场景、出现的问题及解决方案等。

🎯Azure Firewall中有DNAT Rules、Application Rules和Network Rules三种规则类型。DNAT Rules控制来自互联网的流量，Application Rules控制流向HTTP、HTTPS或MSSQL的流量，Network Rules控制任意流向的流量。

📋文中提到一种内部客户端连接服务器的场景，客户端可能通过多种方式连接，连接需SSL认证，服务器通过Azure Firewall的路由连接到另一个虚拟网络/子网。

💡当客户端连接服务器出现问题时，经排查发现是Application Rule进行SNAT导致的。解决方法有修改NSG规则以继续使用Application Rules，或使用Network Rules，各有优缺点。

📖文章还提到了何时使用不同规则的建议，如DNAT Rules用于特定情况，Application Rules用于出站连接到互联网，Network Rules用于其他情况。

This post is about using either Network Rules or Application Rules in Azure Firewall for internal traffic. I’m going to discuss a common scenario, a “problem” that can occur, and how you can deal with that problem.

The Rules Types

There are three kinds of rules in Azure Firewall:

DNAT Rules: Control traffic originating from the Internet, directed to a public IP address attached to Azure Firewall, and translated to a private IP Address/port in an Azure virtual network. This is implicitly applied as a Network Rule. I rarely use DNAT Rules – most modern applications are HTTP/S and enter the virtual network(s) via an Application Gateway/WAF.Application Rules: Control traffic going to HTTP, HTTPS, or MSSQL (including Azure database services).Network Rules: Control anything going anywhere.

The Scenario

We have an internal client, which could be:

On-premises over private networkingConnecting via point-to-site VPNConnected to a virtual network, either the same as the Azure Firewall or to a peered virtual network.

The client needs to connect to a server, with SSL authentication, to a server. The server is connected to another virtual network/subnet. The route to the server goes through the Azure Firewall. I’ll complicate things by saying that the server is a PaaS resource with a Private Endpoint – this doesn’t affect the core problem but it makes troubleshooting more difficult

NSG rules and firewall rules have been accounted for and created. The essential connection is either HTTPS or MSSQL and is implemented as an Application Rule.

The Problem

The client attempts a connection to the server. You end up with some type of application error stating that there was either a timeout or a problem with SSL/TLS authentication.

You begin to troubleshoot:

Azure Firewall shows the traffic is allowed.NSG Flow Logs show nothing – you panic until you remember/read that Private Endpoints do not generate flow logs – I told you that I’d complicate things You can consider VNet Flow Logs to try to capture this data and then you might discover the cause.

You try and discover two things:

If you disconnect the NSG from the subnet then the connection is allowed. Hmm – the rules are correct so the traffic should be allowed: traffic from the client prefix(es) is permitted to the server IP address/port. The rules match the firewall rules.You change the Application Rule to a Network Rule (with the NSG still associated and unchanged) and the connection is allowed.

So, something is going on with the Application Rules.

The Root Cause

In this case, the Application Rule is SNATing the connection. In other words, when the connection is relayed from the Azure Firewall instance to the server, the source IP is no longer that of the client; the source IP address is a compute instance in the AzureFirewallSubnet.

That is why:

The connection works when you remove the NSGThe connection works when you use a Network Rule with the NSG – the Network Rule does not SNAT the connection.

Solutions

There are two solutions to the problem:

Using Application Rules

If you want to continue to use Application Rules then the fix is to modify the NSG rule. Change the source IP prefix(es) to be the AzureFirewallSubnet.

The downsides to this are:

The NSG rules are inconsistent with the Azure Firewall rules.The NSG rules are no longer restricting traffic to documented approved clients.

Using Network Rules

My preference is to use Network Rules for all inbound and east-west traffic. Yes, we lose some of the “Layer-7” features but we still have core features, including IDPS in the Premium SKU.

Contrary to using Application Rules:

The NSG rules are consistent with the Azure Firewall rules.The NSG rules restrict traffic to the documented approved clients.

When To Use Application Rules?

In my sessions/classes, I teach:

Use DNAT rules for the rare occasion where Internet clients will connect to Azure resources via the public IP address of Azure Firewall.Use Application Rules for outbound connections to Internet, including Azure resources via public endpoints, through the Azure Firewall.Use Network Rules for everything else.

This approach limits “weird sh*t” errors like what is described above and means that NSG rules are effectively clones of the Azure Firewall rules, with some additional stuff to control stuff inside of the Virtual Network/subnet.

The post Network Rules Versus Application Rules for Internal Traffic first appeared on Aidan Finn, IT Pro.