Merge pull request #211786 from vhorne/fw-long-running

add long running session

Author: BCS2022

articles/firewall/long-running-sessions.md

@@ -0,0 +1,50 @@
+---
+title: Long running TCP sessions with Azure Firewall
+description: There are few scenarios where Azure Firewall can potentially drop long running TCP sessions.
+services: firewall
+author: vhorne
+ms.service: firewall
+ms.topic: article
+ms.date: 09/21/2022
+ms.author: victorh 
+---
+
+# Long running TCP sessions with Azure Firewall
+
+Azure Firewall is designed to be available and redundant. Every effort is made to avoid service disruptions. However, there are few scenarios where Azure Firewall can potentially drop long running TCP sessions. 
+
+## Scenarios impacting long running connections
+
+The following scenarios can potentially drop long running TCP sessions:
+- Scale down
+- Firewall maintenance
+- Idle timeout
+- Auto-recovery
+
+### Scale down
+
+Azure Firewall scales up\down based on throughput and CPU usage. Scale down is performed by putting the VM instance in drain mode for 90 seconds before recycling the VM instance. Any long running connections remaining on the VM instance after 90 seconds will be disconnected.
+
+### Firewall maintenance
+
+The Azure Firewall engineering team updates the firewall on an as-needed basis (usually every month), generally during night time hours in the local time-zone for that region.  Updates include security patches, bug fixes, and new feature roll outs that are applied by configuring the firewall in a [rolling update mode](https://azure.microsoft.com/blog/deployment-strategies-defined/). The firewall instances are put in a drain mode before reimaging them to give short-lived sessions time to drain. Long running sessions remaining on an instance after the drain period are dropped during the restart.
+
+### Idle timeout
+
+An idle timer is in place to recycle idle sessions. The default value is four minutes. Applications that maintain keepalives don't idle out. If the application needs more than 4 minutes (typical of IOT devices), you can contact support to extend the time to 30 minutes in the backend.
+
+### Auto-recovery
+
+Azure Firewall constantly monitors VM instances and recovers them automatically in case any instance goes unresponsive. In general, there's a 1 in 100 chance for a firewall instance to be auto-recovered over a 30 day period.
+
+## Applications sensitive to TCP session resets
+
+Session disconnection isn’t an issue for resilient applications that can handle session reset gracefully. However, there are few applications (like traditional SAP GUI and SAP RFC based apps) which are sensitive to sessions resets. Secure such sensitive applications with Network Security Groups (NSGs).
+
+## Network security groups
+
+You can deploy [network security groups](../virtual-network/virtual-network-vnet-plan-design-arm.md#security) (NSGs) to protect against unsolicited traffic into Azure subnets. Network security groups are simple, stateful packet inspection devices that use the 5-tuple approach (source IP, source port, destination IP, destination port, and layer 4 protocol) to create allow/deny rules for network traffic. You allow or deny traffic to and from a single IP address, to and from multiple IP addresses, or to and from entire subnets. NSG flow logs help with auditing by logging information about IP traffic flowing through an NSG.  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).
+
+## Next steps
+
+To learn more about Azure Firewall performance, see [Azure Firewall performance](firewall-performance.md).

articles/firewall/toc.yml

@@ -91,6 +91,8 @@ items:
       href: ftp-support.md
     - name: Performance
       href: firewall-performance.md
+    - name: Long running TCP sessions
+      href: long-running-sessions.md
 - name: How-to guides
   items:
     - name: Deploy and configure - classic