Logging and Metrics Enhancements to Azure Firewall now in Preview

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

Introduction:  

Azure Firewall is a cloud-native network firewall security service that provides threat protection for your cloud workloads running in Azure. It is a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. Azure Firewall sits between the end user and the application server, processing critical application traffic and enforcing security policies on this traffic. In case of any latency or disconnection to the application, the firewall acts as a great point to look at this traffic and troubleshoot the root cause. Azure Firewall now offers new logging and metric enhancements designed to increase visibility and provide more insights into the traffic processed by the firewall. 

 

  1. Latency Probe Metric – In Preview 
  2. Flow Trace Logs – In Preview
  3. Top Flows – In Preview 

  

Latency Probe Metric:  

Latency in network infrastructure can increase due to various factors. Monitoring the latency of the firewall is essential for proactively identifying potential issues with traffic or services in the infrastructure. The Latency Probe metric measures the overall latency of Azure Firewall and provides insight into the health of the service. IT administrators can use this metric for monitoring and alerting if there is observable latency and diagnosing if Azure Firewall is causing latency in a network. If Azure Firewall is experiencing latency, it could be due to various reasons such as high CPU utilization, traffic throughput, or networking issues. It’s important to note that this tool is powered by Pingmesh technology, which means that it measures the average latency of the firewall itself. The metric does not measure end-to-end latency or the latency of individual packets.  

Note: As a reference, the average expected latency for a firewall is approximately 1m/s. This may vary depending on deployment size and environment. 

  

Screenshot 2023-05-10 203456.png

Flow Trace Logs: 

Azure Firewall logs different types of traffic, such as network, application, and threat intelligence traffic etc. These logs only show the first attempt of a TCP connection, which is the SYN packet. But this does not show the whole process of the TCP handshake. To see every packet that goes through the firewall and to find out if there are any packet drops or asymmetric routes, you need more information. Asymmetric routing happens when a packet goes one way to the firewall and another way back to the source. This can be caused by user errors, such as adding a wrong route in the firewall path. Azure Firewall is a stateful firewall that keeps track of state connections and allows traffic to come back to the firewall automatically and dynamically. To check if a packet went through the firewall successfully or if there was asymmetric routing, you can use Flow Trace to see more TCP handshake logs. You can look at the network logs to see the first SYN packet and click “enable Flow Trace” to see more flags for verification:  

 

  • SYN-ACK  
  • FIN  
  • FIN-ACK  
  • RST  
  • INVALID  

 

image2flowtrace.png

By adding these additional flags in Flow Trace logs, IT administrators can now see the return packet if there was a failed connection or an unrecognized packet. To enable these logs, please read the documentation here. 

 

For Instance, let’s say in the below example, SourceIP 10.10.0.68 is trying to connect to the Destination IP 10.10.0.132 on destination Port RDP 3389 with a random source port 51369. We have set up an asymmetric routing scenario where we made sure that this traffic is not routed through the firewall, however, the return traffic is configured to go through the firewall that is from 10.10.0.132 to 10.10.0.68 with source port 3389 and destination port 51369. In this case, by using the Flow Trace Logs, we can clearly see if there is an invalid packet that is not recognized by the Firewall that could be causing the connection issues. 

 

NologsAssymetricrouting.png

As we can see in the above image, when we look at the initial traffic on the firewall there are no logs as expected as the firewall was not in the path. However, when we look at AZFWFlowTrace logs, we can see that there is a log for the return traffic in the opposite direction and this packet has been marked as invalid by the firewall as the Azure Firewall is stateful and keeps track of TCP connections. In this way we can easily troubleshoot different asymmetric routing scenarios and invalid TCP connections using the new Flow Trace logs. 

  

returninvalidlog.png

Top Flows:  

Microsoft Azure Firewall Standard can support up to 30 Gbps and Azure Firewall Premium can support up to 100 Gbps of traffic processing. However, sometimes traffic flows can either be unintentionally or intentionally “heavy” depending on the size, duration, and other factors of the packets. These flows can potentially impact other flows and the processing of the firewall. Therefore, it’s important to monitor these traffic flows to ensure that the firewall can perform optimally. 

The Top Flows log—or industry-known as Fat Flows—log shows the top connections that are contributing to the highest bandwidth in a given time frame through the firewall. This visibility provides the following benefits for IT administrators: 

  • Identifying the top traffic flows traversing through the firewall. 
  • Identifying any unexpected or anomaly traffic. 
  • Deciding what traffic should be allowed or denied based on results and goals. 

image3fatflow.png

Note: Because of the CPU impact, enable Top flows only when you need to troubleshoot a specific issue. The recommendation is to enable Top flows no longer than one week at a time. 

 

Conclusion:  

These new logging and metric improvements enable security administrators to gain more visibility into the traffic flowing through the Azure Firewall. This will help them troubleshoot and analyse the root causes more effectively. 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.