Merge pull request #102315 from mscatyao/caya-appgw-updates

itechedit · web-flow · commit 3a23e4c76dc4 · 2020-03-27T10:27:02.000-07:00
added new doc on udr
diff --git a/articles/application-gateway/application-gateway-autoscaling-zone-redundant.md b/articles/application-gateway/application-gateway-autoscaling-zone-redundant.md
@@ -5,7 +5,7 @@ services: application-gateway
 author: vhorne
 ms.service: application-gateway
 ms.topic: article
-ms.date: 02/26/2020
+ms.date: 03/24/2020
 ms.author: victorh
 ---
 
@@ -164,7 +164,7 @@ The following table compares the features available with each SKU.
 |--|--|
 |Authentication certificate|Not supported.<br>For more information, see [Overview of end to end SSL with Application Gateway](ssl-overview.md#end-to-end-ssl-with-the-v2-sku).|
 |Mixing Standard_v2 and Standard Application Gateway on the same subnet|Not supported|
-|User Defined Route (UDR) on Application Gateway subnet|Not supported|
+|User-Defined Route (UDR) on Application Gateway subnet|Supported (specific scenarios). In preview.<br> For more information about supported scenarios, see [Application Gateway configuration overview](configuration-overview.md#user-defined-routes-supported-on-the-application-gateway-subnet).|
 |NSG for Inbound port range| - 65200 to 65535 for Standard_v2 SKU<br>- 65503 to 65534 for Standard SKU.<br>For more information, see the [FAQ](application-gateway-faq.md#are-network-security-groups-supported-on-the-application-gateway-subnet).|
 |Performance logs in Azure diagnostics|Not supported.<br>Azure metrics should be used.|
 |Billing|Billing scheduled to start on July 1, 2019.|
diff --git a/articles/application-gateway/application-gateway-faq.md b/articles/application-gateway/application-gateway-faq.md
@@ -5,7 +5,7 @@ services: application-gateway
 author: vhorne
 ms.service: application-gateway
 ms.topic: article
-ms.date: 03/06/2020
+ms.date: 03/24/2020
 ms.author: victorh
 ---
 
@@ -91,6 +91,10 @@ Yes. In addition to multiple instances of a given Application Gateway deployment
 
 A single subnet can't support both Standard_v2 and Standard Application Gateway together.
 
+### Does Application Gateway v2 support user-defined routes (UDR)?
+
+Yes, but only specific scenarios. For more information, see [Application Gateway configuration overview](configuration-overview.md#user-defined-routes-supported-on-the-application-gateway-subnet).
+
 ### Does Application Gateway support x-forwarded-for headers?
 
 Yes. See [Modifications to a request](https://docs.microsoft.com/azure/application-gateway/how-application-gateway-works#modifications-to-the-request).
@@ -385,24 +389,24 @@ Yes. If your configuration matches following scenario, you won't see allowed tra
 
 ### How do I use Application Gateway V2 with only private frontend IP address?
 
-Application Gateway V2 currently does not support only private IP mode. It supports the following combinations
+Application Gateway V2 currently doesn't support only private IP mode. It supports the following combinations
 * Private IP and Public IP
 * Public IP only
 
 But if you'd like to use Application Gateway V2 with only private IP, you can follow the process below:
 1. Create an Application Gateway with both public and private frontend IP address
-2. Do not create any listeners for the public frontend IP address. Application Gateway will not listen to any traffic on the public IP address if no listeners are created for it.
+2. Don't create any listeners for the public frontend IP address. Application Gateway will not listen to any traffic on the public IP address if no listeners are created for it.
 3. Create and attach a [Network Security Group](https://docs.microsoft.com/azure/virtual-network/security-overview) for the Application Gateway subnet with the following configuration in the order of priority:
     
     a. Allow traffic from Source as **GatewayManager** service tag and Destination as **Any** and Destination port as **65200-65535**. This port range is required for Azure infrastructure communication. These ports are protected (locked down) by certificate authentication. External entities, including the Gateway user administrators, can't initiate changes on those endpoints without appropriate certificates in place
     
-    b. Allow traffic from Source as **AzureLoadBalancer** service tag and Destination and destination port as **Any**
+    b. Allow traffic from Source as **AzureLoadBalancer** service tag and destination port as **Any**
     
-    c. Deny all inbound traffic from Source as **Internet** service tag and Destination and destination port as **Any**. Give this rule the *least priority* in the inbound rules
+    c. Deny all inbound traffic from Source as **Internet** service tag and destination port as **Any**. Give this rule the *least priority* in the inbound rules
     
-    d. Keep the default rules like allowing VirtualNetwork inbound so that the access on private IP address is not blocked
+    d. Keep the default rules like allowing VirtualNetwork inbound so that the access on private IP address isn't blocked
     
-    e. Outbound internet connectivity can't be blocked. Otherwise, you will face issues with logging, metrics, etc.
+    e. Outbound internet connectivity can't be blocked. Otherwise, you will face issues with logging, metrics, and so on.
 
 Sample NSG configuration for private IP only access:
 ![Application Gateway V2 NSG Configuration for private IP access only](./media/application-gateway-faq/appgw-privip-nsg.png)
diff --git a/articles/application-gateway/configuration-overview.md b/articles/application-gateway/configuration-overview.md
@@ -5,9 +5,8 @@ services: application-gateway
 author: vhorne
 ms.service: application-gateway
 ms.topic: article
-ms.date: 11/15/2019
+ms.date: 03/24/2020
 ms.author: absha
-
 ---
 
 # Application Gateway configuration overview
@@ -32,11 +31,11 @@ An application gateway is a dedicated deployment in your virtual network. Within
 
 #### Size of the subnet
 
-Application Gateway consumes 1 private IP address per instance, plus another private IP address if a private front-end IP is configured.
+Application Gateway uses one private IP address per instance, plus another private IP address if a private front-end IP is configured.
 
-Azure also reserves 5 IP addresses in each subnet for internal use: the first 4 and the last IP addresses. For example, consider 15 application gateway instances with no private front-end IP. You need at least 20 IP addresses for this subnet: 5 for internal use and 15 for the application gateway instances. So, you need a /27 subnet size or larger.
+Azure also reserves five IP addresses in each subnet for internal use: the first four and the last IP addresses. For example, consider 15 application gateway instances with no private front-end IP. You need at least 20 IP addresses for this subnet: five for internal use and 15 for the application gateway instances. So, you need a /27 subnet size or larger.
 
-Consider a subnet that has 27 application gateway instances and an IP address for a private front-end IP. In this case, you need 33 IP addresses: 27 for the application gateway instances, 1 for the private front end, and 5 for internal use. So, you need a /26 subnet size or larger.
+Consider a subnet that has 27 application gateway instances and an IP address for a private front-end IP. In this case, you need 33 IP addresses: 27 for the application gateway instances, one for the private front end, and five for internal use. So, you need a /26 subnet size or larger.
 
 We recommend that you use a subnet size of at least /28. This size gives you 11 usable IP addresses. If your application load requires more than 10 Application Gateway instances, consider a /27 or /26 subnet size.
 
@@ -65,23 +64,64 @@ For this scenario, use NSGs on the Application Gateway subnet. Put the following
 
 #### User-defined routes supported on the Application Gateway subnet
 
-For the v1 SKU, user-defined routes (UDRs) are supported on the Application Gateway subnet, as long as they don't alter end-to-end request/response communication. For example, you can set up a UDR in the Application Gateway subnet to point to a firewall appliance for packet inspection. But you must make sure that the packet can reach its intended destination after inspection. Failure to do so might result in incorrect health-probe or traffic-routing behavior. This includes learned routes or default 0.0.0.0/0 routes that are propagated by Azure ExpressRoute or VPN gateways in the virtual network.
+> [!IMPORTANT]
+> Using UDRs on the Application Gateway subnet might cause the health status in the [back-end health view](https://docs.microsoft.com/azure/application-gateway/application-gateway-diagnostics#back-end-health) to appear as **Unknown**. It also might cause generation of Application Gateway logs and metrics to fail. We recommend that you don't use UDRs on the Application Gateway subnet so that you can view the back-end health, logs, and metrics.
 
-For the v2 SKU, UDRs are not supported on the Application Gateway subnet. For more information, see [Azure Application Gateway v2 SKU](application-gateway-autoscaling-zone-redundant.md#differences-with-v1-sku).
+- **v1**
 
-> [!NOTE]
-> UDRs are not supported for the v2 SKU as of now.
+   For the v1 SKU, user-defined routes (UDRs) are supported on the Application Gateway subnet, as long as they don't alter end-to-end request/response communication. For example, you can set up a UDR in the Application Gateway subnet to point to a firewall appliance for packet inspection. But you must make sure that the packet can reach its intended destination after inspection. Failure to do so might result in incorrect health-probe or traffic-routing behavior. This includes learned routes or default 0.0.0.0/0 routes that are propagated by Azure ExpressRoute or VPN gateways in the virtual network.
 
-> [!NOTE]
-> Using UDRs on the Application Gateway subnet might cause the health status in the [back-end health view](https://docs.microsoft.com/azure/application-gateway/application-gateway-diagnostics#back-end-health) to appear as "Unknown." It also might cause generation of Application Gateway logs and metrics to fail. We recommend that you don't use UDRs on the Application Gateway subnet so that you can view the back-end health, logs, and metrics.
+- **v2**
+
+   For the v2 SKU, there are supported and unsupported scenarios:
+
+   **v2 supported scenarios**
+   > [!WARNING]
+   > An incorrect configuration of the route table could result in asymmetrical routing in Application Gateway v2. Ensure that all management/control plane traffic is sent directly to the Internet and not through a virtual appliance. Logging and metrics could also be affected.
+
+
+  **Scenario 1**: UDR to disable Border Gateway Protocol (BGP) Route Propagation to the Application Gateway subnet
+
+   Sometimes the default gateway route (0.0.0.0/0) is advertised via the ExpressRoute or VPN gateways associated with the Application Gateway virtual network. This breaks management plane traffic, which requires a direct path to the Internet. In such scenarios, a UDR can be used to disable BGP route propagation. 
+
+   To disable BGP route propagation, use the following steps:
+
+   1. Create a Route Table resource in Azure.
+   2. Disable the **Virtual network gateway route propagation** parameter. 
+   3. Associate the Route Table to the appropriate subnet. 
+
+   Enabling the UDR for this scenario shouldn't break any existing setups.
+
+  **Scenario 2**: UDR to direct 0.0.0.0/0 to the Internet
+
+   You can create a UDR to send 0.0.0.0/0 traffic directly to the Internet. 
+
+  **Scenario 3**: UDR for Azure Kubernetes Service kubenet
+
+  If you're using kubenet with Azure Kubernetes Service (AKS) and Application Gateway Ingress Controller (AGIC), you need to set up a route table to allow traffic sent to the pods to be routed to the correct node. This won't be necessary if you use Azure CNI. 
+
+   To set up the route table to allow kubenet to work, use the following steps:
+
+  1. Create a Route Table resource in Azure. 
+  2. Once it's created, go to the **Routes** page. 
+  3. Add a new route:
+     - Address prefix should be the IP range of the pods you want to reach in AKS. 
+     - Next hop type should be **Virtual Appliance**. 
+     - Next hop address should be the IP address of the node hosting the pods within the IP range defined in the address prefix field. 
+    
+  **v2 unsupported scenarios**
+
+  **Scenario 1**: UDR for Virtual Appliances
+
+  Any scenario where 0.0.0.0/0 needs to be redirected through any virtual appliance, a hub/spoke virtual network, or on-premise (forced tunneling) isn't supported for the v2 public preview. 
 
 ## Front-end IP
 
 You can configure the application gateway to have a public IP address, a private IP address, or both. A public IP is required when you host a back end that clients must access over the internet via an internet-facing virtual IP (VIP). 
 
 A public IP isn't required for an internal endpoint that's not exposed to the internet. That's known as an *internal load-balancer* (ILB) endpoint or private frontend IP. An application gateway ILB is useful for internal line-of-business applications that aren't exposed to the internet. It's also useful for services and tiers in a multi-tier application within a security boundary that aren't exposed to the internet but that require round-robin load distribution, session stickiness, or TLS termination.
 
-Only 1 public IP address or 1 private IP address is supported. You choose the front-end IP when you create the application gateway.
+Only 1 public IP address or one private IP address is supported. You choose the front-end IP when you create the application gateway.
 
 - For a public IP, you can create a new public IP address or use an existing public IP in the same location as the application gateway. For more information, see [static vs. dynamic public IP address](https://docs.microsoft.com/azure/application-gateway/application-gateway-components#static-versus-dynamic-public-ip-address).
 
@@ -105,7 +145,7 @@ When you create a new listener, you choose between [*basic* and *multi-site*](ht
 
 #### Order of processing listeners
 
-For the v1 SKU, requests are matched according to the order of the rules and the type of listener. If a rule with basic listener comes first in the order, it is processed first and will accept any request for that port and IP combination. To avoid this, configure the rules with multi-site listeners first and push the rule with the basic listener to the last in the list.
+For the v1 SKU, requests are matched according to the order of the rules and the type of listener. If a rule with basic listener comes first in the order, it's processed first and will accept any request for that port and IP combination. To avoid this, configure the rules with multi-site listeners first and push the rule with the basic listener to the last in the list.
 
 For the v2 SKU, multi-site listeners are processed before basic listeners.
 
@@ -251,15 +291,15 @@ The application gateway routes traffic to the back-end servers by using the conf
 
 ### Cookie-based affinity
 
-Azure Application Gateway uses gateway managed cookies for maintaining user sessions. When a user sends the first request to Application Gateway, it sets an affinity cookie in the response with a hash value which contains the session details, so that the subsequent requests carrying the affinity cookie will be routed to the same backend server for maintaining stickiness. 
+Azure Application Gateway uses gateway-managed cookies for maintaining user sessions. When a user sends the first request to Application Gateway, it sets an affinity cookie in the response with a hash value which contains the session details, so that the subsequent requests carrying the affinity cookie will be routed to the same backend server for maintaining stickiness. 
 
 This feature is useful when you want to keep a user session on the same server and when session state is saved locally on the server for a user session. If the application can't handle cookie-based affinity, you can't use this feature. To use it, make sure that the clients support cookies.
 
 The [Chromium browser](https://www.chromium.org/Home) [v80 update](https://chromiumdash.appspot.com/schedule) brought a mandate where HTTP cookies without [SameSite](https://tools.ietf.org/id/draft-ietf-httpbis-rfc6265bis-03.html#rfc.section.5.3.7) attribute has to be treated as SameSite=Lax. In the case of CORS (Cross-Origin Resource Sharing) requests, if the cookie has to be sent in a third-party context, it has to use *SameSite=None; Secure* attributes and it should be sent over HTTPS only. Otherwise, in a HTTP only scenario, the browser doesn't send the cookies in the third-party context. The goal of this update from Chrome is to enhance security and to avoid Cross-Site Request Forgery (CSRF) attacks. 
 
-To support this change, starting February 17th 2020, Application Gateway (all the SKU types) will inject another cookie called *ApplicationGatewayAffinityCORS* in addition to the existing *ApplicationGatewayAffinity* cookie. The *ApplicationGatewayAffinityCORS* cookie has two more attributes added to it (*"SameSite=None; Secure"*) so that sticky session are maintained even for cross-origin requests.
+To support this change, starting February 17 2020, Application Gateway (all the SKU types) will inject another cookie called *ApplicationGatewayAffinityCORS* in addition to the existing *ApplicationGatewayAffinity* cookie. The *ApplicationGatewayAffinityCORS* cookie has two more attributes added to it (*"SameSite=None; Secure"*) so that sticky session are maintained even for cross-origin requests.
 
-Note that the default affinity cookie name is *ApplicationGatewayAffinity* and you can change it. In case you are using a custom affinity cookie name, an additional cookie is added with CORS as suffix. For example, *CustomCookieNameCORS*.
+Note that the default affinity cookie name is *ApplicationGatewayAffinity* and you can change it. In case you're using a custom affinity cookie name, an additional cookie is added with CORS as suffix. For example, *CustomCookieNameCORS*.
 
 > [!NOTE]
 > If the attribute *SameSite=None* is set, it is mandatory that the cookie also contains the *Secure* flag, and must be sent over HTTPS.  If session affinity is required over CORS, you must migrate your workload to HTTPS. 
diff --git a/articles/application-gateway/configure-keyvault-ps.md b/articles/application-gateway/configure-keyvault-ps.md
@@ -66,7 +66,7 @@ $certificate = Get-AzKeyVaultCertificate -VaultName $kv -Name "cert1"
 $secretId = $certificate.SecretId.Replace($certificate.Version, "")
 ```
 > [!NOTE]
-> The -EnableSoftDelete flag must be used for SSL termination to function properly.
+> The -EnableSoftDelete flag must be used for SSL termination to function properly. If you're configuring [Key Vault soft-delete through the Portal](../key-vault/key-vault-ovw-soft-delete.md#soft-delete-behavior), the retention period must be kept at 90 days, the default value. Application Gateway doesn't support a different retention period yet. 
 
 ### Create a virtual network
 
diff --git a/articles/application-gateway/whats-new.md b/articles/application-gateway/whats-new.md
