Merge pull request #226201 from BeatrizSilv/patch-9

Update private-link-inspection-secure-virtual-hub.md

Author: v-dirichards

articles/firewall-manager/private-link-inspection-secure-virtual-hub.md

@@ -18,45 +18,60 @@ ms.author: kumud
 
 Private endpoints allow resources access to the private link service deployed in a virtual network. Access to the private endpoint through virtual network peering and on-premises network connections extend the connectivity.
 
-You may need to filter traffic from clients either on premises or in Azure destined to services exposed via private endpoints in a Virtual WAN connected virtual network. This article walks you through this task using [secured virtual hub](../firewall-manager/secured-virtual-hub.md) with [Azure Firewall](../firewall/overview.md) as the security provider.
+You may need to filter traffic from clients either on-premises or in Azure destined to services exposed via private endpoints in a Virtual WAN connected virtual network. This article walks you through this task using [secured virtual hub](../firewall-manager/secured-virtual-hub.md) with [Azure Firewall](../firewall/overview.md) as the security provider.
 
 Azure Firewall filters traffic using any of the following methods:
 
 * [FQDN in network rules](../firewall/fqdn-filtering-network-rules.md) for TCP and UDP protocols
 * [FQDN in application rules](../firewall/features.md#application-fqdn-filtering-rules) for HTTP, HTTPS, and MSSQL.
 * Source and destination IP addresses, port, and protocol using [network rules](../firewall/features.md#network-traffic-filtering-rules)
 
-Use application rules over network rules to inspect traffic destined to private endpoints.
+Application rules are preferred over network rules to inspect traffic destined to private endpoints because Azure Firewall always SNATs traffic with application rules. SNAT is recommended when inspecting traffic destined to a private endpoint due to the limitation described here: [What is a private endpoint?][private-endpoint-overview]. If you're planning on using network rules instead, it is recommended to configure Azure Firewall to always perform SNAT: [Azure Firewall SNAT private IP address ranges][firewall-snat-private-ranges].
+
 A secured virtual hub is managed by Microsoft and it cannot be linked to a [Private DNS Zone](../dns/private-dns-privatednszone.md). This is required to resolve a [private link resource](../private-link/private-endpoint-overview.md#private-link-resource) FQDN to its corresponding private endpoint IP address.
 
 SQL FQDN filtering is supported in [proxy-mode](/azure/azure-sql/database/connectivity-architecture#connection-policy) only (port 1433). *Proxy* mode can result in more latency compared to *redirect*. If you want to continue using redirect mode, which is the default for clients connecting within Azure, you can filter access using FQDN in firewall network rules.
 
-## Filter traffic using FQDN in network and application rules
+## Filter traffic network or application rules in Azure Firewall
+
+The following steps enable Azure Firewall to filter traffic using either network rules (FQDN or IP address-based) or application rules:
 
-The following steps enable Azure Firewall to filter traffic using FQDN in network and application rules:
+### Network rules:
 
 1. Deploy a [DNS forwarder](../private-link/private-endpoint-dns.md#virtual-network-and-on-premises-workloads-using-a-dns-forwarder) virtual machine in a virtual network connected to the secured virtual hub and linked to the Private DNS Zones hosting the A record types for the private endpoints.
 
-2. Configure [custom DNS settings](../firewall/dns-settings.md#configure-custom-dns-servers---azure-portal) to point to the DNS forwarder virtual machine IP address and enable DNS proxy in the firewall policy associated with the Azure Firewall deployed in the secured virtual hub.
+2. Configure [custom DNS servers](../virtual-network/manage-virtual-network.md#change-dns-servers) for the virtual networks connected to the secured virtual hub:
+   - **FQDN-based network rules** - configure [custom DNS settings](../firewall/dns-settings.md#configure-custom-dns-servers---azure-portal) to point to the DNS forwarder virtual machine IP address and enable DNS proxy in the firewall policy associated with the Azure Firewall. Enabling DNS proxy is required if you want to do FQDN filtering in network rules.
+   - **IP address-based network rules** - the custom DNS settings described in the previous point are **optional**. You can simply configure the custom DNS servers to point to the private IP of the DNS forwarder virtual machine.
+
+3. Depending on the configuration chosen in step **2.**, configure on-premises DNS servers to forward DNS queries for the private endpoints **public DNS zones** to either the private IP address of the Azure Firewall, or of the DNS forwarder virtual machine.
+
+4. Configure a [network rule](../firewall/tutorial-firewall-deploy-portal.md#configure-a-network-rule) as required in the firewall policy associated with the Azure Firewall. Choose *Destination Type* IP Addresses  if going with an **IP address-based** rule and configure the IP address of the private endpoint as *Destination*. For **FQDN-based** network rules, choose *Destination Type* FQDN and configure the private link resource public FQDN as *Destination*.
 
-3. Configure [custom DNS servers](../virtual-network/manage-virtual-network.md#change-dns-servers) for the virtual networks connected to the secured virtual hub to point to the private IP address associated with the Azure Firewall deployed in the secured virtual hub.
+5. Navigate to the firewall policy associated with the Azure Firewall deployed in the secured virtual hub. Select *Private IP ranges (SNAT)* and select the option to *Always perform SNAT*.
 
-4. Configure on premises DNS servers to forward DNS queries for the private endpoints public DNS zones to the private IP address associated with the Azure Firewall deployed in the secured virtual hub.
+### Application rules:
 
-5. Configure an [application rule](../firewall/tutorial-firewall-deploy-portal.md#configure-an-application-rule) or [network rule](../firewall/tutorial-firewall-deploy-portal.md#configure-a-network-rule) as necessary in the firewall policy associated with the Azure Firewall deployed in the secured virtual hub with *Destination Type* FQDN and the private link resource public FQDN as *Destination*.
+1. For application rules, steps **1.** to **3.** from the previous section still apply. For the custom DNS server configuration, you can either choose to use the Azure Firewall as DNS proxy, or point to the DNS forwarder virtual machine directly.
 
-6. Navigate to *Secured virtual hubs* in the firewall policy associated with the Azure Firewall deployed in the secured virtual hub and select the secured virtual hub where traffic filtering destined to private endpoints will be configured.
+2. Configure an [application rule](../firewall/tutorial-firewall-deploy-portal.md#configure-an-application-rule) as required in the firewall policy associated with the Azure Firewall. Choose *Destination Type* FQDN and the private link resource public FQDN as *Destination*.
 
-7. Navigate to **Security configuration**, select **Send via Azure Firewall** under **Private traffic**.
+Lastly, and regardless of the type of rules configured in the Azure Firewall, make sure [Network Policies][network-policies-overview] (at least for UDR support) are enabled in the subnet(s) where the private endpoints are deployed. This will ensure traffic destined to private endpoints will not bypass the Azure Firewall. 
 
-8. Select **Private traffic prefixes** to edit the CIDR prefixes that will be inspected via Azure Firewall in secured virtual hub and add one /32 prefix for each private endpoint as follows:
+ > [!IMPORTANT]
+   > By default, RFC 1918 prefixes are automatically included in the *Private Traffic Prefixes* of the Azure Firewall. For most private endpoints, this will be enough to make sure traffic from on-premises clients, or in different virtual networks connected to the same secured hub, will be inspected by the firewall. In case traffic destined to private endpoints is not being logged in the firewall, try adding the /32 prefix for each private endpoint to the list of *Private Traffic Prefixes*. 
 
-   > [!IMPORTANT]
-   > If these /32 prefixes are not configured, traffic destined to private endpoints will bypass Azure Firewall.
+If needed, you can edit the CIDR prefixes that will be inspected via Azure Firewall in a secured hub as follows:
+
+1. Navigate to *Secured virtual hubs* in the firewall policy associated with the Azure Firewall deployed in the secured virtual hub and select the secured virtual hub where traffic filtering destined to private endpoints will be configured.
+
+2. Navigate to **Security configuration**, select **Send via Azure Firewall** under **Private traffic**.
+
+3. Select **Private traffic prefixes** to edit the CIDR prefixes that will be inspected via Azure Firewall in secured virtual hub and add one /32 prefix for each private endpoint.
 
    :::image type="content" source="./media/private-link-inspection-secure-virtual-hub/firewall-manager-security-configuration.png" alt-text="Firewall Manager Security Configuration" border="true":::
 
-These steps only work when the clients and private endpoints are deployed in different virtual networks connected to the same secured virtual hub and for on premises clients. If the clients and private endpoints are deployed in the same virtual network, a UDR with /32 routes for the private endpoints must be created. Configure these routes with **Next hop type**  set to **Virtual appliance** and **Next hop address** set to the private IP address of the Azure Firewall deployed in the secured virtual hub. **Propagate gateway routes** must be set to **Yes**.
+To inspect traffic from clients in the same virtual network as private endpoints, it is not required to specifically override the /32 routes from private endpoints. As long as **Network Policies** are enabled in the private endpoints subnet(s), a UDR with a wider address range will take precedence. For instance, configure this UDR with **Next hop type** set to **Virtual Appliance**, **Next hop address** set to the private IP of the Azure Firewall, and **Address prefix** destination set to the subnet dedicated to all private endpoint deployed in the virtual network. **Propagate gateway routes** must be set to **Yes**.
 
 The following diagram illustrates the DNS and data traffic flows for the different clients to connect to a private endpoint deployed in Azure virtual WAN:
 
@@ -113,24 +128,24 @@ In most cases, these problems are caused by one of the following issues:
 
    :::image type="content" source="./media/private-link-inspection-secure-virtual-hub/firewall-policy-private-traffic-configuration.png" alt-text="Private Traffic Secured by Azure Firewall" border="true":::
 
-2. Verify **Security configuration** in the firewall policy associated with the Azure Firewall deployed in the secured virtual hub. Make sure there's a /32 entry for each private endpoint private IP address you want to filter traffic for under **Private traffic prefixes**.
+2. Verify **Security configuration** in the firewall policy associated with the Azure Firewall deployed in the secured virtual hub. In case traffic destined to private endpoints is not being logged in the firewall, try adding the /32 prefix for each private endpoint to the list of **Private Traffic Prefixes**.
 
    :::image type="content" source="./media/private-link-inspection-secure-virtual-hub/firewall-manager-security-configuration.png" alt-text="Firewall Manager Security Configuration - Private Traffic Prefixes" border="true":::
 
-3. In the secured virtual hub under virtual WAN, inspect effective routes for the route tables associated with the virtual networks and branches connections you want to filter traffic for. Make sure there are /32 entries for each private endpoint private IP address you want to filter traffic for.
+3. In the secured virtual hub under virtual WAN, inspect effective routes for the route tables associated with the virtual networks and branches connections you want to filter traffic for. If /32 entries were added for each private endpoint you want to inspect traffic for, make sure these are listed in the effective routes.
 
    :::image type="content" source="./media/private-link-inspection-secure-virtual-hub/secured-virtual-hub-effective-routes.png" alt-text="Secured Virtual Hub Effective Routes" border="true":::
 
-4. Inspect the effective routes on the NICs attached to the virtual machines deployed in the virtual networks you want to filter traffic for. Make sure there are /32 entries for each private endpoint private IP address you want to filter traffic for.
+4. Inspect the effective routes on the NICs attached to the virtual machines deployed in the virtual networks you want to filter traffic for. Make sure there are /32 entries for each private endpoint private IP address you want to filter traffic for (if added).
 
    Azure CLI:
 
    ```azurecli-interactive
    az network nic show-effective-route-table --name <Network Interface Name> --resource-group <Resource Group Name> -o table
    ```
-5. Inspect the routing tables of your on premises routing devices. Make sure you're learning the address spaces of the virtual networks where the private endpoints are deployed.
+5. Inspect the routing tables of your on-premises routing devices. Make sure you're learning the address spaces of the virtual networks where the private endpoints are deployed.
 
-   Azure virtual WAN doesn't advertise the prefixes configured under **Private traffic prefixes** in firewall policy **Security configuration** to on premises. It's expected that the /32 entries won't show in the routing tables of your on premises routing devices.
+   Azure virtual WAN doesn't advertise the prefixes configured under **Private traffic prefixes** in firewall policy **Security configuration** to on-premises. It's expected that the /32 entries won't show in the routing tables of your on-premises routing devices.
 
 6. Inspect **AzureFirewallApplicationRule** and **AzureFirewallNetworkRule** Azure Firewall logs. Make sure traffic destined to the private endpoints is being logged.
 
@@ -148,3 +163,7 @@ In most cases, these problems are caused by one of the following issues:
 ## Next steps
 
 - [Use Azure Firewall to inspect traffic destined to a private endpoint](../private-link/inspect-traffic-with-azure-firewall.md)
+
+[private-endpoint-overview]: ../private-link/private-endpoint-overview.md
+[firewall-snat-private-ranges]: ../firewall/snat-private-range.md
+[network-policies-overview]: ../private-link/disable-private-endpoint-network-policy.md