Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into us429364-seo-top25-vnet

asudbring · asudbring · commit d92e9e3616c0 · 2025-07-15T16:49:45.000-05:00
diff --git a/articles/application-gateway/add-http-header-rewrite-rule-powershell.md b/articles/application-gateway/add-http-header-rewrite-rule-powershell.md
@@ -5,51 +5,68 @@ services: application-gateway
 author: mbender-ms
 ms.service: azure-application-gateway
 ms.topic: how-to
-ms.date: 04/12/2019
+ms.date: 07/09/2025
 ms.author: mbender 
 ms.custom: devx-track-azurepowershell
 # Customer intent: "As a cloud administrator, I want to configure HTTP header rewrites using Azure PowerShell, so that I can efficiently modify headers in requests and responses for my Application Gateway."
 ---
 # Rewrite HTTP request and response headers with Azure Application Gateway - Azure PowerShell
 
-This article describes how to use Azure PowerShell to configure an [Application Gateway v2 SKU](./application-gateway-autoscaling-zone-redundant.md) instance to rewrite the HTTP headers in requests and responses.
+This article describes how to use Azure PowerShell to configure an [Application Gateway v2 SKU](./application-gateway-autoscaling-zone-redundant.md) instance to rewrite HTTP headers in requests and responses. Header rewriting enables you to add, remove, or update HTTP headers while the request and response packets move between the client and backend pools.
 
 If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.
 
-## Before you begin
+## Prerequisites
 
-- You need to run Azure PowerShell locally to complete the steps in this article. You also need to have Az module version 1.0.0 or later installed. Run `Import-Module Az` and then `Get-Module Az` to determine the version that you have installed. If you need to upgrade, see [Install Azure PowerShell module](/powershell/azure/install-azure-powershell). After you verify the PowerShell version, run `Login-AzAccount` to create a connection with Azure.
-- You need to have an Application Gateway v2 SKU instance. Rewriting headers isn't supported in the v1 SKU. If you don't have the v2 SKU, create an [Application Gateway v2 SKU](./tutorial-autoscale-ps.md) instance before you begin.
+Before you begin, ensure you have the following requirements:
 
-## Create required objects
+- **Azure PowerShell**: You need Azure PowerShell installed locally or access to Azure Cloud Shell. The Azure PowerShell Az module version 1.0.0 or later is required. To check your version, run `Get-Module -ListAvailable Az`. If you need to upgrade, see [Install Azure PowerShell module](/powershell/azure/install-azure-powershell). 
+- **Azure connection**: After verifying the PowerShell version, run `Connect-AzAccount` to authenticate with Azure.
+- **Application Gateway v2**: You need an existing Application Gateway v2 SKU instance. Header rewriting is only supported in the v2 SKU (Standard_v2 or WAF_v2). If you don't have one, create an [Application Gateway v2 SKU](./tutorial-autoscale-ps.md) instance before you begin.
+- **Proper permissions**: Ensure you have Contributor or Owner permissions on the Application Gateway resource.
 
-To configure HTTP header rewrite, you need to complete these steps.
+> [!IMPORTANT]
+> Header rewrite functionality is only available with Application Gateway v2 SKU. The v1 SKU doesn't support this feature.
 
-1. Create the objects that are required for HTTP header rewrite:
+## Understanding HTTP header rewrite components
 
-   - **RequestHeaderConfiguration**: Used to specify the request header fields that you intend to rewrite and the new value for the headers.
+To configure HTTP header rewrite, you need to understand and create the following components in a specific order:
 
-   - **ResponseHeaderConfiguration**: Used to specify the response header fields that you intend to rewrite and the new value for the headers.
+### Core components
 
-   - **ActionSet**: Contains the configurations of the request and response headers specified previously.
+1. **RequestHeaderConfiguration**: Specifies the request header fields you want to rewrite and their new values. Use this component to modify headers in client requests before they reach the backend servers.
 
-   - **Condition**: An optional configuration. Rewrite conditions evaluate the content of HTTP(S) requests and responses. The rewrite action will occur if the HTTP(S) request or response matches the rewrite condition.
+2. **ResponseHeaderConfiguration**: Specifies the response header fields you want to rewrite and their new values. Use this component to modify headers in server responses before they reach the client.
 
-     If you associate more than one condition with an action, the action occurs only when all the conditions are met. In other words, the operation is a  logical AND operation.
+3. **ActionSet**: Contains the configurations of the request and response headers specified. Each action set represents a collection of header modifications to perform.
+   
+   - **Condition**: An optional configuration. Rewrite conditions evaluate the content of HTTP(S) requests and responses. The rewrite action occurs if the HTTP(S) request or response matches the rewrite condition.
 
-   - **RewriteRule**: Contains multiple rewrite action / rewrite condition combinations.
+   > [!NOTE]
+   > Multiple conditions associated with an action use logical AND operation - all conditions must be met for the action to execute.
 
-   - **RuleSequence**: An optional configuration that helps determine the order in which rewrite rules execute. This configuration is helpful when you have multiple rewrite rules in a rewrite set. A rewrite rule that has a lower rule sequence value runs first. If you assign the same rule sequence value to two rewrite rules, the order of execution is non-deterministic.
+5. **RewriteRule**: Combines multiple rewrite actions and rewrite conditions. Each rule defines when and how to modify headers.
 
-     If you don't specify the RuleSequence explicitly, a default value of 100 is set.
+6. **RuleSequence** (Optional): Determines the execution order when you have multiple rewrite rules in a rewrite set. Rules with lower sequence values execute first. If you don't specify a value, the default is 100.
 
-   - **RewriteRuleSet**: Contains multiple rewrite rules that will be associated to a request routing rule.
+   > [!WARNING]
+   > If you assign the same sequence value to multiple rules, the execution order becomes non-deterministic.
 
-2. Attach the RewriteRuleSet to a routing rule. The rewrite configuration is attached to the source listener via the routing rule. When you use a basic routing rule, the header rewrite configuration is associated with a source listener and is a global header rewrite. When you use a path-based routing rule, the header rewrite configuration is defined on the URL path map. In that case, it applies only to the specific path area of a site.
+7. **RewriteRuleSet**: Contains multiple rewritten rules that are associated with a request routing rule.
 
-You can create multiple HTTP header rewrite sets and apply each rewrite set to multiple listeners. But you can apply only one rewrite set to a specific listener.
+### Application scope
 
-## Sign in to Azure
+The rewrite configuration scope depends on the routing rule type:
+
+- **Basic routing rule**: Header rewrite configuration applies globally to all requests for the associated listener
+- **Path-based routing rule**: Header rewrite configuration applies only to requests matching specific URL path patterns defined in the URL path map
+
+> [!IMPORTANT]
+> You can create multiple HTTP header rewrite sets and apply each set to multiple listeners, but only one rewrite set can be applied to a specific listener.
+
+## Authenticate with Azure
+
+Before configuring header rewrite rules, authenticate with Azure and select your subscription:
 
 ```azurepowershell
 Connect-AzAccount
@@ -58,12 +75,12 @@ Select-AzSubscription -Subscription "<sub name>"
 
 ## Specify the HTTP header rewrite rule configuration
 
-In this example, we'll modify a redirection URL by rewriting the location header in the HTTP response whenever the location header contains a reference to azurewebsites.net. To do this, we'll add a condition to evaluate whether the location header in the response contains azurewebsites.net. We'll use the pattern `(https?)://.*azurewebsites.net(.*)$`. And we'll use `{http_resp_Location_1}://contoso.com{http_resp_Location_2}` as the header value. This value will replace *azurewebsites.net* with *contoso.com* in the location header.
+In this example, we modify a redirection URL by rewriting the location header in the HTTP response whenever the location header contains a reference to azurewebsite.net. To do this modification, we add a condition to evaluate whether the location header in the response contains azurewebsite.net. We use the pattern `(https?)://.*azurewebsite.net(.*)$`. And we use `{http_resp_Location_1}://contoso.com{http_resp_Location_2}` as the header value. This value replaces *azurewebsite.net* with *contoso.com* in the location header.
 
 ```azurepowershell
 $responseHeaderConfiguration = New-AzApplicationGatewayRewriteRuleHeaderConfiguration -HeaderName "Location" -HeaderValue "{http_resp_Location_1}://contoso.com{http_resp_Location_2}"
 $actionSet = New-AzApplicationGatewayRewriteRuleActionSet -ResponseHeaderConfiguration $responseHeaderConfiguration
-$condition = New-AzApplicationGatewayRewriteRuleCondition -Variable "http_resp_Location" -Pattern "(https?):\/\/.*azurewebsites\.net(.*)$" -IgnoreCase
+$condition = New-AzApplicationGatewayRewriteRuleCondition -Variable "http_resp_Location" -Pattern "(https?):\/\/.*azurewebsite\.net(.*)$" -IgnoreCase
 $rewriteRule = New-AzApplicationGatewayRewriteRule -Name LocationHeader -ActionSet $actionSet -Condition $condition
 $rewriteRuleSet = New-AzApplicationGatewayRewriteRuleSet -Name LocationHeaderRewrite -RewriteRule $rewriteRule
 ```
@@ -74,32 +91,51 @@ $rewriteRuleSet = New-AzApplicationGatewayRewriteRuleSet -Name LocationHeaderRew
 $appgw = Get-AzApplicationGateway -Name "AutoscalingAppGw" -ResourceGroupName "<rg name>"
 ```
 
-## Retrieve the configuration of your request routing rule
+## Retrieve request routing rule configuration
+
+Get the specific request routing rule where you want to apply the header rewrite configuration:
 
 ```azurepowershell
 $reqRoutingRule = Get-AzApplicationGatewayRequestRoutingRule -Name rule1 -ApplicationGateway $appgw
 ```
 
 ## Update the application gateway with the configuration for rewriting HTTP headers
 
-In this example, the rewrite set would be associated instantly against a basic routing rule. In case of a path based routing rule, the association would not be enabled by default. The rewrite set can be enabled either via checking the paths on which it needs to be applied via portal or by providing a URL path map config specifying the RewriteRuleSet against each path option.  
+In this example, the rewrite set would be associated instantly against a basic routing rule. In a path based routing rule, the association wouldn't be enabled by default. The rewrite set can be enabled either via -- checking the paths on which it needs to be applied via portal or by providing a URL path map config specifying the RewriteRuleSet against each path option.  
 
 ```azurepowershell
 Add-AzApplicationGatewayRewriteRuleSet -ApplicationGateway $appgw -Name $rewriteRuleSet.Name  -RewriteRule $rewriteRuleSet.RewriteRules
 Set-AzApplicationGatewayRequestRoutingRule -ApplicationGateway $appgw -Name $reqRoutingRule.Name -RuleType $reqRoutingRule.RuleType -BackendHttpSettingsId $reqRoutingRule.BackendHttpSettings.Id -HttpListenerId $reqRoutingRule.HttpListener.Id -BackendAddressPoolId $reqRoutingRule.BackendAddressPool.Id -RewriteRuleSetId $rewriteRuleSet.Id
 Set-AzApplicationGateway -ApplicationGateway $appgw
 ```
 
-## Delete a rewrite rule
+## Remove a rewrite rule (Optional)
 
-```azurepowershell
+If you need to remove a rewrite rule set from your Application Gateway, use the following steps:
+
+```azurepowershell-interactive
+# Retrieve the current Application Gateway configuration
 $appgw = Get-AzApplicationGateway -Name "AutoscalingAppGw" -ResourceGroupName "<rg name>"
+
+# Remove the rewrite rule set association from the routing rule first
+$requestRoutingRule = Get-AzApplicationGatewayRequestRoutingRule -Name "rule1" -ApplicationGateway $appgw
+
+# Clear the rewrite rule set reference
+$requestRoutingRule.RewriteRuleSet = $null
+
+# Remove the rewrite rule set from the Application Gateway
 Remove-AzApplicationGatewayRewriteRuleSet -Name "LocationHeaderRewrite" -ApplicationGateway $appgw
-$requestroutingrule= Get-AzApplicationGatewayRequestRoutingRule -Name "rule1" -ApplicationGateway $appgw
-$requestroutingrule.RewriteRuleSet= $null
-set-AzApplicationGateway -ApplicationGateway $appgw
+
+# Apply the changes
+Set-AzApplicationGateway -ApplicationGateway $appgw
+
+Write-Output "Rewrite rule set removed successfully"
 ```
 
 ## Next steps
 
-To learn more about how to set up some common use cases, see [common header rewrite scenarios](./rewrite-http-headers-url.md).
+Now that you learned how to configure HTTP header rewrite rules, explore these related articles:
+
+- **Common scenarios**: Learn about [common header rewrite scenarios](./rewrite-http-headers-url.md) including security headers, custom routing, and backend server integration patterns.
+
+- **Monitoring and troubleshooting**: Set up [Application Gateway diagnostics](./application-gateway-diagnostics.md) to monitor header rewrite operations and troubleshoot issues.
diff --git a/articles/application-gateway/mutual-authentication-troubleshooting.md b/articles/application-gateway/mutual-authentication-troubleshooting.md
@@ -123,13 +123,15 @@ Double check the certificate chain that was uploaded and remove the private key
 #### Cause
 
 There are two potential causes for this error:
+
 * **Parsing failure:** The certificate chain isn't in the correct format. Application Gateway expects certificate chains in PEM format with properly delimited individual certificates.
 * **Empty content:** The uploaded file contains only delimiters without actual certificate data between them. 
 
 #### Solution
 
 Based on the specific cause, apply one of the following solutions:
-*  **Format issue:** Ensure the certificate chain is in PEM format with each certificate properly delimited by `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` markers. Each certificate should be on separate lines within these delimiters.
+
+* **Format issue:** Ensure the certificate chain is in PEM format with each certificate properly delimited by `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` markers. Each certificate should be on separate lines within these delimiters.
 * **Missing data:** Verify that the certificate file contains actual certificate data between the delimiters, not just empty delimiters. 
 
 ### Error code: ApplicationGatewayTrustedClientCertificateDoesNotContainAnyCACertificate
diff --git a/articles/traffic-manager/traffic-manager-subnet-override-cli.md b/articles/traffic-manager/traffic-manager-subnet-override-cli.md
@@ -68,6 +68,28 @@ az network traffic-manager endpoint update \
     --remove subnets \
     --type AzureEndpoints
 ```
+### IPv6 Subnet Mapping Examples ###
+You can also configure subnet mapping using IPv6 address ranges. Use the --type parameter with IPv6 and specify IPv6 addresses in CIDR or range format.
+
+```azurecli-interactive
+### Add an IPv6 Subnet in CIDR Notation ###
+az network traffic-manager endpoint update \
+  --resource-group MyResourceGroup \
+  --profile-name MyTmProfile \
+  --endpoint-name MyEndpoint \
+  --type IPv6 \
+  --subnets 2001:0db8:1234:5678::/64 \
+  --endpoint-type ExternalEndpoints
+
+### Add a range of IPs ###
+az network traffic-manager endpoint update \
+  --resource-group MyResourceGroup \
+  --profile-name MyTmProfile \
+  --endpoint-name MyEndpoint \
+  --type IPv6 \
+  --subnets 2001:0db8:abcd:1234::1-2001:0db8:abcd:1234::ffff \
+  --endpoint-type ExternalEndpoints
+```
 
 ## Next Steps
 
diff --git a/articles/traffic-manager/traffic-manager-subnet-override-powershell.md b/articles/traffic-manager/traffic-manager-subnet-override-powershell.md
@@ -69,7 +69,10 @@ To create a Traffic Manager subnet override, you can use Azure PowerShell to add
 
     ### Add a range of IPs with a subnet ###
     Add-AzTrafficManagerIPAddressRange -TrafficManagerEndpoint $TrafficManagerEndpoint -First "12.13.14.0" -Last "12.13.14.31" -Scope 27
- 
+
+    ### Add a range of IPv6 IPs ###
+    Add-AzTrafficManagerIPAddressRange -TrafficManagerEndpoint $TrafficManagerEndpoint -First "2001:0db8:85a3::1" -Last "2001:0db8:85a3::ffff"
+
     ```
 
 ### Update Endpoint 
@@ -109,6 +112,9 @@ Set-AzTrafficManagerEndpoint -TrafficManagerEndpoint $TrafficManagerEndpoint
     ### Remove a range of IPs with a subnet ###
     Remove-AzTrafficManagerIpAddressRange -TrafficManagerEndpoint $TrafficManagerEndpoint -First "12.13.14.0" 
 
+    ### Remove a range of IPv6 IPs ###
+    Remove-AzTrafficManagerIpAddressRange -TrafficManagerEndpoint $TrafficManagerEndpoint -First "2001:0db8:85a3::1" 
+    
     ```
 
 ### Update Endpoint
diff --git a/articles/virtual-wan/how-to-routing-policies.md b/articles/virtual-wan/how-to-routing-policies.md
@@ -367,13 +367,22 @@ Using the sample VPN configuration and VPN site from above, create firewall rule
 
 #### Performance for Encrypted ExpressRoute
 
-Configuring private routing policies with Encrypted ExpressRoute routes VPN ESP packets through the next hop security appliance deployed in the hub. As a result, you can expect Encrypted ExpressRoute maximum VPN tunnel throughput of 1 Gbps in both directions (inbound from on-premises and outbound from Azure). To achieve the maximum VPN tunnel throughput, consider the following deployment optimizations:
+Configuring private routing policies with Encrypted ExpressRoute routes VPN ESP packets through the next hop security appliance deployed in the hub. Encrypted ExpressRoute performance is impacted by two main factors:
+* You can expect Encrypted ExpressRoute VPN tunnels to have a maximum throughput of 1 Gbps due to ESP traffic being forwarded through the next hop security appliance deployed in the Virtual WAN hub. 
+* In practice, Encrypted ExpressRoute VPN tunnel throughput is also impacted by the maximum per-tunnel packets-per-second (PPS) supported by the VPN Gateway scale unit. For smaller packet sizes, you may see lower tunnel throughput. See [Site-to-site VPN performance](virtual-wan-faq.md#packets) for more information.
+
+
+To achieve the maximum VPN tunnel throughput, consider the following deployment optimizations:
 
 * Deploy Azure Firewall Premium instead of Azure Firewall Standard or Azure Firewall Basic.
 * Ensure Azure Firewall processes the rule that allows traffic between the VPN tunnel endpoints (192.168.1.4 and 192.168.1.5 in the example above) first by making the rule have the highest priority in your Azure Firewall policy. For more information about Azure Firewall rule processing logic, see [Azure Firewall rule processing logic](../firewall/rule-processing.md#rule-processing-using-firewall-policy).
 * Turn off deep-packet for traffic between the VPN tunnel endpoints. For information on how to configure Azure Firewall to exclude traffic from deep-packet inspection, reference [IDPS bypass list documentation](../firewall/premium-features.md#idps).
 * Configure VPN devices to use GCMAES256 for both IPSEC Encryption and Integrity to maximize performance.
 
+To achieve maximum aggregate throughput, consider the following optimization:
+
+* To increase throughput between a single on-premises site and Azure, create multiple tunnels between on-premises devices and the Site-to-site VPN Gateway in Virtual WAN. Ensure your on-premises VPN device is configured to load-balance traffic across all active tunnels.
+
 #### Direct routing to NVA instances for dual-role connectivity and firewall NVAs
 
 > [!NOTE]
