When checking the Logs of our Azure Firewall in Premium SKU I noticed very strange behavior. The source AND destination for allowed traffic do not match the defined rule that allegedly allowed the traffic. Example: I defined a rule like this: Name Source Type Source Protocol Destination Ports Destination TestRule IP Address 10.100.10.0/23 TCP 443 10.100.14.0/24 I then checked the Azure Firewall Logs: AZFWNetworkRule | union AZFWApplicationRule, AZFWNatRule, AZFWThreatIntel, AZFWIdpsSignature | where Rule == "TestRule" | take 100 The results I get look like this: Protocol Source IP Destination IP Destination Port Rule TCP 10.100.34.111 10.100.65.46 443 TestRule I am not comfortable sharing the actual addresses but the logs do show completely different source and destination in the logs which do not match the source and destination defined in the rule. There are multiple rules showing this behavior which is a really big problem especially for firewall logs. In my opinion this can only be classified as a bug. Can anyone come up with a different explanation? I am out of ideas at this point.

Logged Traffic in Azure Firewall does not match Source and Destination defined in Rules

Lukas Lohrsträter 0

When checking the Logs of our Azure Firewall in Premium SKU I noticed very strange behavior.

The source AND destination for allowed traffic do not match the defined rule that allegedly allowed the traffic.

Example:

I defined a rule like this:

Name	Source Type	Source	Protocol	Destination Ports	Destination
TestRule	IP Address	10.100.10.0/23	TCP	443	10.100.14.0/24

I then checked the Azure Firewall Logs:

AZFWNetworkRule
| union AZFWApplicationRule, AZFWNatRule, AZFWThreatIntel, AZFWIdpsSignature
| where Rule == "TestRule"
| take 100

The results I get look like this:

Protocol	Source IP	Destination IP	Destination Port	Rule
TCP	10.100.34.111	10.100.65.46	443	TestRule

I am not comfortable sharing the actual addresses but the logs do show completely different source and destination in the logs which do not match the source and destination defined in the rule.

There are multiple rules showing this behavior which is a really big problem especially for firewall logs. In my opinion this can only be classified as a bug. Can anyone come up with a different explanation? I am out of ideas at this point.

Rohith Vinnakota 1,240 Reputation points Microsoft Vendor

2024-11-19T21:33:01.0766667+00:00

Hi Lukas Lohrsträter

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

Based on our understanding of your issue, there are several factors to consider. Please review the following suggestions.

1.Ensure that there are no overlapping rules that might be affecting the traffic. Sometimes, multiple rules can match a given flow, and the log might be attributing the traffic to a different rule than expected.

2.If there are NAT rules in place, the source or destination IP addresses could be translated. This means that the IPs you see in the logs might be the translated addresses rather than the original ones. Verify if there are any NAT rules that could be modifying the traffic.

3.Azure Firewall Premium includes additional features such as TLS inspection and IDPS. Ensure that these features are not influencing the traffic in unexpected ways. For example, TLS inspection might terminate and re-initiate connections, leading to different IP addresses appearing in the logs.

Kindly let us know if the above helps or you need further assistance on this issue.

Cheers,
Rohith
Lukas Lohrsträter 0 Reputation points

2024-11-20T13:14:57.21+00:00

Hi @Rohith Vinnakota ,

Thank you for your response. It appears the table I included earlier became jumbled—I’ve corrected it in the original question, so I hope it’s clearer now.

The issue in my case is that, according to the logs, the rule matching the traffic shouldn’t actually apply because the source and destination don’t align at all. Neither the source nor the destination fall within the address space defined by the rule that is allegedly matching the traffic. Despite this, the logs specifically reference that exact rule, pointing to the corresponding rule collection group, rule collection, and rule name. This leaves no room for a mix-up.

There are no NAT rules in place, and we are not yet using TLS inspection or IDPS.

Thanks for your assistance

Best regards,

Lukas

Share via

Logged Traffic in Azure Firewall does not match Source and Destination defined in Rules

Your answer