rewrite

Author: duongau

articles/firewall/long-running-sessions.md

@@ -1,61 +1,64 @@
 ---
-title: Azure Firewall idle timeout and long-running TCP sessions
-description: Understand TCP idle timeout behavior and scenarios where Azure Firewall can drop long-running TCP sessions.
+title: Azure Firewall TCP session behavior
+description: Learn about the behavior of long-running sessions and TCP idle timeout for Azure Firewall.
 services: firewall
 author: sujamiya
 ms.service: azure-firewall
 ms.topic: concept-article
-ms.date: 03/21/2025
+ms.date: 03/25/2025
 ms.author: duau
 ---
 
-# TCP idle timeout behavior and long-running TCP sessions in Azure Firewall
+# Azure Firewall TCP session behavior
 
-This article explains the TCP idle timeout and the behavior of long-running sessions in Azure Firewall. Understanding how these settings work is crucial for maintaining a secure and efficient network environment.
+This article explains the behavior of long-running sessions and the TCP idle timeout for Azure Firewall. Understanding these concepts is crucial for maintaining network security, optimizing firewall resources, and ensuring uninterrupted connectivity for critical applications.
 
 ## Long-running TCP sessions
 ---
 
-Azure Firewall is built for high availability and redundancy, aiming to minimize service disruptions. However, certain scenarios can still lead to the dropping of long-running TCP sessions. Long-running sessions are TCP connections that remain active for extended periods. These are commonly used in applications such as SSH, RDP, VPN tunnels, and database connections. To ensure these sessions remain connected, specific configurations are required.
+Long-running sessions refer to TCP connections that stay active for extended durations. These are often utilized in applications like SSH, RDP, VPN tunnels, and database connections. To prevent unexpected disconnections, it's essential to configure these sessions appropriately. Understanding the factors that influence their stability is key to ensuring uninterrupted connectivity.
 
-The following Azure Firewall scenarios can potentially drop long-running TCP sessions:
+Certain scenarios can lead to the dropping of long-running TCP sessions. Azure Firewall is designed to handle a large number of concurrent connections, but it might not be able to maintain long-running sessions under certain conditions.
 
-- **Scale-in**: When Azure Firewall scales in, it puts the instance in drain mode for 90 seconds before recycling. Any long-running connections still active after this period are disconnected.
-- **Firewall maintenance**: During maintenance updates, the firewall enters drain mode to allow short-lived sessions to complete. Long-running sessions that remain after the drain period are dropped during the restart.
-- **Autorecovery**: If an Azure Firewall instance becomes unresponsive, it will automatically recovered. This process can result in the disconnection of long-running sessions.
-- **Idle timeout**: Idle sessions are recycled based on the TCP idle timeout settings.
+The following scenarios in Azure Firewall can result in the termination of long-running TCP sessions:
+
+- **Scale-in**: When Azure Firewall scales in, it enters a drain mode for 90 seconds before recycling the instance. Any long-running connections still active after this period gets disconnected.
+
+- **Firewall maintenance**: During maintenance updates, Azure Firewall allows short-lived sessions to complete. However, long-running sessions that persist beyond the drain period are terminated during the restart process.
+
+- **Autorecovery**: If an Azure Firewall instance becomes unresponsive, it undergoes an automatic recovery process. This recovery can lead to the disconnection of long-running sessions.
+
+- **Idle timeout**: Connections that remain inactive for a duration exceeding the TCP idle timeout gets closed by the Azure Firewall.
 
 ## Idle timeout settings
 ---
 
 The TCP idle timeout specifies the duration a connection can stay inactive before the Azure Firewall terminates the connection. This setting helps optimize the Azure Firewall by closing inactive connections and maintaining overall network performance.
 
-Configuring the TCP idle timeout properly can:
+The TCP idle timeout provides several benefits:
 
-- **Optimize Azure Firewall resources**: Frees up memory and compute resources by closing inactive connections.
-- **Mitigate DDoS risks**: Reduces the risk of attacks that exploit persistent idle connections.
-- **Enhance network performance**: Improves throughput and reduces latency by effectively managing idle connections.
+- **Efficient resource utilization**: By terminating inactive connections, the Azure Firewall conserves memory and compute resources, ensuring optimal performance.
+- **DDoS risk mitigation**: Helps protect against Distributed Denial-of-Service (DDoS) attacks that exploit idle, persistent connections.
+- **Improved network performance**: Enhances overall throughput and reduces latency by managing idle connections effectively.
 
 ### Timeout behavior
 
-In the aspect of the Azure Firewall, **north-south** traffic refers to the traffic that flows between the Azure Firewall and the Internet, while **east-west** traffic refers to the traffic that flows between Azure resources within the same region or across regions. This also includes traffic between Azure resources and on-premises resources connected through Azure VPN, Azure ExpressRoute, and Virtual network peering. The TCP idle timeout behavior in Azure Firewall is different for north-south and east-west traffic. 
+In the context of Azure Firewall, **north-south traffic** refers to traffic between the Azure Firewall and the Internet, while **east-west traffic** refers to internal traffic between Azure resources within the same region, across regions, and on-premises networks connected through Azure VPN, Azure ExpressRoute, or Virtual Network Peering going through the Azure Firewall. 
+
+The TCP idle timeout behavior differs for north-south and east-west traffic:
 
-- **North-south**: The default TCP idle timeout is set to **4 minutes** to maintain active connections. You can increase the timeout to a maximum of **15 minutes** by submitting a support request through the Azure portal.
-- **East-west**: There's a **5 minutes** TCP idle timeout on the Azure Firewall. This timeout isn't configurable. 
+- **North-south traffic**: The default TCP idle timeout is **4 minutes**. You can extend this timeout to a maximum of **15 minutes** by submitting a support request through the Azure portal.
+- **East-west traffic**: The TCP idle timeout is fixed at **5 minutes** and can't be modified.
 
-## Applications sensitive to TCP session reset
+### TCP reset packets (RST)
 
-Some applications, such as traditional SAP GUI and SAP RFC (Remote Function Call) based apps, are sensitive to TCP session resets.
+When a TCP connection is terminated due to an idle timeout, the Azure Firewall sends a TCP reset packet (RST) to both the client and server. This packet notifies both parties that the connection closed. The behavior of TCP reset packets differs for north-south and east-west traffic.
 
-> [!TIP]
-> To avoid connectivity issues, configure a keep-alive mechanism within your application that communicates through the Azure Firewall for east-west traffic. This ensures that long-running sessions remain active and aren't affected by the idle timeout settings.
+- **North-south traffic**: The Azure Firewall notifies both the client and server when an idle timeout occurs by send a TCP reset packet (RST).
+- **East-west traffic**: Azure Firewall doesn't send a reset packet (RST) when an idle timeout occurs. This behavior can cause unexpected issues in applications. Configure a keep-alive mechanism within your application to keep long-running sessions active and prevent disruptions during scale-in, maintenance, or autorecovery events.
 
-> [!IMPORTANT]
-> - **North-south traffic**: The Azure Firewall sends a reset packet (RST) to both the source and destination when an idle timeout occurs.
-> - **East-west traffic**: The Azure Firewall doesn't send a reset packet (RST) when an idle timeout occurs.
+Certain applications, such as traditional SAP GUI and SAP Remote Function Call (RFC)-based applications, are sensitive to session resets and can experience connectivity issues when sessions are terminated unexpectedly. To avoid these issues, you can implement a retry logic in your application to handle session resets gracefully. This mechanism should include logic to re-establish connections and resume operations seamlessly.
 
 ## Next steps
 
-- To protect and monitor you applications, use [Network security groups](../virtual-network/network-security-groups-overview.md) and [How to secure a virtual network](../virtual-network/virtual-network-vnet-plan-design-arm.md#security).
-- To learn more about Azure Firewall performance, see [Azure Firewall performance](firewall-performance.md).
-- To learn more about NSG flow logging, see [Introduction to flow logging for network security groups](../network-watcher/network-watcher-nsg-flow-logging-overview.md).
+To learn more about Azure Firewall performance, see [Azure Firewall performance](firewall-performance.md).