Merge pull request #295726 from varunkalyana/fwnat

Firewall - LB Integration (Add NATGW integration)

Author: Stacyrch140

articles/firewall/integrate-lb.md

@@ -2,18 +2,18 @@
 title: Integrate Azure Firewall with Azure Standard Load Balancer
 description: You can integrate an Azure Firewall into a virtual network with an Azure Standard Load Balancer (either public or internal).
 services: firewall
-author: duongau
+author: varunkalyana
 ms.service: azure-firewall
 ms.topic: how-to
-ms.date: 06/14/2024
+ms.date: 03/04/2025
 ms.author: duau
 ---
 
 # Integrate Azure Firewall with Azure Standard Load Balancer
 
-You can integrate an Azure Firewall into a virtual network with an Azure Standard Load Balancer (either public or internal). 
+You can integrate an Azure Firewall into a virtual network with either a public or internal Azure Standard Load Balancer.
 
-The preferred design is to integrate an internal load balancer with your Azure firewall, as this is a simpler design. You can use a public load balancer if you already have one deployed and you want to keep it in place. However, you need to be aware of an asymmetric routing issue that can break functionality with the public load balancer scenario.
+The preferred design is to use an internal load balancer with your Azure Firewall, as it simplifies the setup. If you already have a public load balancer deployed and wish to continue using it, be aware of potential asymmetric routing issues that could disrupt functionality.
 
 For more information about Azure Load Balancer, see [What is Azure Load Balancer?](../load-balancer/load-balancer-overview.md)
 
@@ -27,42 +27,68 @@ Asymmetric routing is where a packet takes one path to the destination and takes
 
 ### Fix the routing issue
 
-When you deploy an Azure Firewall into a subnet, one step is to create a default route for the subnet directing packets through the firewall's private IP address located on the AzureFirewallSubnet. For more information, see [Tutorial: Deploy and configure Azure Firewall using the Azure portal](tutorial-firewall-deploy-portal.md#create-a-default-route).
+#### Scenario 1: Azure Firewall without NAT Gateway
+When deploying an Azure Firewall into a subnet, you need to create a default route for the subnet. This route directs packets through the firewall's private IP address located on the AzureFirewallSubnet. For detailed steps, see [Deploy and configure Azure Firewall using the Azure portal](tutorial-firewall-deploy-portal.md#create-a-default-route).
+When integrating the firewall into your load balancer scenario, ensure that your Internet traffic enters through the firewall's public IP address. The firewall applies its rules and NAT the packets to the load balancer's public IP address. The issue arises when packets arrive at the firewall's public IP address but return via the private IP address (using the default route).
 
-When you introduce the firewall into your load balancer scenario, you want your Internet traffic to come in through your firewall's public IP address. From there, the firewall applies its firewall rules and NATs the packets to your load balancer's public IP address. This is where the problem occurs. Packets arrive on the firewall's public IP address, but return to the firewall via the private IP address (using the default route).
-To avoid this problem, create another host route for the firewall's public IP address. Packets going to the firewall's public IP address are routed via the Internet. This avoids taking the default route to the firewall's private IP address.
+To prevent asymmetric routing, add a specific route for the firewall's public IP address. Packets intended for the firewall's public IP address are directed through the Internet, bypassing the default route to the firewall's private IP address.
 
-:::image type="content" source="media/integrate-lb/Firewall-LB-asymmetric.png" alt-text="Diagram of asymmetric routing." lightbox="media/integrate-lb/Firewall-LB-asymmetric.png":::
-### Route table example
+:::image type="content" source="media/integrate-lb/Firewall-LB-asymmetric.png" alt-text="Diagram of asymmetric routing and the workaround solution." lightbox="media/integrate-lb/Firewall-LB-asymmetric.png":::
 
-For example, the following routes are for a firewall at public IP address 203.0.113.136, and private IP address 10.0.1.4.
+##### Route table example
+
+For example, the following route table shows routes for a firewall with a public IP address of 203.0.113.136 and a private IP address of 10.0.1.4.
 
 :::image type="content" source="media/integrate-lb/route-table.png" lightbox="media/integrate-lb/route-table.png" alt-text="Screenshot of route table.":::
+
+#### Scenario 2: Azure Firewall with NAT Gateway
+
+In some scenarios, you might configure a NAT Gateway on the Azure Firewall subnet to overcome SNAT (Source Network Address Translation) port limitations for outbound connectivity. In these cases, the route configuration in Scenario 1 doesn't work because the NAT Gateway's public IP address takes precedence over the Azure Firewall's public IP address.
+
+For more information, see [Integration of NAT Gateway with Azure Firewall](../nat-gateway/tutorial-hub-spoke-nat-firewall.md).
+
+:::image type="content" source="media/integrate-lb/nat-firewall-routing.png" alt-text="Diagram of routing with NAT Gateway associated to the Azure Firewall subnet.":::
+
+When a NAT Gateway is associated with the Azure Firewall subnet, inbound traffic from the internet lands on the Azure Firewall's public IP address. The Azure Firewall then changes (SNAT) the source IP to the NAT Gateway's public IP address before forwarding the traffic to the load balancer's public IP address.
+
+Without a NAT Gateway, the Azure Firewall changes the source IP address to its own public IP address before forwarding the traffic to the load balancer's public IP address.
+
+> [!IMPORTANT]
+> Allow the NAT Gateway public IP address or public prefixes in the Network Security Group (NSG) rules associated with the resource (AKS/VM) subnet.
+
+##### Route table example with NAT Gateway
+
+You must add a route for the return path to use the NAT Gateway public IP address instead of the Azure Firewall public IP address with Internet as the next hop.
+
+For example, the following route table shows routes for a NAT Gateway with a public IP address of 198.51.100.101 and a firewall with a private IP address of 10.0.1.4.
+
+:::image type="content" source="media/integrate-lb/firewall-route-table.png" alt-text="Screenshot of the route table showing a route with the destination as the NAT Gateway Public IP address and the next hop as Internet.":::
+
 ### NAT rule example
 
-In the following example, a NAT rule translates RDP traffic to the firewall at 203.0.113.136 over to the load balancer at 203.0.113.220:
+In both scenarios, a NAT rule translates RDP (Remote Desktop Protocol) traffic from the firewall's public IP address (203.0.113.136) to the load balancer's public IP address (203.0.113.220):
 
 :::image type="content" source="media/integrate-lb/nat-rule-02.png" lightbox="media/integrate-lb/nat-rule-02.png" alt-text="Screenshot of NAT rule.":::
+
 ### Health probes
 
-Remember, you need to have a web service running on the hosts in the load balancer pool if you use TCP health probes to port 80, or HTTP/HTTPS probes.
+Remember to have a web service running on the hosts in the load balancer pool if you use TCP (Transport Control Protocol) health probes on port 80, or HTTP/HTTPS probes.
 
 ## Internal load balancer
 
-With an internal load balancer, the load balancer is deployed with a private frontend IP address.
-
-There's no asymmetric routing issue with this scenario. The incoming packets arrive at the firewall's public IP address, get translated to the load balancer's private IP address, and then returns to the firewall's private IP address using the same return path.
+An internal load balancer is deployed with a private frontend IP address.
 
-So, you can deploy this scenario similar to the public load balancer scenario, but without the need for the firewall public IP address host route.
+This scenario doesn't have asymmetric routing issues. Incoming packets arrive at the firewall's public IP address, are translated to the load balancer's private IP address, and return to the firewall's private IP address using the same path.
 
-The virtual machines in the backend pool can have outbound Internet connectivity through the Azure Firewall. Configure a user defined route on the virtual machine's subnet with the firewall as the next hop.
+Deploy this scenario similarly to the public load balancer scenario, but without needing the firewall public IP address host route.
 
+Virtual machines in the backend pool can have outbound Internet connectivity through the Azure Firewall. Configure a user-defined route on the virtual machine's subnet with the firewall as the next hop.
 
 ## Extra security
 
-To further enhance the security of your load-balanced scenario, you can use network security groups (NSGs).
+To further enhance the security of your load-balanced scenario, use network security groups (NSGs).
 
-For example, you can create an NSG on the backend subnet where the load-balanced virtual machines are located. Allow incoming traffic originating from the firewall IP address/port.
+For example, create an NSG on the backend subnet where the load-balanced virtual machines are located. Allow incoming traffic originating from the firewall's public IP address and port. If a NAT Gateway is associated with the Azure Firewall subnet, allow incoming traffic originating from the NAT Gateway's public IP address and port.
 
 :::image type="content" source="media/integrate-lb/nsg-01.png" alt-text="Screenshot of network security group." lightbox="media/integrate-lb/nsg-01.png":::