While troubleshooting a particular DNAT rule implemented with Azure Firewall, we noticed the outside traffic was not reaching the targeted VM as intended.

In order to troubleshoot this, we first inspected the Azure Firewall logs in Azure Log Analytics to confirm the traffic was indeed hitting the proper NAT rule. Here’s the query that was used in Log Analytics to determine this:

AzureDiagnostics

| where Category == “AzureFirewallNetworkRule”and msg_s contains”DNAT”

Here’s what the result of the query looked like:

Once we were able to confirm the traffic was hitting the right rule, we then proceeded to loosen the NSG rules applied to the subnet for the VM and then used a network capture tool such as tcpdump to determine what source IP was showing up for the traffic that was DNATed by Azure Firewall. For example, here’s what the tcpdump looked like:

sudo tcpdump ‘port <DNATed port number> and !host <my ip>’

Note that my internal IP is excluded so that I can see only the traffic coming from outside Azure for a particular DNATed port.

By using this, we were able to determine the source IP seen was from the AzureFirewall subnet but not exactly the internal IP being shown in the portal. That is mostly likely due to the HA/load balanced setup for Azure Firewall requiring multiple instances to operate. Once we added the appropriate address to the NSG rule, the traffic was flowing properly to the VM and the NSG was re-tighten for the pleasure of our security folks!