App Gateway PDF
App Gateway PDF
App Gateway PDF
Azure Application Gateway is a web traffic load balancer that enables you to manage traffic to your web
applications.
Traditional load balancers operate at the transport layer (OSI layer 4 - TCP and UDP ) and route traffic based on
source IP address and port, to a destination IP address and port. But with the Application Gateway you can be
even more specific. For example, you can route traffic based on the incoming URL. So if /images is in the
incoming URL, you can route traffic to a specific set of servers (known as a pool) configured for images. If
/video is in the URL, that traffic is routed to another pool optimized for videos.
This type of routing is known as application layer (OSI layer 7) load balancing. Azure Application Gateway can
do URL -based routing and more.
The following features are included with Azure Application Gateway:
URL-based routing
URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request.
One of the scenarios is to route requests for different content types to different pool.
For example, requests for are routed to VideoServerPool, and
http://contoso.com/video/*
http://contoso.com/images/* are routed to ImageServerPool. DefaultServerPool is selected if none of the path
patterns match.
Multiple-site hosting
Multiple-site hosting enables you to configure more than one web site on the same application gateway
instance. This feature allows you to configure a more efficient topology for your deployments by adding up to 20
web sites to one application gateway. Each web site can be directed to its own pool. For example, application
gateway can serve traffic for contoso.com and fabrikam.com from two server pools called ContosoServerPool
and FabrikamServerPool.
Requests for http://contoso.com are routed to ContosoServerPool, and http://fabrikam.com are routed to
FabrikamServerPool.
Similarly, two subdomains of the same parent domain can be hosted on the same application gateway
deployment. Examples of using subdomains could include http://blog.contoso.com and http://app.contoso.com
hosted on a single application gateway deployment.
Redirection
A common scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all
communication between an application and its users occurs over an encrypted path.
In the past, you may have used techniques such as creating a dedicated pool whose sole purpose is to redirect
requests it receives on HTTP to HTTPS. Application gateway supports the ability to redirect traffic on the
Application Gateway. This simplifies application configuration, optimizes the resource usage, and supports new
redirection scenarios, including global and path-based redirection. Application Gateway redirection support is
not limited to HTTP to HTTPS redirection alone. This is a generic redirection mechanism, so you can redirect
from and to any port you define using rules. It also supports redirection to an external site as well.
Application Gateway redirection support offers the following capabilities:
Global redirection from one port to another port on the Gateway. This enables HTTP to HTTPS redirection
on a site.
Path-based redirection. This type of redirection enables HTTP to HTTPS redirection only on a specific site
area, for example a shopping cart area denoted by /cart/* .
Redirect to an external site.
Session affinity
The cookie-based session affinity feature is useful when you want to keep a user session on the same server. By
using gateway-managed cookies, the Application Gateway can direct subsequent traffic from a user session to
the same server for processing. This is important in cases where session state is saved locally on the server for a
user session.
Next steps
Depending on your requirements and environment, you can create a test Application Gateway using either the
Azure portal, Azure PowerShell, or Azure CLI:
Quickstart: Direct web traffic with Azure Application Gateway - Azure portal.
Quickstart: Direct web traffic with Azure Application Gateway - Azure PowerShell
Quickstart: Direct web traffic with Azure Application Gateway - Azure CLI
Quickstart: Direct web traffic with Azure Application
Gateway - Azure portal
5/1/2018 • 4 minutes to read • Edit Online
With Azure Application Gateway, you can direct your application web traffic to specific resources by assigning
listeners to ports, creating rules, and adding resources to a backend pool.
This quickstart shows you how to use the Azure portal to quickly create the application gateway with two virtual
machines in its backend pool. You then test it to make sure it's working correctly.
If you don't have an Azure subscription, create a free account before you begin.
Log in to Azure
Log in to the Azure portal at http://portal.azure.com
3. Enter myBackendSubnet for the name of the subnet and then click OK.
Set-AzureRmVMExtension `
-ResourceGroupName myResourceGroupAG `
-ExtensionName IIS `
-VMName myVM `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.4 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content
-Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS
3. Create a second virtual machine and install IIS using the steps that you just finished. Enter myVM2 for its
name and for VMName in Set-AzureRmVMExtension.
Add backend servers
After you create the virtual machines, you need to add them to the backend pool in the application gateway.
1. Click All resources > myAppGateway.
2. Click Backend pools. A default pool was automatically created with the application gateway. Click
appGatewayBackendPool.
3. Click Add target > Virtual machine, and then select myVM. Select Add target > Virtual machine, and
then select myVM2.
4. Click Save.
2. Copy the public IP address, and then paste it into the address bar of your browser.
When you refresh the browser, you should see the name of the other VM appear.
Clean up resources
First explore the resources that were created with the application gateway, and then when no longer needed, you
can delete the resource group, application gateway, and all related resources. To do so, select the resource group
that contains the application gateway and click Delete.
Next steps
Manage web traffic with an application gateway using the Azure CLI
Quickstart: Direct web traffic with Azure Application
Gateway - Azure PowerShell
5/1/2018 • 5 minutes to read • Edit Online
With Azure Application Gateway, you can direct your application web traffic to specific resources by assigning
listeners to ports, creating rules, and adding resources to a backend pool.
This quickstart shows you how to use the Azure portal to quickly create the application gateway with two virtual
machines in its backend pool. You then test it to make sure it's working correctly.
If you don't have an Azure subscription, create a free account before you begin.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
If you choose to install and use the PowerShell locally, this tutorial requires the Azure PowerShell module version
3.6 or later. To find the version, run Get-Module -ListAvailable AzureRM . If you need to upgrade, see Install Azure
PowerShell module. If you are running PowerShell locally, you also need to run Login-AzureRmAccount to create a
connection with Azure.
$defaultlistener = New-AzureRmApplicationGatewayHttpListener `
-Name myAGListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendport
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultlistener `
-BackendAddressPool $backendPool `
-BackendHttpSettings $poolSettings
When you refresh the browser, you should see the name of the other VM appear.
Clean up resources
First explore the resources that were created with the application gateway, and then when no longer needed, you
can use the Remove-AzureRmResourceGroup command to remove the resource group, application gateway, and
all related resources.
Next steps
Manage web traffic with an application gateway using Azure PowerShell
Quickstart: Direct web traffic with Azure Application
Gateway - Azure CLI
4/25/2018 • 5 minutes to read • Edit Online
With Azure Application Gateway, you can direct your application web traffic to specific resources by assigning
listeners to ports, creating rules, and adding resources to a backend pool.
This quickstart shows you how to use the Azure CLI to quickly create the application gateway with two virtual
machines in its backend pool. You then test it to make sure it's working correctly.
If you don't have an Azure subscription, create a free account before you begin.
If you choose to install and use the CLI locally, this quickstart requires that you run the Azure CLI version 2.0.4 or
later. To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.
Create the network interfaces with az network nic create. Create the virtual machines with az vm create.
It may take up to 30 minutes for the application gateway to be created. After the application gateway is created,
you can see these features of it:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.
When you refresh the browser, you should see the name of the other VM appear.
Clean up resources
First explore the resources that were created with the application gateway, and then when no longer needed, you
can use the az group delete command to remove the resource group, application gateway, and all related
resources.
Next steps
Manage web traffic with an application gateway using the Azure CLI
Tutorial: Manage web traffic with an application
gateway using the Azure CLI
7/16/2018 • 4 minutes to read • Edit Online
Application gateway is used to manage and secure web traffic to servers that you maintain. You can use the Azure
CLI to create an application gateway that uses a virtual machine scale set for backend servers to manage web
traffic. In this example, the scale set contains two virtual machine instances that are added to the default backend
pool of the application gateway.
In this tutorial, you learn how to:
Set up the network
Create an application gateway
Create a virtual machine scale set with the default backend pool
If you prefer, you can complete this tutorial using Azure PowerShell.
If you don't have an Azure subscription, create a free account before you begin.
If you choose to install and use the CLI locally, this quickstart requires that you are running the Azure CLI version
2.0.4 or later. To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.
It may take several minutes for the application gateway to be created. After the application gateway is created, you
will see these new features:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.
Install NGINX
Now you can install NGINX on the virtual machine scale set so you can test HTTP connectivity to the backend
pool.
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources.
Next steps
In this tutorial, you learned how to:
Set up the network
Create an application gateway
Create a virtual machine scale set with the default backend pool
Restrict web traffic with a web application firewall
Tutorial: Enable web application firewall using the
Azure CLI
7/16/2018 • 4 minutes to read • Edit Online
You can restrict traffic on an application gateway with a web application firewall (WAF ). The WAF uses OWASP
rules to protect your application. These rules include protection against attacks such as SQL injection, cross-site
scripting attacks, and session hijacks.
In this tutorial, you learn how to:
Set up the network
Create an application gateway with WAF enabled
Create a virtual machine scale set
Create a storage account and configure diagnostics
If you prefer, you can complete this tutorial using Azure PowerShell.
If you don't have an Azure subscription, create a free account before you begin.
If you choose to install and use the CLI locally, this tutorial requires that you are running the Azure CLI version
2.0.4 or later. To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.
It may take several minutes for the application gateway to be created. After the application gateway is created, you
can see these new features of it:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.
az vmss create \
--name myvmss \
--resource-group myResourceGroupAG \
--image UbuntuLTS \
--admin-username azureuser \
--admin-password Azure123456! \
--instance-count 2 \
--vnet-name myVNet \
--subnet myBackendSubnet \
--vm-sku Standard_DS2 \
--upgrade-policy-mode Automatic \
--app-gateway myAppGateway \
--backend-pool-name appGatewayBackendPool
Install NGINX
Configure diagnostics
Configure diagnostics to record data into the ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog,
and ApplicationGatewayFirewallLog logs. Substitute <subscriptionId> with your subscription identifier and then
configure diagnostics with az monitor diagnostic-settings create.
storeid=$(az storage account show --name myagstore1 --resource-group myResourceGroupAG --query id -o tsv)
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources.
Next steps
In this tutorial, you learned how to:
Set up the network
Create an application gateway with WAF enabled
Create a virtual machine scale set
Create a storage account and configure diagnostics
Create an application gateway with SSL termination
Tutorial: Create an application gateway with SSL
termination using the Azure CLI
7/16/2018 • 4 minutes to read • Edit Online
You can use the Azure CLI to create an application gateway with a certificate for SSL termination that uses a
virtual machine scale set for backend servers. In this example, the scale set contains two virtual machine instances
that are added to the default backend pool of the application gateway.
In this tutorial, you learn how to:
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate
Create a virtual machine scale set with the default backend pool
If you prefer, you can complete this tutorial using Azure PowerShell.
If you don't have an Azure subscription, create a free account before you begin.
If you choose to install and use the CLI locally, this tutorial requires you to run the Azure CLI version 2.0.4 or later.
To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out appgwcert.crt
Enter values that make sense for your certificate. You can accept the default values.
It may take several minutes for the application gateway to be created. After the application gateway is created, you
can see these new features of it:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.
az vmss create \
--name myvmss \
--resource-group myResourceGroupAG \
--image UbuntuLTS \
--admin-username azureuser \
--admin-password Azure123456! \
--instance-count 2 \
--vnet-name myVNet \
--subnet myBackendSubnet \
--vm-sku Standard_DS2 \
--upgrade-policy-mode Automatic \
--app-gateway myAppGateway \
--backend-pool-name appGatewayBackendPool
Install NGINX
To accept the security warning if you used a self-signed certificate, select Details and then Go on to the
webpage. Your secured NGINX site is then displayed as in the following example:
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources.
Next steps
In this tutorial, you learned how to:
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate
Create a virtual machine scale set with the default backend pool
Create an application gateway that hosts multiple web sites
Tutorial: Create an application gateway that hosts
multiple web sites using the Azure CLI
7/16/2018 • 6 minutes to read • Edit Online
You can use the Azure CLI to configure the hosting of multiple web sites when you create an application gateway.
In this tutorial, you define backend address pools using virtual machines scale sets. You then configure listeners
and rules based on domains that you own to make sure web traffic arrives at the appropriate servers in the pools.
This tutorial assumes that you own multiple domains and uses examples of www.contoso.com and
www.fabrikam.com.
In this tutorial, you learn how to:
Set up the network
Create an application gateway
Create backend listeners
Create routing rules
Create virtual machine scale sets with the backend pools
Create a CNAME record in your domain
If you prefer, you can complete this tutorial using Azure PowerShell.
If you don't have an Azure subscription, create a free account before you begin.
if [ $i -eq 1 ]
then
poolName="contosoPool"
fi
if [ $i -eq 2 ]
then
poolName="fabrikamPool"
fi
az vmss create \
--name myvmss$i \
--resource-group myResourceGroupAG \
--image UbuntuLTS \
--admin-username azureuser \
--admin-password Azure123456! \
--instance-count 2 \
--vnet-name myVNet \
--subnet myBackendSubnet \
--vm-sku Standard_DS2 \
--upgrade-policy-mode Automatic \
--app-gateway myAppGateway \
--backend-pool-name $poolName
done
Install NGINX
for i in `seq 1 2`; do
done
The use of A-records is not recommended because the VIP may change when the application gateway is restarted.
Change the address to your other domain and you should see something like the following example:
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources.
You can use Azure CLI to configure web traffic routing to specific scalable server pools based on the URL that is
used to access your application. In this tutorial, you create an Azure Application Gateway with three backend pools
using Virtual Machine Scale Sets. Each of the backend pools serves a specific purpose such as, common data,
images, and video. Routing traffic to separate pools ensures that your customers get the information that they
need when they need it.
To enable traffic routing, you create routing rules assigned to listeners that listen on specific ports to ensure web
traffic arrives at the appropriate servers in the pools.
In this tutorial, you learn how to:
Set up the network
Create listeners, URL path map, and rules
Create scalable backend pools
If you prefer, you can complete this tutorial using Azure PowerShell.
If you don't have an Azure subscription, create a free account before you begin.
If you choose to install and use the CLI locally, this tutorial requires you to run the Azure CLI version 2.0.4 or later.
To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.
It may take several minutes to create the application gateway. After the application gateway is created, you can see
these new features:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.
Add image and video backend pools and port
Add backend pools named imagesBackendPool and videoBackendPool to your application gateway by using az
network application-gateway address-pool create. You add the frontend port for the pools using az network
application-gateway frontend-port create.
if [ $i -eq 1 ]
then
poolName="appGatewayBackendPool"
fi
if [ $i -eq 2 ]
then
poolName="imagesBackendPool"
fi
if [ $i -eq 3 ]
then
poolName="videoBackendPool"
fi
az vmss create \
--name myvmss$i \
--resource-group myResourceGroupAG \
--image UbuntuLTS \
--admin-username azureuser \
--admin-password Azure123456! \
--instance-count 2 \
--vnet-name myVNet \
--subnet myBackendSubnet \
--vm-sku Standard_DS2 \
--upgrade-policy-mode Automatic \
--app-gateway myAppGateway \
--backend-pool-name $poolName
done
Install NGINX
Change the URL to http://<ip-address>:8080/video/test.html, substituting your IP address for <ip-address>, and
you should see something like the following example.
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources.
Next steps
In this tutorial, you learned how to:
Set up the network
Create listeners, URL path map, and rules
Create scalable backend pools
Create an application gateway with URL path-based redirection
Tutorial: Create an application gateway with URL
path-based redirection using the Azure CLI
7/16/2018 • 6 minutes to read • Edit Online
You can use the Azure CLI to configure URL path-based routing rules when you create an application gateway. In
this tutorial, you create backend pools using virtual machine scale sets. You then create URL routing rules that
make sure web traffic is redirected to the appropriate backend pool.
In this tutorial, you learn how to:
Set up the network
Create an application gateway
Add listeners and routing rules
Create virtual machine scale sets for backend pools
The following example shows site traffic coming from both ports 8080 and 8081 and being directed to the same
backend pools:
If you prefer, you can complete this tutorial using Azure PowerShell.
If you don't have an Azure subscription, create a free account before you begin.
If you choose to install and use the CLI locally, this quickstart requires that you are running the Azure CLI version
2.0.4 or later. To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.
It may take several minutes for the application gateway to be created. After the application gateway is created, you
can see these new features:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.
Add backend pools and ports
You can add backend address pools named imagesBackendPool and videoBackendPool to your application
gateway by using az network application-gateway address-pool create. You add the frontend ports for the pools
using az network application-gateway frontend-port create.
az vmss create \
--name myvmss$i \
--resource-group myResourceGroupAG \
--image UbuntuLTS \
--admin-username azureuser \
--admin-password Azure123456! \
--instance-count 2 \
--vnet-name myVNet \
--subnet myBackendSubnet \
--vm-sku Standard_DS2 \
--upgrade-policy-mode Automatic \
--app-gateway myAppGateway \
--backend-pool-name $poolName
done
Install NGINX
for i in `seq 1 3`; do
az vmss extension set \
--publisher Microsoft.Azure.Extensions \
--version 2.0 \
--name CustomScript \
--resource-group myResourceGroupAG \
--vmss-name myvmss$i \
--settings '{ "fileUris": ["https://raw.githubusercontent.com/Azure/azure-docs-powershell-
samples/master/application-gateway/iis/install_nginx.sh"], "commandToExecute": "./install_nginx.sh" }'
done
Change the URL to http://<ip-address>:8080/images/test.html, substituting your IP address for <ip-address>, and
you should see something like the following example:
Change the URL to http://<ip-address>:8080/video/test.html, substituting your IP address for <ip-address>, and
you should see something like the following example:
Now, change the URL to http://<ip-address>:8081/images/test.htm, substituting your IP address for <ip-
address>, and you should see traffic redirected back to the images backend pool at http://<ip-
address>:8080/images.
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources.
Next steps
In this tutorial, you learned how to:
Set up the network
Create an application gateway
Add listeners and routing rules
Create virtual machine scale sets for backend pools
Learn more about what you can do with application gateway
Azure Application Gateway PowerShell samples
5/1/2018 • 2 minutes to read • Edit Online
The following table includes links to Azure PowerShell script samples that create application gateways.
Manage web traffic Creates an application gateway and all related resources.
Restrict web traffic Creates an application gateway that restricts traffic using
OWASP rules.
Azure Application Gateway Azure CLI samples
5/1/2018 • 2 minutes to read • Edit Online
The following table includes links to Azure CLI script samples that create application gateways.
Manage web traffic Creates an application gateway and all related resources.
Restrict web traffic Creates an application gateway that restricts traffic using
OWASP rules.
Overview of end to end SSL with Application
Gateway
7/10/2018 • 2 minutes to read • Edit Online
Application gateway supports SSL termination at the gateway, after which traffic typically flows unencrypted to
the backend servers. This feature allows web servers to be unburdened from costly encryption and decryption
overhead. However for some customers unencrypted communication to the backend servers is not an acceptable
option. This unencrypted communication could be due to security requirements, compliance requirements, or the
application may only accept a secure connection. For such applications, application gateway supports end to end
SSL encryption.
Overview
End to end SSL allows you to securely transmit sensitive data to the backend encrypted while still taking
advantage of the benefits of Layer 7 load balancing features which application gateway provides. Some of these
features are cookie-based session affinity, URL -based routing, support for routing based on sites, or ability to
inject X-Forwarded-* headers.
When configured with end to end SSL communication mode, application gateway terminates the SSL sessions at
the gateway and decrypts user traffic. It then applies the configured rules to select an appropriate backend pool
instance to route traffic to. Application gateway then initiates a new SSL connection to the backend server and re-
encrypts data using the backend server's public key certificate before transmitting the request to the backend. End
to end SSL is enabled by setting protocol setting in BackendHTTPSetting to HTTPS, which is then applied to a
backend pool. Each backend server in the backend pool with end to end SSL enabled must be configured with a
certificate to allow secure communication.
In this example, requests using TLS1.2 are routed to backend servers in Pool1 using end to end SSL.
End to end SSL and whitelisting of certificates
Application gateway only communicates with known backend instances that have whitelisted their certificate with
the application gateway. To enable whitelisting of certificates, you must upload the public key of backend server
certificates to the application gateway (not the root certificate). Only connections to known and whitelisted
backends are then allowed. The remaining backends results in a gateway error. Self-signed certificates are for test
purposes only and not recommended for production workloads. Such certificates have to be whitelisted with the
application gateway as described in the preceding steps before they can be used.
Next steps
After learning about end to end SSL, go to Configure an application gateway with SSL termination using the
Azure portal to create an application gateway using end to end SSL.
Application Gateway SSL policy overview
9/5/2017 • 2 minutes to read • Edit Online
You can use Azure Application Gateway to centralize SSL certificate management and reduce encryption and
decryption overhead from a back-end server farm. This centralized SSL handling also lets you specify a central
SSL policy that's suited to your organizational security requirements. This helps you meet compliance
requirements as well as security guidelines and recommended practices.
The SSL policy includes control of the SSL protocol version as well as the cipher suites and the order in which
ciphers are used during an SSL handshake. Application Gateway offers two mechanisms for controlling SSL policy.
You can use either a predefined policy or a custom policy.
Name AppGwSslPolicy20150501
MinProtocolVersion TLSv1_0
CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
AppGwSslPolicy20170401
PROPERTY VALUE
Name AppGwSslPolicy20170401
MinProtocolVersion TLSv1_1
Default False
CipherSuites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
AppGwSslPolicy20170401S
PROPERTY VALUE
Name AppGwSslPolicy20170401S
MinProtocolVersion TLSv1_2
Default False
CipherSuites TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Next steps
If you want to learn to configure an SSL policy, see Configure SSL policy on an application gateway.
Web application firewall (WAF)
4/25/2018 • 6 minutes to read • Edit Online
Web application firewall (WAF ) is a feature of Application Gateway that provides centralized protection of your
web applications from common exploits and vulnerabilities.
Web application firewall is based on rules from the OWASP core rule sets 3.0 or 2.2.9. Web applications are
increasingly targets of malicious attacks that exploit common known vulnerabilities. Common among these
exploits are SQL injection attacks, cross site scripting attacks to name a few. Preventing such attacks in application
code can be challenging and may require rigorous maintenance, patching and monitoring at multiple layers of the
application topology. A centralized web application firewall helps make security management much simpler and
gives better assurance to application administrators against threats or intrusions. A WAF solution can also react to
a security threat faster by patching a known vulnerability at a central location versus securing each of individual
web applications. Existing application gateways can be converted to a web application firewall enabled application
gateway easily.
Application Gateway operates as an application delivery controller and offers SSL termination, cookie-based
session affinity, round-robin load distribution, content-based routing, ability to host multiple websites and security
enhancements. Security enhancements offered by Application Gateway include SSL policy management, end to
end SSL support. Application security is now strengthened by WAF (web application firewall) being directly
integrated into the ADC offering. This provides an easy to configure central location to manage and protect your
web applications against common web vulnerabilities.
Benefits
The following are the core benefits that Application Gateway and web application firewall provide:
Protection
Protect your web application from web vulnerabilities and attacks without modification to backend code.
Protect multiple web applications at the same time behind an application gateway. Application gateway
supports hosting up to 20 websites behind a single gateway that could all be protected against web attacks
with WAF.
Monitoring
Monitor your web application against attacks using a real-time WAF log. This log is integrated with Azure
Monitor to track WAF alerts and logs and easily monitor trends.
WAF will be integrated with Azure Security Center soon. Azure Security Center allows for a central view of
the security state of all your Azure resources.
Customization
The ability to customize WAF rules and rule groups to suit your application requirements and eliminate false
positives.
Features
Web application firewall comes preconfigured with CRS 3.0 by default or you can choose to use 2.2.9. CRS 3.0
offers reduced false positives over 2.2.9. The ability to customize rules to suit your needs is provided. Some of the
common web vulnerabilities which web application firewall protects against includes:
SQL injection protection
Cross site scripting protection
Common Web Attacks Protection such as command injection, HTTP request smuggling, HTTP response
splitting, and remote file inclusion attack
Protection against HTTP protocol violations
Protection against HTTP protocol anomalies such as missing host user-agent and accept headers
Prevention against bots, crawlers, and scanners
Detection of common application misconfigurations (i.e. Apache, IIS, etc.)
For a more detailed list of rules and their protections see the following Core rule sets.
Core rule sets
Application Gateway supports two rule sets, CRS 3.0, and CRS 2.2.9. These core rules sets are collections of rules
that protect your web applications for malicious activity.
OWASP_3.0
The 3.0 core rule set provided has 13 rule groups as shown in the following table. Each of these rule groups
contains multiple rules, which can be disabled.
RULEGROUP DESCRIPTION
OWASP_2.2.9
The 2.2.9 core rule set provided has 10 rule groups as shown in the following table. Each of these rule groups
contains multiple rules, which can be disabled.
RULEGROUP DESCRIPTION
WAF Modes
Application Gateway WAF can be configured to run in the following two modes:
Detection mode – When configured to run in detection mode, Application Gateway WAF monitors and logs
all threat alerts in to a log file. Logging diagnostics for Application Gateway should be turned on using the
Diagnostics section. You also need to ensure that the WAF log is selected and turned on. When running in
detection mode web application firewall does not block incoming requests.
Prevention mode – When configured to run in prevention mode, Application Gateway actively blocks
intrusions and attacks detected by its rules. The attacker receives a 403 unauthorized access exception and the
connection is terminated. Prevention mode continues to log such attacks in the WAF logs.
WAF Monitoring
Monitoring the health of your application gateway is important. Monitoring the health of your web application
firewall and the applications that it protects are provided through logging and integration with Azure Monitor,
Azure Security Center (coming soon), and Log Analytics.
Azure Monitor
Each application gateway log is integrated with Azure Monitor. This allows you to track diagnostic information
including WAF alerts and logs. This capability is provided within the Application Gateway resource in the portal
under the Diagnostics tab or through the Azure Monitor service directly. To learn more about enabling diagnostic
logs for application gateway visit Application Gateway diagnostics
Azure Security Center
Azure Security Center helps you prevent, detect, and respond to threats with increased visibility into and control
over the security of your Azure resources. Application gateway now integrates into Azure Security Center. Azure
Security Center scans your environment to detect unprotected web applications. It can now recommend
application gateway WAF to protect these vulnerable resources. You can directly create application gateway WAF
from the Azure Security Center. These WAF instances are integrated with Azure Security Center and will send
alerts and health information back to Azure Security Center for reporting.
Logging
Application Gateway WAF provides detailed reporting on each threat it detects. Logging is integrated with Azure
Diagnostics logs and alerts are recorded in a json format. These logs can be integrated with Log Analytics.
{
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupId}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEW
AYS/{appGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"time": "2017-03-20T15:52:09.1494499Z",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIp": "104.210.252.3",
"clientPort": "4835",
"requestUri": "/?a=%3Cscript%3Ealert(%22Hello%22);%3C/script%3E",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.0",
"ruleId": "941320",
"message": "Possible XSS Attack Detected - HTML Tag Handler",
"action": "Blocked",
"site": "Global",
"details": {
"message": "Warning. Pattern match \"
<(a|abbr|acronym|address|applet|area|audioscope|b|base|basefront|bdo|bgsound|big|blackface|blink|blockquote|bo
dy|bq|br|button|caption|center|cite|code|col|colgroup|comment|dd|del|dfn|dir|div|dl|dt|em|embed|fieldset|fn|fo
nt|form|frame|frameset|h1|head|h ...\" at ARGS:a.",
"data": "Matched Data: <script> found within ARGS:a: <script>alert(\\x22hello\\x22);</script>",
"file": "rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf",
"line": "865"
}
}
}
Next steps
After learning more about the capabilities of WAF, visit How to configure web application firewall on Application
Gateway.
Azure Application Gatewaty URL path based routing
overview
4/25/2018 • 2 minutes to read • Edit Online
URL Path Based Routing allows you to route traffic to back-end server pools based on URL Paths of the request.
One of the scenarios is to route requests for different content types to different backend server pools.
In the following example, Application Gateway is serving traffic for contoso.com from three back-end server pools
for example: VideoServerPool, ImageServerPool, and DefaultServerPool.
IMPORTANT
Rules are processed in the order they are listed in the portal. It is highly recommended to configure multi-site listeners first
prior to configuring a basic listener. This ensures that traffic gets routed to the right back end. If a basic listener is listed first
and matches an incoming request, it gets processed by that listener.
NOTE
PathPattern: This setting is a list of path patterns to match. Each must start with / and the only place a "*" is allowed is at the
end following a "/." The string fed to the path matcher does not include any text after the first? or #, and those chars are not
allowed here.
You can check out a Resource Manager template using URL -based routing for more information.
PathBasedRouting rule
RequestRoutingRule of type PathBasedRouting is used to bind a listener to a urlPathMap. All requests that are
received for this listener are routed based on policy specified in urlPathMap. Snippet of PathBasedRouting rule:
"requestRoutingRules": [
{
"name": "{ruleName}",
"id":
"/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/requestRoutingRules/{ru
leName}",
"properties": {
"ruleType": "PathBasedRouting",
"httpListener": {
"id":
"/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/httpListeners/<listener
Name>"
},
"urlPathMap": {
"id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/
urlPathMaps/{urlpathMapName}"
},
}
}
]
Next steps
After learning about URL -based content routing, go to create an application gateway using URL -based routing to
create an application gateway with URL routing rules.
Application Gateway multiple site hosting
4/25/2018 • 2 minutes to read • Edit Online
Multiple site hosting enables you to configure more than one web application on the same application gateway
instance. This feature allows you to configure a more efficient topology for your deployments by adding up to 20
websites to one application gateway. Each website can be directed to its own backend pool. In the following
example, application gateway is serving traffic for contoso.com and fabrikam.com from two back-end server pools
called ContosoServerPool and FabrikamServerPool.
IMPORTANT
Rules are processed in the order they are listed in the portal. It is highly recommended to configure multi-site listeners first
prior to configuring a basic listener. This will ensure that traffic gets routed to the right back end. If a basic listener is listed
first and matches an incoming request, it gets processed by that listener.
Requests for http://contoso.com are routed to ContosoServerPool, and http://fabrikam.com are routed to
FabrikamServerPool.
Similarly two subdomains of the same parent domain can be hosted on the same application gateway
deployment. Examples of using subdomains could include http://blog.contoso.com and http://app.contoso.com
hosted on a single application gateway deployment.
"httpListeners": [
{
"name": "appGatewayHttpsListener1",
"properties": {
"FrontendIPConfiguration": {
"Id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/frontendIPConfigurations/DefaultFrontendPublicIP"
},
"FrontendPort": {
"Id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/frontendPorts/appGatewayFrontendPort443'"
},
"Protocol": "Https",
"SslCertificate": {
"Id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/sslCertificates/appGatewaySslCert1'"
},
"HostName": "contoso.com",
"RequireServerNameIndication": "true"
}
},
{
"name": "appGatewayHttpListener2",
"properties": {
"FrontendIPConfiguration": {
"Id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/frontendIPConfigurations/appGatewayFrontendIP'"
},
"FrontendPort": {
"Id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/frontendPorts/appGatewayFrontendPort80'"
},
"Protocol": "Http",
"HostName": "fabrikam.com",
"RequireServerNameIndication": "false"
}
}
],
You can visit Resource Manager template using multiple site hosting for an end to end template-based
deployment.
Routing rule
There is no change required in the routing rule. The routing rule 'Basic' should continue to be chosen to tie the
appropriate site listener to the corresponding backend address pool.
"requestRoutingRules": [
{
"name": "<ruleName1>",
"properties": {
"RuleType": "Basic",
"httpListener": {
"id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/httpListeners/appGatewayHttpsListener1')]"
},
"backendAddressPool": {
"id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/backendAddressPools/ContosoServerPool')]"
},
"backendHttpSettings": {
"id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
},
{
"name": "<ruleName2>",
"properties": {
"RuleType": "Basic",
"httpListener": {
"id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/httpListeners/appGatewayHttpListener2')]"
},
"backendAddressPool": {
"id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/backendAddressPools/FabrikamServerPool')]"
},
"backendHttpSettings": {
"id":
"/subscriptions/<subid>/resourceGroups/<rgName>/providers/Microsoft.Network/applicationGateways/applicationGat
eway1/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
}
]
Next steps
After learning about multiple site hosting, go to create an application gateway using multiple site hosting to create
an application gateway with ability to support more than one web application.
Application Gateway redirect overview
5/1/2018 • 2 minutes to read • Edit Online
A common scenario for many web applications is to support automatic HTTP to HTTPS redirection to ensure all
communication between application and its users occurs over an encrypted path. In the past, customers have used
techniques such as creating a dedicated backend pool whose sole purpose is to redirect requests it receives on
HTTP to HTTPS.
Application Gateway now supports the ability to redirect traffic on the gateway. This simplifies application
configuration, optimizes the resource usage, and supports new redirection scenarios including global and path-
based redirection. Application Gateway redirection support is not limited to HTTP -> HTTPS redirection alone. It
has a generic redirection mechanism, which allows for traffic redirection received at one listener to another listener
on Application Gateway. External site redirection is also supported.
Application Gateway redirection support offers the following capabilities:
Global redirection
Redirects from one listener to another listener on the gateway. This enables HTTP to HTTPS redirection on a
site.
Path-based redirection
This type of redirection enables HTTP to HTTPS redirection only on a specific site area, for example a
shopping cart area denoted by /cart/*.
Redirect to external site
With this change, customers need to create a new redirect configuration object, which specifies the target listener
or external site to which redirection is desired. The configuration element also supports options to enable
appending the URI path and query string to the redirected URL. You can also choose whether redirection is a
temporary (HTTP status code 302) or a permanent redirect (HTTP status code 301). Once created, this redirect
configuration is attached to the source listener via a new rule. When using a basic rule, the redirect configuration is
associated with a source listener and is a global redirect. When a path-based rule is used, the redirect configuration
is defined on the URL path map. So it only applies to the specific path area of a site.
Next steps
Configure URL redirection on an application gateway
Application Gateway support for multi-tenant back
ends
5/1/2018 • 2 minutes to read • Edit Online
Azure Application Gateway supports virtual machine scale sets, network interfaces, public/private IP, or fully
qualified domain name (FQDN ) as part of its back end pools. By default, application gateway does not change the
incoming HTTP host header from the client and sends the header unaltered to the back end. There are many
services like Azure Web Apps that are multi-tenant in nature and rely on a specific host header or SNI extension to
resolve to the correct endpoint. Application Gateway now supports the ability for users to overwrite the incoming
HTTP host header based on the back end HTTP settings. This capability enables support for multi-tenant back ends
Azure web apps and API management. This capability is available for both the standard and WAF SKU. Multi-
tenant back end support also works with SSL termination and end to end SSL scenarios.
The ability to specify a host override is defined at the HTTP settings and can be applied to any back end pool
during rule creation. Multi-tenant back ends support the following two ways of overriding host header and SNI
extension.
1. The ability to set the host name to a fixed value in the HTTP settings. This capability ensures that the host
header is overridden to this value for all traffic to the back end pool where the HTTP settings are applied.
When using end to end SSL, this overridden host name is used in the SNI extension. This capability enables
scenarios where a back end pool farm expects a host header that is different from the incoming customer
host header.
2. The ability to derive the host name from the IP or FQDN of the back end pool members. HTTP settings also
provide an option to pick the host name from a back end pool member's FQDN if configured with the
option to derive host name from an individual back end pool member. When using end to end SSL, this host
name is derived from the FQDN and is used in the SNI extension. This capability enables scenarios where a
back end pool can have two or more multi-tenant PaaS services like Azure web apps and the request's host
header to each member contains the host name derived from its FQDN.
NOTE
In both of the preceding cases the settings only affect the live traffic behavior and not the health probe behavior. Custom
probes already support the ability to specify a host header in the probe configuration. Custom probes now also support the
ability to derive the host header behavior from the currently configured HTTP settings. This configuration can be specified by
using the PickHostNameFromBackendHttpSettings parameter in the probe configuration. For end to end functionality to
work, both the probe and the HTTP settings must be modified to reflect the correct configuration.
With this capability, customers specify the options in the HTTP settings and custom probes to the appropriate
configuration. This setting is then tied to a listener and a back end pool by using a rule.
Next steps
Learn how to set up an application gateway with a web app as a back end pool member by visiting: Configure App
Service web apps with Application Gateway
Application Gateway health monitoring overview
6/18/2018 • 4 minutes to read • Edit Online
Azure Application Gateway by default monitors the health of all resources in its back-end pool and automatically
removes any resource considered unhealthy from the pool. Application Gateway continues to monitor the
unhealthy instances and adds them back to the healthy back-end pool once they become available and respond to
health probes. Application gateway sends the health probes with the same port that is defined in the back-end
HTTP settings. This configuration ensures that the probe is testing the same port that customers would be using to
connect to the backend.
In addition to using default health probe monitoring, you can also customize the health probe to suit your
application's requirements. In this article, both default and custom health probes are covered.
Once the match criteria is specified, it can be attached to probe configuration using a -Match parameter in
PowerShell.
Default health probe settings
PROBE PROPERTY VALUE DESCRIPTION
NOTE
The port is the same port as the back-end HTTP settings.
The default probe looks only at http://127.0.0.1:<port> to determine health status. If you need to configure the
health probe to go to a custom URL or modify any other settings, you must use custom probes as described in the
following steps:
Name Name of the probe. This name is used to refer to the probe in
back-end HTTP settings.
Protocol Protocol used to send the probe. The probe uses the protocol
defined in the back-end HTTP settings
Host Host name to send the probe. Applicable only when multi-site
is configured on Application Gateway, otherwise use
'127.0.0.1'. This value is different from VM host name.
Path Relative path of the probe. The valid path starts from '/'.
Unhealthy threshold Probe retry count. The back-end server is marked down after
the consecutive probe failure count reaches the unhealthy
threshold.
IMPORTANT
If Application Gateway is configured for a single site, by default the Host name should be specified as '127.0.0.1', unless
otherwise configured in custom probe. For reference a custom probe is sent to <protocol>://<host>:<port><path>. The
port used will be the same port as defined in the back-end HTTP settings.
NSG considerations
If there is a network security group (NSG ) on an application gateway subnet, port ranges 65503-65534 must be
opened on the application gateway subnet for inbound traffic. These ports are required for the backend health API
to work.
Additionally, outbound Internet connectivity can't be blocked, and traffic from the AzureLoadBalancer tag must be
allowed.
Next steps
After learning about Application Gateway health monitoring, you can configure a custom health probe in the Azure
portal or a custom health probe using PowerShell and the Azure Resource Manager deployment model.
Overview of WebSocket support in Application
Gateway
6/27/2017 • 2 minutes to read • Edit Online
Application Gateway provides native support for WebSocket across all gateway sizes. There is no user-
configurable setting to selectively enable or disable WebSocket support.
WebSocket protocol standardized in RFC6455 enables a full duplex communication between a server and a client
over a long running TCP connection. This feature allows for a more interactive communication between the web
server and the client, which can be bidirectional without the need for polling as required in HTTP -based
implementations. WebSocket has low overhead unlike HTTP and can reuse the same TCP connection for multiple
request/responses resulting in a more efficient utilization of resources. WebSocket protocols are designed to work
over traditional HTTP ports of 80 and 443.
You can continue using a standard HTTP listener on port 80 or 443 to receive WebSocket traffic. WebSocket traffic
is then directed to the WebSocket enabled backend server using the appropriate backend pool as specified in
application gateway rules. The backend server must respond to the application gateway probes, which are
described in the health probe overview section. Application gateway health probes are HTTP/HTTPS only. Each
backend server must respond to HTTP probes for application gateway to route WebSocket traffic to the server.
}, {
"name": "<ruleName2>",
"properties": {
"RuleType": "Basic",
"httpListener": {
"id":
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGate
ways/{applicationGatewayName}/httpListeners/appGatewayHttpListener')]"
},
"backendAddressPool": {
"id":
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGate
ways/{applicationGatewayName}/backendAddressPools/ContosoServerPool')]"
},
"backendHttpSettings": {
"id":
"/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/applicationGate
ways/{applicationGatewayName}/backendHttpSettingsCollection/appGatewayBackendHttpSettings')]"
}
}
}]
Another reason for this is that application gateway backend health probe supports HTTP and HTTPS protocols
only. If the backend server does not respond to HTTP or HTTPS probes, it is taken out of backend pool.
Next steps
After learning about WebSocket support, go to create an application gateway to get started with a WebSocket
enabled web application.
Manage web traffic with an application gateway
using Azure PowerShell
7/13/2018 • 5 minutes to read • Edit Online
Application gateway is used to manage and secure web traffic to servers that you maintain. You can use Azure
PowerShell to create an application gateway that uses a virtual machine scale set for backend servers to manage
web traffic. In this example, the scale set contains two virtual machine instances that are added to the default
backend pool of the application gateway.
In this tutorial, you learn how to:
Set up the network
Create an application gateway
Create a virtual machine scale set with the default backend pool
If you don't have an Azure subscription, create a free account before you begin.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
If you choose to install and use PowerShell locally, this tutorial requires the Azure PowerShell module version 3.6
or later. To find the version, run Get-Module -ListAvailable AzureRM . If you need to upgrade, see Install Azure
PowerShell module. If you are running PowerShell locally, you also need to run Login-AzureRmAccount to create a
connection with Azure.
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.2.0/24
$vnet = New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
$pip = New-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$subnet=$vnet.Subnets[0]
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendport = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 80
Create the backend pool and settings
Create the backend pool named appGatewayBackendPool for the application gateway using New -
AzureRmApplicationGatewayBackendAddressPool. Configure the settings for the backend address pools using
New -AzureRmApplicationGatewayBackendHttpSettings.
$defaultPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool
$poolSettings = New-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings `
-Port 80 `
-Protocol Http `
-CookieBasedAffinity Enabled `
-RequestTimeout 120
$defaultlistener = New-AzureRmApplicationGatewayHttpListener `
-Name mydefaultListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendport
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultlistener `
-BackendAddressPool $defaultPool `
-BackendHttpSettings $poolSettings
$sku = New-AzureRmApplicationGatewaySku `
-Name Standard_Medium `
-Tier Standard `
-Capacity 2
$appgw = New-AzureRmApplicationGateway `
-Name myAppGateway `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-BackendAddressPools $defaultPool `
-BackendHttpSettingsCollection $poolSettings `
-FrontendIpConfigurations $fipconfig `
-GatewayIpConfigurations $gipconfig `
-FrontendPorts $frontendport `
-HttpListeners $defaultlistener `
-RequestRoutingRules $frontendRule `
-Sku $sku
Create a virtual machine scale set
In this example, you create a virtual machine scale set to provide servers for the backend pool in the application
gateway. You assign the scale set to the backend pool when you configure the IP settings.
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$backendPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool `
-ApplicationGateway $appgw
$ipConfig = New-AzureRmVmssIpConfig `
-Name myVmssIPConfig `
-SubnetId $vnet.Subnets[1].Id `
-ApplicationGatewayBackendAddressPoolsId $backendPool.Id
$vmssConfig = New-AzureRmVmssConfig `
-Location eastus `
-SkuCapacity 2 `
-SkuName Standard_DS2 `
-UpgradePolicyMode Automatic
Set-AzureRmVmssStorageProfile $vmssConfig `
-ImageReferencePublisher MicrosoftWindowsServer `
-ImageReferenceOffer WindowsServer `
-ImageReferenceSku 2016-Datacenter `
-ImageReferenceVersion latest `
-OsDiskCreateOption FromImage
Set-AzureRmVmssOsProfile $vmssConfig `
-AdminUsername azureuser `
-AdminPassword "Azure123456!" `
-ComputerNamePrefix myvmss
Add-AzureRmVmssNetworkInterfaceConfiguration `
-VirtualMachineScaleSet $vmssConfig `
-Name myVmssNetConfig `
-Primary $true `
-IPConfiguration $ipConfig
New-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss `
-VirtualMachineScaleSet $vmssConfig
Install IIS
$publicSettings = @{ "fileUris" = (,"https://raw.githubusercontent.com/Azure/azure-docs-powershell-
samples/master/application-gateway/iis/appgatewayurl.ps1");
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File appgatewayurl.ps1" }
Update-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss `
-VirtualMachineScaleSet $vmss
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using Remove-
AzureRmResourceGroup.
Next steps
In this tutorial, you learned how to:
Set up the network
Create an application gateway
Create a virtual machine scale set with the default backend pool
Restrict web traffic with a web application firewall
Create an application gateway by using the Azure
Resource Manager template
5/1/2018 • 5 minutes to read • Edit Online
Azure Application Gateway is a layer-7 load balancer. It provides failover and performance-routing HTTP requests
between different servers, whether they are on the cloud or on-premises. Application Gateway provides many
application delivery controller (ADC ) features including HTTP load balancing, cookie-based session affinity, Secure
Sockets Layer (SSL ) offload, custom health probes, support for multi-site, and many others. To find a complete list
of supported features, visit Application Gateway overview
This article walks you through downloading and modifying an existing Azure Resource Manager template from
GitHub and deploying the template from GitHub, PowerShell, and the Azure CLI.
If you are simply deploying the template directly from GitHub without any changes, skip to deploy a template from
GitHub.
Scenario
In this scenario you will:
Create an application gateway with web application firewall.
Create a virtual network named VirtualNetwork1 with a reserved CIDR block of 10.0.0.0/16.
Create a subnet called Appgatewaysubnet that uses 10.0.0.0/28 as its CIDR block.
Set up two previously configured back-end IPs for the web servers you want to load balance the traffic. In this
template example, the back-end IPs are 10.0.1.10 and 10.0.1.11.
NOTE
Those settings are the parameters for this template. To customize the template, you can change rules, the listener, SSL, and
other options in the azuredeploy.json file.
PARAMETER DESCRIPTION
wafRuleSetVersion Ruleset version. OWASP CRS 2.2.9 and 3.0 are currently
the supported options.
7. Check the content under resources and notice the following properties:
type. Type of resource being created by the template. In this case, the type is
Microsoft.Network/applicationGateways , which represents an application gateway.
name. Name for the resource. Notice the use of [parameters('applicationGatewayName')] , which means
that the name is provided as input by you or by a parameter file during deployment.
properties. List of properties for the resource. This template uses the virtual network and public IP
address during application gateway creation.
8. Navigate back to https://github.com/Azure/azure-quickstart-templates/blob/master/101-application-
gateway-waf/.
9. Click azuredeploy-parameters.json, and then click RAW.
10. Save the file to a local folder on your computer.
11. Open the file that you saved and edit the values for the parameters. Use the following values to deploy the
application gateway described in our scenario.
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"addressPrefix": {
"value": "10.0.0.0/16"
},
"subnetPrefix": {
"value": "10.0.0.0/28"
},
"applicationGatewaySize": {
"value": "WAF_Medium"
},
"capacity": {
"value": 2
},
"backendIpAddress1": {
"value": "10.0.1.10"
},
"backendIpAddress2": {
"value": "10.0.1.11"
},
"wafEnabled": {
"value": true
},
"wafMode": {
"value": "Detection"
},
"wafRuleSetType": {
"value": "OWASP"
},
"wafRuleSetVersion": {
"value": "3.0"
}
}
}
12. Save the file. You can test the JSON template and parameter template by using online JSON validation
tools like JSlint.com.
Login-AzureRmAccount
Get-AzureRmSubscription
5. Run the New-AzureRmResourceGroupDeployment cmdlet to deploy the new virtual network by using
the preceding template and parameter files you downloaded and modified.
Deploy the Azure Resource Manager template by using the Azure CLI
To deploy the Azure Resource Manager template you downloaded by using Azure CLI, follow the following steps:
1. If you have never used Azure CLI, see Install and configure the Azure CLI and follow the instructions up to
the point where you select your Azure account and subscription.
2. If necessary, run the az group create command to create a resource group, as shown in the following code
snippet. Notice the output of the command. The list shown after the output explains the parameters used.
For more information about resource groups, visit Azure Resource Manager overview.
-n (or --name). Name for the new resource group. For our scenario, it's appgatewayRG.
-l (or --location). Azure region where the new resource group is created. For our scenario, it's westus.
3. Run the az group deployment create cmdlet to deploy the new virtual network by using the template and
parameter files you downloaded and modified in the preceding step. The list shown after the output explains
the parameters used.
4. Select I agree to the terms and conditions stated above and click Purchase.
5. On the Custom deployment blade, click Create.
Windows
Azure CLI
Next steps
If you want to configure SSL offload, visit: Configure an application gateway for SSL offload.
If you want to configure an application gateway to use with an internal load balancer, visit: Create an application
gateway with an internal load balancer (ILB ).
If you want more information about load balancing options in general, visit:
Azure Load Balancer
Azure Traffic Manager
Create an application gateway with an internal load
balancer (ILB)
5/25/2018 • 6 minutes to read • Edit Online
Azure Application Gateway can be configured with an Internet-facing VIP or with an internal endpoint that is not
exposed to the Internet, also known as an internal load balancer (ILB ) endpoint. Configuring the gateway with an
ILB is useful for internal line-of-business applications that are not exposed to the Internet. It's also useful for
services and tiers within a multi-tier application that sit in a security boundary that is not exposed to the Internet
but still require round-robin load distribution, session stickiness, or Secure Sockets Layer (SSL ) termination.
This article walks you through the steps to configure an application gateway with an ILB.
Connect-AzureRmAccount
Step 2
Check the subscriptions for the account.
Get-AzureRmSubscription
Step 4
Create a new resource group (skip this step if you're using an existing resource group).
Azure Resource Manager requires that all resource groups specify a location. This is used as the default location for
resources in that resource group. Make sure that all commands to create an application gateway uses the same
resource group.
In the preceding example, we created a resource group called "appgw -rg" and location "West US".
This step assigns the address range 10.0.0.0/24 to a subnet variable to be used to create a virtual network.
Step 2
This step creates a virtual network named "appgwvnet" in resource group "appgw -rg" for the West US region
using the prefix 10.0.0.0/16 with subnet 10.0.0.0/24.
Step 3
$subnet = $vnet.subnets[0]
This step assigns the subnet object to variable $subnet for the next steps.
This step creates an application gateway IP configuration named "gatewayIP01". When Application Gateway starts,
it picks up an IP address from the subnet configured and route network traffic to the IP addresses in the back-end
IP pool. Keep in mind that each instance takes one IP address.
Step 2
This step configures the back-end IP address pool named "pool01" with IP addresses "10.1.1.8, 10.1.1.9, 10.1.1.10".
Those are the IP addresses that receive the network traffic that comes from the front-end IP endpoint. You replace
the preceding IP addresses to add your own application IP address endpoints.
Step 3
This step configures application gateway setting "poolsetting01" for the load balanced network traffic in the back-
end pool.
Step 4
This step configures the front-end IP port named "frontendport01" for the ILB.
Step 5
This step creates the front-end IP configuration called "fipconfig01" and associates it with a private IP from the
current virtual network subnet.
Step 6
This step creates the listener called "listener01" and associates the front-end port to the front-end IP configuration.
Step 7
$rule = New-AzureRmApplicationGatewayRequestRoutingRule -Name rule01 -RuleType Basic -BackendHttpSettings
$poolSetting -HttpListener $listener -BackendAddressPool $pool
This step creates the load balancer routing rule called "rule01" that configures the load balancer behavior.
Step 8
NOTE
The default value for InstanceCount is 2, with a maximum value of 10. The default value for GatewaySize is Medium. You can
choose between Standard_Small, Standard_Medium, and Standard_Large.
This step creates an application gateway with all configuration items from the preceding steps. In the example, the
application gateway is called "appgwtest".
Step 2
Use Stop-AzureRmApplicationGateway to stop the application gateway. This sample shows the
Stop-AzureRmApplicationGateway cmdlet on the first line, followed by the output.
Once the application gateway is in a stopped state, use the Remove-AzureRmApplicationGateway cmdlet to remove the
service.
NOTE
The -force switch can be used to suppress the remove confirmation message.
To verify that the service has been removed, you can use the Get-AzureRmApplicationGateway cmdlet. This step is not
required.
Next steps
If you want to configure SSL offload, see Configure an application gateway for SSL offload.
If you want to configure an application gateway to use with an ILB, see Create an application gateway with an
internal load balancer (ILB ).
If you want more information about load balancing options in general, see:
Azure Load Balancer
Azure Traffic Manager
Configure an application gateway with SSL
termination using the Azure portal
5/21/2018 • 4 minutes to read • Edit Online
You can use the Azure portal to configure an application gateway with a certificate for SSL termination that uses
virtual machines for backend servers.
In this article, you learn how to:
Create a self-signed certificate
Create an application gateway with the certificate
Create the virtual machines used as backend servers
If you don't have an Azure subscription, create a free account before you begin.
Log in to Azure
Log in to the Azure portal at http://portal.azure.com
New-SelfSignedCertificate \
-certstorelocation cert:\localmachine\my \
-dnsname www.contoso.com
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\my
Thumbprint Subject
---------- -------
E1E81C23B3AD33F9B4D1717B20AB65DBB91AC630 CN=www.contoso.com
Set-AzureRmVMExtension `
-ResourceGroupName myResourceGroupAG `
-ExtensionName IIS `
-VMName myVM `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.4 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content
-Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS
3. Create a second virtual machine and install IIS using the steps that you just finished. Enter myVM2 for its
name and for VMName in Set-AzureRmVMExtension.
Add backend servers
1. Click All resources, and then click myAppGateway.
2. Click Backend pools. A default pool was automatically created with the application gateway. Click
appGateayBackendPool.
3. Click Add target to add each virtual machine that you created to the backend pool.
4. Click Save.
2. Copy the public IP address, and then paste it into the address bar of your browser. To accept the security
warning if you used a self-signed certificate, select Details and then Go on to the webpage:
Your secured IIS website is then displayed as in the following example:
Next steps
In this tutorial, you learned how to:
Create a self-signed certificate
Create an application gateway with the certificate
Create the virtual machines used as backend servers
To learn more about application gateways and their associated resources, continue to the how -to articles.
Create an application gateway with SSL termination
using Azure PowerShell
7/13/2018 • 5 minutes to read • Edit Online
You can use Azure PowerShell to create an application gateway with a certificate for SSL termination that uses a
virtual machine scale set for backend servers. In this example, the scale set contains two virtual machine instances
that are added to the default backend pool of the application gateway.
In this tutorial, you learn how to:
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate
Create a virtual machine scale set with the default backend pool
If you don't have an Azure subscription, create a free account before you begin.
This tutorial requires the Azure PowerShell module version 3.6 or later. Run Get-Module -ListAvailable AzureRM to
find the version. If you need to upgrade, see Install Azure PowerShell module. If you are running PowerShell
locally, you also need to run Login-AzureRmAccount to create a connection with Azure.
New-SelfSignedCertificate `
-certstorelocation cert:\localmachine\my `
-dnsname www.contoso.com
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\my
Thumbprint Subject
---------- -------
E1E81C23B3AD33F9B4D1717B20AB65DBB91AC630 CN=www.contoso.com
Export-PfxCertificate `
-cert cert:\localMachine\my\E1E81C23B3AD33F9B4D1717B20AB65DBB91AC630 `
-FilePath c:\appgwcert.pfx `
-Password $pwd
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.2.0/24
$vnet = New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
$pip = New-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$subnet=$vnet.Subnets[0]
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendport = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 443
Create the backend pool and settings
Create the backend pool named appGatewayBackendPool for the application gateway using New -
AzureRmApplicationGatewayBackendAddressPool. Configure the settings for the backend pool using New -
AzureRmApplicationGatewayBackendHttpSettings.
$defaultPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool
$poolSettings = New-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings `
-Port 80 `
-Protocol Http `
-CookieBasedAffinity Enabled `
-RequestTimeout 120
$pwd = ConvertTo-SecureString `
-String "Azure123456!" `
-Force `
-AsPlainText
$cert = New-AzureRmApplicationGatewaySslCertificate `
-Name "appgwcert" `
-CertificateFile "c:\appgwcert.pfx" `
-Password $pwd
$defaultlistener = New-AzureRmApplicationGatewayHttpListener `
-Name mydefaultListener `
-Protocol Https `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendport `
-SslCertificate $cert
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultlistener `
-BackendAddressPool $defaultPool `
-BackendHttpSettings $poolSettings
$appgw = New-AzureRmApplicationGateway `
-Name myAppGateway `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-BackendAddressPools $defaultPool `
-BackendHttpSettingsCollection $poolSettings `
-FrontendIpConfigurations $fipconfig `
-GatewayIpConfigurations $gipconfig `
-FrontendPorts $frontendport `
-HttpListeners $defaultlistener `
-RequestRoutingRules $frontendRule `
-Sku $sku `
-SslCertificates $cert
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$backendPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool `
-ApplicationGateway $appgw
$ipConfig = New-AzureRmVmssIpConfig `
-Name myVmssIPConfig `
-SubnetId $vnet.Subnets[1].Id `
-ApplicationGatewayBackendAddressPoolsId $backendPool.Id
$vmssConfig = New-AzureRmVmssConfig `
-Location eastus `
-SkuCapacity 2 `
-SkuName Standard_DS2 `
-UpgradePolicyMode Automatic
Set-AzureRmVmssStorageProfile $vmssConfig `
-ImageReferencePublisher MicrosoftWindowsServer `
-ImageReferenceOffer WindowsServer `
-ImageReferenceSku 2016-Datacenter `
-ImageReferenceVersion latest
-OsDiskCreateOption FromImage
Set-AzureRmVmssOsProfile $vmssConfig `
-AdminUsername azureuser `
-AdminPassword "Azure123456!" `
-ComputerNamePrefix myvmss
Add-AzureRmVmssNetworkInterfaceConfiguration `
-VirtualMachineScaleSet $vmssConfig `
-Name myVmssNetConfig `
-Primary $true `
-IPConfiguration $ipConfig
New-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss `
-VirtualMachineScaleSet $vmssConfig
Install IIS
Update-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss `
-VirtualMachineScaleSet $vmss
Test the application gateway
You can use Get-AzureRmPublicIPAddress to get the public IP address of the application gateway. Copy the public
IP address, and then paste it into the address bar of your browser.
To accept the security warning if you used a self-signed certificate, select Details and then Go on to the
webpage. Your secured IIS website is then displayed as in the following example:
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using Remove-
AzureRmResourceGroup.
Next steps
In this tutorial, you learned how to:
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate
Create a virtual machine scale set with the default backend pool
Create an application gateway that hosts multiple web sites
Renew Application Gateway certificates
5/21/2018 • 2 minutes to read • Edit Online
At some point, you'll need to renew your certificates if you configured your application gateway for SSL
encryption.
You can renew a certificate associated with a listener using either the Azure portal, Azure PowerShell, or Azure CLI:
Azure portal
To renew a listener certificate from the portal, navigate to your application gateway listeners. Click the listener that
has a certificate that needs to be renewed, and then click Renew or edit selected certificate.
Upload your new PFX certificate, give it a name, type the password, and then click Save.
Azure PowerShell
To renew your certificate using Azure PowerShell, use the following cmdlet:
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName <ResourceGroup> `
-Name <AppGatewayName>
$password = ConvertTo-SecureString `
-String "<password>" `
-Force `
-AsPlainText
Azure CLI
az network application-gateway ssl-cert update \
-n "<CertName>" \
--gateway-name "<AppGatewayName>" \
-g "ResourceGroupName>" \
--cert-file <PathToCerFile> \
--cert-password "<password>"
Next steps
To learn how to configure SSL Offloading with Azure Application Gateway, see Configure SSL Offload
Configure SSL policy versions and cipher suites on
Application Gateway
4/9/2018 • 4 minutes to read • Edit Online
Learn how to configure SSL policy versions and cipher suites on Application Gateway. You can select from a list of
predefined policies that contain different configurations of SSL policy versions and enabled cipher suites. You also
have the ability to define a custom SSL policy based on your requirements.
AvailableCipherSuites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
AvailableProtocols:
TLSv1_0
TLSv1_1
TLSv1_2
IMPORTANT
At least one cipher suite from the following list must be selected when configuring a custom SSL policy. Application gateway
uses RSA SHA256 cipher suites for backend management.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
# get an application gateway resource
$gw = Get-AzureRmApplicationGateway -Name AdatumAppGateway -ResourceGroup AdatumAppGatewayRG
# Create a new listener with the certificate, port, and frontend ip.
$listener = New-AzureRmApplicationGatewayHttpListener -Name listener01 -Protocol Https -
FrontendIPConfiguration $fipconfig -FrontendPort $fp -SslCertificate $cert
# Choose either custom policy or prefedined policy and uncomment the one you want to use.
# Update AppGW
# The SSL policy options are not validated or updated on the Application Gateway until this cmdlet is
executed.
$SetGW = Set-AzureRmApplicationGateway -ApplicationGateway $AppGW
Next steps
Visit Application Gateway redirect overview to learn how to redirect HTTP traffic to an HTTPS endpoint.
Create an application gateway with a web application
firewall using the Azure portal
5/1/2018 • 4 minutes to read • Edit Online
You can use the Azure portal to create an application gateway with a web application firewall (WAF ). The WAF uses
OWASP rules to protect your application. These rules include protection against attacks such as SQL injection,
cross-site scripting attacks, and session hijacks.
In this article, you learn how to:
Create an application gateway with WAF enabled
Create the virtual machines used as backend servers
Create a storage account and configure diagnostics
Log in to Azure
Log in to the Azure portal at http://portal.azure.com
3. Enter myBackendSubnet for the name of the subnet and then click OK.
Set-AzureRmVMExtension `
-ResourceGroupName myResourceGroupAG `
-ExtensionName IIS `
-VMName myVM `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.4 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content
-Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS
3. Create a second virtual machine and install IIS using the steps that you just finished. Enter myVM2 for its
name and for VMName in Set-AzureRmVMExtension.
Add backend servers
1. Click All resources, and then click myAppGateway.
2. Click Backend pools. A default pool was automatically created with the application gateway. Click
appGateayBackendPool.
3. Click Add target to add each virtual machine that you created to the backend pool.
4. Click Save.
Configure diagnostics
Configure diagnostics to record data into the ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog,
and ApplicationGatewayFirewallLog logs.
1. In the left-hand menu, click All resources, and then select myAppGateway.
2. Under Monitoring, click Diagnostics logs.
3. Click Add diagnostics setting.
4. Enter myDiagnosticsSettings as the name for the diagnostics settings.
5. Select Archive to a storage account, and then click Configure to select the myagstore1 storage account that
you previously created.
6. Select the application gateway logs to collect and retain.
7. Click Save.
Test the application gateway
1. Find the public IP address for the application gateway on the Overview screen. Click All resources and then
click myAGPublicIPAddress.
2. Copy the public IP address, and then paste it into the address bar of your browser.
Next steps
In this article, you learned how to:
Create an application gateway with WAF enabled
Create the virtual machines used as backend servers
Create a storage account and configure diagnostics
To learn more about application gateways and their associated resources, continue to the how -to articles.
Enable web application firewall using Azure
PowerShell
7/13/2018 • 6 minutes to read • Edit Online
You can restrict traffic on an application gateway with a web application firewall (WAF ). The WAF uses OWASP
rules to protect your application. These rules include protection against attacks such as SQL injection, cross-site
scripting attacks, and session hijacks.
In this tutorial, you learn how to:
Set up the network
Create an application gateway with WAF enabled
Create a virtual machine scale set
Create a storage account and configure diagnostics
If you prefer, you can complete this tutorial using Azure CLI.
If you don't have an Azure subscription, create a free account before you begin.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
If you choose to install and use the PowerShell locally, this tutorial requires the Azure PowerShell module version
3.6 or later. Run Get-Module -ListAvailable AzureRM to find the version. If you need to upgrade, see Install Azure
PowerShell module. If you are running PowerShell locally, you also need to run Login-AzureRmAccount to create a
connection with Azure.
Create a resource group
A resource group is a logical container into which Azure resources are deployed and managed. Create an Azure
resource group using New -AzureRmResourceGroup.
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.2.0/24
$vnet = New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
$pip = New-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic
$subnet=$vnet.Subnets[0]
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendport = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 80
$defaultPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool
$poolSettings = New-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings `
-Port 80 `
-Protocol Http `
-CookieBasedAffinity Enabled `
-RequestTimeout 120
$defaultlistener = New-AzureRmApplicationGatewayHttpListener `
-Name mydefaultListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendport
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultlistener `
-BackendAddressPool $defaultPool `
-BackendHttpSettings $poolSettings
$sku = New-AzureRmApplicationGatewaySku `
-Name WAF_Medium `
-Tier WAF `
-Capacity 2
$wafConfig = New-AzureRmApplicationGatewayWebApplicationFirewallConfiguration `
-Enabled $true `
-FirewallMode "Detection"
$appgw = New-AzureRmApplicationGateway `
-Name myAppGateway `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-BackendAddressPools $defaultPool `
-BackendHttpSettingsCollection $poolSettings `
-FrontendIpConfigurations $fipconfig `
-GatewayIpConfigurations $gipconfig `
-FrontendPorts $frontendport `
-HttpListeners $defaultlistener `
-RequestRoutingRules $frontendRule `
-Sku $sku `
-WebApplicationFirewallConfig $wafConfig
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$backendPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool `
-ApplicationGateway $appgw
$ipConfig = New-AzureRmVmssIpConfig `
-Name myVmssIPConfig `
-SubnetId $vnet.Subnets[1].Id `
-ApplicationGatewayBackendAddressPoolsId $backendPool.Id
$vmssConfig = New-AzureRmVmssConfig `
-Location eastus `
-SkuCapacity 2 `
-SkuName Standard_DS2 `
-UpgradePolicyMode Automatic
Set-AzureRmVmssStorageProfile $vmssConfig `
-ImageReferencePublisher MicrosoftWindowsServer `
-ImageReferenceOffer WindowsServer `
-ImageReferenceSku 2016-Datacenter `
-ImageReferenceVersion latest
-OsDiskCreateOption FromImage
Set-AzureRmVmssOsProfile $vmssConfig `
-AdminUsername azureuser `
-AdminPassword "Azure123456!" `
-ComputerNamePrefix myvmss
Add-AzureRmVmssNetworkInterfaceConfiguration `
-VirtualMachineScaleSet $vmssConfig `
-Name myVmssNetConfig `
-Primary $true `
-IPConfiguration $ipConfig
New-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss `
-VirtualMachineScaleSet $vmssConfig
Install IIS
Update-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss `
-VirtualMachineScaleSet $vmss
Create a storage account and configure diagnostics
In this tutorial, the application gateway uses a storage account to store data for detection and prevention
purposes. You could also use Log Analytics or Event Hub to record data.
Create the storage account
Create a storage account named myagstore1 using New -AzureRmStorageAccount.
$storageAccount = New-AzureRmStorageAccount `
-ResourceGroupName myResourceGroupAG `
-Name myagstore1 `
-Location eastus `
-SkuName "Standard_LRS"
Configure diagnostics
Configure diagnostics to record data into the ApplicationGatewayAccessLog,
ApplicationGatewayPerformanceLog, and ApplicationGatewayFirewallLog logs using Set-
AzureRmDiagnosticSetting.
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$store = Get-AzureRmStorageAccount `
-ResourceGroupName myResourceGroupAG `
-Name myagstore1
Set-AzureRmDiagnosticSetting `
-ResourceId $appgw.Id `
-StorageAccountId $store.Id `
-Categories ApplicationGatewayAccessLog, ApplicationGatewayPerformanceLog, ApplicationGatewayFirewallLog `
-Enabled $true `
-RetentionEnabled $true `
-RetentionInDays 30
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using
Remove-AzureRmResourceGroup.
Remove-AzureRmResourceGroup -Name myResourceGroupAG
Next steps
In this tutorial, you learned how to:
Set up the network
Create an application gateway with WAF enabled
Create a virtual machine scale set
Create a storage account and configure diagnostics
Create an application gateway with SSL termination
Customize web application firewall rules through the
Azure portal
5/1/2018 • 2 minutes to read • Edit Online
The Azure Application Gateway web application firewall (WAF ) provides protection for web applications. These
protections are provided by the Open Web Application Security Project (OWASP ) Core Rule Set (CRS ). Some
rules can cause false positives and block real traffic. For this reason, Application Gateway provides the capability to
customize rule groups and rules. For more information on the specific rule groups and rules, see List of web
application firewall CRS rule groups and rules.
NOTE
If your application gateway is not using the WAF tier, the option to upgrade the application gateway to the WAF tier appears
in the right pane.
The Azure Application Gateway web application firewall (WAF ) provides protection for web applications. These
protections are provided by the Open Web Application Security Project (OWASP ) Core Rule Set (CRS ). Some
rules can cause false positives and block real traffic. For this reason, Application Gateway provides the capability to
customize rule groups and rules. For more information on the specific rule groups and rules, see List of web
application firewall CRS Rule groups and rules.
Get-AzureRmApplicationGatewayAvailableWafRuleSets
REQUEST-910-IP-REPUTATION:
Description:
Rules:
RuleId Description
------ -----------
910011 Rule 910011
910012 Rule 910012
... ...
REQUEST-911-METHOD-ENFORCEMENT:
Description:
Rules:
RuleId Description
------ -----------
911011 Rule 911011
... ...
crs_20_protocol_violations:
Description:
Rules:
RuleId Description
------ -----------
960911 Invalid HTTP Request Line
981227 Apache Error: Invalid URI in Request.
960000 Attempted multipart/form-data bypass
... ...
Disable rules
The following example disables rules 910018 and 910017 on an application gateway:
Next steps
After you configure your disabled rules, you can learn how to view your WAF logs. For more information, see
Application Gateway Diagnostics.
Customize web application firewall rules through the
Azure CLI 2.0
5/1/2018 • 2 minutes to read • Edit Online
The Azure Application Gateway web application firewall (WAF ) provides protection for web applications. These
protections are provided by the Open Web Application Security Project (OWASP ) Core Rule Set (CRS ). Some
rules can cause false positives and block real traffic. For this reason, Application Gateway provides the capability to
customize rule groups and rules. For more information on the specific rule groups and rules, see List of web
application firewall CRS rule groups and rules.
Disable rules
The following example disables rules 910018 and 910017 on an application gateway:
Next steps
After you configure your disabled rules, you can learn how to view your WAF logs. For more information, see
Application Gateway diagnostics.
Create an application gateway with path-based
routing rules using the Azure portal
7/13/2018 • 4 minutes to read • Edit Online
You can use the Azure portal to configure URL path-based routing rules when you create an application gateway.
In this tutorial, you create backend pools using virtual machines. You then create routing rules that make sure web
traffic arrives at the appropriate servers in the pools.
In this article, you learn how to:
Create an application gateway
Create virtual machines for backend servers
Create backend pools with the backend servers
Create a backend listener
Create a path-based routing rule
If you don't have an Azure subscription, create a free account before you begin.
Log in to Azure
Log in to the Azure portal at http://portal.azure.com
3. Create two more virtual machines and install IIS using the steps that you just finished. Enter the names of
myVM2 and myVM3 for the names and for the values of VMName in Set-AzureRmVMExtension.
2. Copy the public IP address, and then paste it into the address bar of your browser. Such as,
http://40.121.222.19.
Next steps
In this article, you learned how to
Create an application gateway
Create virtual machines for backend servers
Create backend pools with the backend servers
Create a backend listener
Create a path-based routing rule
To learn more about application gateways and their associated resources, continue to the how -to articles.
Route web traffic based on the URL using Azure
PowerShell
7/13/2018 • 8 minutes to read • Edit Online
You can use Azure PowerShell to configure web traffic routing to specific scalable server pools based on the URL
that is used to access your application. In this tutorial, you create an Azure Application Gateway with three
backend pools using Virtual Machine Scale Sets. Each of the backend pools serves a specific purpose such as,
common data, images, and video. Routing traffic to separate pools ensures that your customers get the
information that they need when they need it.
To enable traffic routing, you create routing rules assigned to listeners that listen on specific ports to ensure web
traffic arrives at the appropriate servers in the pools.
In this tutorial, you learn how to:
Set up the network
Create listeners, URL path map, and rules
Create scalable backend pools
If you don't have an Azure subscription, create a free account before you begin.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
If you choose to install and use the PowerShell locally, this tutorial requires the Azure PowerShell module version
3.6 or later. To find the version, run Get-Module -ListAvailable AzureRM . If you need to upgrade, see Install Azure
PowerShell module. If you are running PowerShell locally, you also need to run Login-AzureRmAccount to create a
connection with Azure.
Because of the time needed to create resources, it can take up to 90 minutes to complete this tutorial.
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.2.0/24
$vnet = New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
$pip = New-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$subnet=$vnet.Subnets[0]
$pip = Get-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Name myAGPublicIPAddress
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendport = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 80
$defaultPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool
$poolSettings = New-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings `
-Port 80 `
-Protocol Http `
-CookieBasedAffinity Enabled `
-RequestTimeout 120
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultlistener `
-BackendAddressPool $defaultPool `
-BackendHttpSettings $poolSettings
$sku = New-AzureRmApplicationGatewaySku `
-Name Standard_Medium `
-Tier Standard `
-Capacity 2
$appgw = New-AzureRmApplicationGateway `
-Name myAppGateway `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-BackendAddressPools $defaultPool `
-BackendHttpSettingsCollection $poolSettings `
-FrontendIpConfigurations $fipconfig `
-GatewayIpConfigurations $gipconfig `
-FrontendPorts $frontendport `
-HttpListeners $defaultlistener `
-RequestRoutingRules $frontendRule `
-Sku $sku
It may take up to 30 minutes for the application gateway to be created, wait until the deployment finishes
successfully before moving on to the next section. At this point in the tutorial, you have an application gateway
that is listening for traffic on port 80 and sends that traffic to a default pool of servers.
Add image and video backend pools and port
Add backend pools named imagesBackendPool and videoBackendPool to your application gatewayAdd-
AzureRmApplicationGatewayBackendAddressPool. Add the frontend port for the pools using Add-
AzureRmApplicationGatewayFrontendPort. Submit the changes to the application gateway using Set-
AzureRmApplicationGateway.
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
Add-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name imagesBackendPool
Add-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name videoBackendPool
Add-AzureRmApplicationGatewayFrontendPort `
-ApplicationGateway $appgw `
-Name bport `
-Port 8080
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$backendPort = Get-AzureRmApplicationGatewayFrontendPort `
-ApplicationGateway $appgw `
-Name bport
$fipconfig = Get-AzureRmApplicationGatewayFrontendIPConfig `
-ApplicationGateway $appgw
Add-AzureRmApplicationGatewayHttpListener `
-ApplicationGateway $appgw `
-Name backendListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $backendPort
$poolSettings = Get-AzureRmApplicationGatewayBackendHttpSettings `
-ApplicationGateway $appgw `
-Name myPoolSettings
$imagePool = Get-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name imagesBackendPool
$videoPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name videoBackendPool
$defaultPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name appGatewayBackendPool
$imagePathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name imagePathRule `
-Paths "/images/*" `
-BackendAddressPool $imagePool `
-BackendHttpSettings $poolSettings
$videoPathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name videoPathRule `
-Paths "/video/*" `
-BackendAddressPool $videoPool `
-BackendHttpSettings $poolSettings
Add-AzureRmApplicationGatewayUrlPathMapConfig `
-ApplicationGateway $appgw `
-Name urlpathmap `
-PathRules $imagePathRule, $videoPathRule `
-DefaultBackendAddressPool $defaultPool `
-DefaultBackendHttpSettings $poolSettings
$backendlistener = Get-AzureRmApplicationGatewayHttpListener `
-ApplicationGateway $appgw `
-Name backendListener
$urlPathMap = Get-AzureRmApplicationGatewayUrlPathMapConfig `
-ApplicationGateway $appgw `
-Name urlpathmap
Add-AzureRmApplicationGatewayRequestRoutingRule `
-ApplicationGateway $appgw `
-Name rule2 `
-RuleType PathBasedRouting `
-HttpListener $backendlistener `
-UrlPathMap $urlPathMap
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$backendPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool `
-ApplicationGateway $appgw
$imagesPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name imagesBackendPool `
-ApplicationGateway $appgw
$videoPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name videoBackendPool `
-ApplicationGateway $appgw
$ipConfig = New-AzureRmVmssIpConfig `
-Name myVmssIPConfig$i `
-SubnetId $vnet.Subnets[1].Id `
-SubnetId $vnet.Subnets[1].Id `
-ApplicationGatewayBackendAddressPoolsId $poolId
$vmssConfig = New-AzureRmVmssConfig `
-Location eastus `
-SkuCapacity 2 `
-SkuName Standard_DS2 `
-UpgradePolicyMode Automatic
Set-AzureRmVmssStorageProfile $vmssConfig `
-ImageReferencePublisher MicrosoftWindowsServer `
-ImageReferenceOffer WindowsServer `
-ImageReferenceSku 2016-Datacenter `
-ImageReferenceVersion latest
-OsDiskCreateOption FromImage
Set-AzureRmVmssOsProfile $vmssConfig `
-AdminUsername azureuser `
-AdminPassword "Azure123456!" `
-ComputerNamePrefix myvmss$i
Add-AzureRmVmssNetworkInterfaceConfiguration `
-VirtualMachineScaleSet $vmssConfig `
-Name myVmssNetConfig$i `
-Primary $true `
-IPConfiguration $ipConfig
New-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss$i `
-VirtualMachineScaleSet $vmssConfig
}
Install IIS
Each scale set contains two virtual machine instances on which you install IIS, which runs a sample page to test
whether the application gateway is working.
Update-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss$i `
-VirtualMachineScaleSet $vmss
}
Change the URL to http://<ip-address>:8080/images/test.htm, substituting your IP address for <ip-address>, and
you should see something like the following example:
Change the URL to http://<ip-address>:8080/video/test.htm, substituting your IP address for <ip-address>, and
you should see something like the following example:
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using
Remove-AzureRmResourceGroup.
Next steps
In this tutorial, you learned how to:
Set up the network
Create listeners, URL path map, and rules
Create scalable backend pools
Redirect web traffic based on the URL
Create and configure an application gateway to host
multiple web sites using the Azure portal
7/13/2018 • 5 minutes to read • Edit Online
You can use the Azure portal to configure the hosting of multiple web sites when you create an application
gateway. In this tutorial, you define backend address pools using virtual machines. You then configure listeners and
rules based on domains that you own to make sure web traffic arrives at the appropriate servers in the pools. This
tutorial assumes that you own multiple domains and uses examples of www.contoso.com and www.fabrikam.com.
In this article, you learn how to:
Create an application gateway
Create virtual machines for backend servers
Create backend pools with the backend servers
Create backend listeners
Create routing rules
Create a CNAME record in your domain
If you don't have an Azure subscription, create a free account before you begin.
Log in to Azure
Log in to the Azure portal at http://portal.azure.com
3. Create the second virtual machine and install IIS using the steps that you just finished. Enter the names of
fabrikamVM for the name and for the value of VMName in Set-AzureRmVMExtension.
2. Copy the DNS address and use it as the value for a new CNAME record in your domain.
Next steps
In this article, you learned how to:
Create an application gateway
Create virtual machines for backend servers
Create backend pools with the backend servers
Create backend listeners
Create routing rules
Create a CNAME record in your domain
Create an application gateway that hosts multiple
web sites using Azure PowerShell
7/13/2018 • 6 minutes to read • Edit Online
You can use Azure Powershell to configure the hosting of multiple web sites when you create an application
gateway. In this tutorial, you define backend address pools using virtual machines scale sets. You then configure
listeners and rules based on domains that you own to make sure web traffic arrives at the appropriate servers in
the pools. This tutorial assumes that you own multiple domains and uses examples of www.contoso.com and
www.fabrikam.com.
In this tutorial, you learn how to:
Set up the network
Create an application gateway
Create backend listeners
Create routing rules
Create virtual machine scale sets with the backend pools
Create a CNAME record in your domain
If you don't have an Azure subscription, create a free account before you begin.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
If you choose to install and use the PowerShell locally, this tutorial requires the Azure PowerShell module version
3.6 or later. To find the version, run Get-Module -ListAvailable AzureRM . If you need to upgrade, see Install Azure
PowerShell module. If you are running PowerShell locally, you also need to run Login-AzureRmAccount to create a
connection with Azure.
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.2.0/24
$vnet = New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
$pip = New-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic
$subnet=$vnet.Subnets[0]
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendport = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 80
$contosoPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name contosoPool
$fabrikamPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name fabrikamPool
$poolSettings = New-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings `
-Port 80 `
-Protocol Http `
-CookieBasedAffinity Enabled `
-RequestTimeout 120
$fabrikamlistener = New-AzureRmApplicationGatewayHttpListener `
-Name fabrikamListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendport `
-HostName "www.fabrikam.com"
$contosoRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name contosoRule `
-RuleType Basic `
-HttpListener $contosoListener `
-BackendAddressPool $contosoPool `
-BackendHttpSettings $poolSettings
$fabrikamRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name fabrikamRule `
-RuleType Basic `
-HttpListener $fabrikamListener `
-BackendAddressPool $fabrikamPool `
-BackendHttpSettings $poolSettings
$sku = New-AzureRmApplicationGatewaySku `
-Name Standard_Medium `
-Tier Standard `
-Capacity 2
$appgw = New-AzureRmApplicationGateway `
-Name myAppGateway `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-BackendAddressPools $contosoPool, $fabrikamPool `
-BackendHttpSettingsCollection $poolSettings `
-FrontendIpConfigurations $fipconfig `
-GatewayIpConfigurations $gipconfig `
-FrontendPorts $frontendport `
-HttpListeners $contosoListener, $fabrikamListener `
-RequestRoutingRules $contosoRule, $fabrikamRule `
-Sku $sku
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$contosoPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name contosoPool `
-ApplicationGateway $appgw
$fabrikamPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name fabrikamPool `
-ApplicationGateway $appgw
$ipConfig = New-AzureRmVmssIpConfig `
-Name myVmssIPConfig$i `
-SubnetId $vnet.Subnets[1].Id `
-ApplicationGatewayBackendAddressPoolsId $poolId
$vmssConfig = New-AzureRmVmssConfig `
-Location eastus `
-SkuCapacity 2 `
-SkuName Standard_DS2 `
-UpgradePolicyMode Automatic
Set-AzureRmVmssStorageProfile $vmssConfig `
-ImageReferencePublisher MicrosoftWindowsServer `
-ImageReferenceOffer WindowsServer `
-ImageReferenceSku 2016-Datacenter `
-ImageReferenceVersion latest
-OsDiskCreateOption FromImage
Set-AzureRmVmssOsProfile $vmssConfig `
-AdminUsername azureuser `
-AdminPassword "Azure123456!" `
-ComputerNamePrefix myvmss$i
Add-AzureRmVmssNetworkInterfaceConfiguration `
-VirtualMachineScaleSet $vmssConfig `
-Name myVmssNetConfig$i `
-Primary $true `
-IPConfiguration $ipConfig
New-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss$i `
-VirtualMachineScaleSet $vmssConfig
}
Install IIS
$publicSettings = @{ "fileUris" = (,"https://raw.githubusercontent.com/Azure/azure-docs-powershell-
samples/master/application-gateway/iis/appgatewayurl.ps1");
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File appgatewayurl.ps1" }
Update-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss$i `
-VirtualMachineScaleSet $vmss
}
Change the address to your other domain and you should see something like the following example:
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using
Remove-AzureRmResourceGroup.
Remove-AzureRmResourceGroup -Name myResourceGroupAG
Next steps
In this tutorial, you learned how to:
Set up the network
Create an application gateway
Create backend listeners
Create routing rules
Create virtual machine scale sets with the backend pools
Create a CNAME record in your domain
Create an application gateway with URL path-based routing rules
Create an application gateway with HTTP to HTTPS
redirection using Azure PowerShell
7/13/2018 • 6 minutes to read • Edit Online
You can use the Azure PowerShell to create an application gateway with a certificate for SSL termination. A routing
rule is used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create
a virtual machine scale set for the backend pool of the application gateway that contains two virtual machine
instances.
In this article, you learn how to:
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate
Add a listener and redirection rule
Create a virtual machine scale set with the default backend pool
If you don't have an Azure subscription, create a free account before you begin.
This tutorial requires the Azure PowerShell module version 3.6 or later. Run Get-Module -ListAvailable AzureRM to
find the version. If you need to upgrade, see Install Azure PowerShell module. To run the commands in this tutorial,
you also need to run Login-AzureRmAccount to create a connection with Azure.
New-SelfSignedCertificate `
-certstorelocation cert:\localmachine\my `
-dnsname www.contoso.com
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\my
Thumbprint Subject
---------- -------
E1E81C23B3AD33F9B4D1717B20AB65DBB91AC630 CN=www.contoso.com
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.2.0/24
$vnet = New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
$pip = New-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$subnet=$vnet.Subnets[0]
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendPort = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 443
$defaultPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool
$poolSettings = New-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings `
-Port 80 `
-Protocol Http `
-CookieBasedAffinity Enabled `
-RequestTimeout 120
$pwd = ConvertTo-SecureString `
-String "Azure123456!" `
-Force `
-AsPlainText
$cert = New-AzureRmApplicationGatewaySslCertificate `
-Name "appgwcert" `
-CertificateFile "c:\appgwcert.pfx" `
-Password $pwd
$defaultListener = New-AzureRmApplicationGatewayHttpListener `
-Name appGatewayHttpListener `
-Protocol Https `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendPort `
-SslCertificate $cert
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultListener `
-BackendAddressPool $defaultPool `
-BackendHttpSettings $poolSettings
$appgw = Get-AzureRmApplicationGateway `
-Name myAppGateway `
-ResourceGroupName myResourceGroupAG
Add-AzureRmApplicationGatewayFrontendPort `
-Name httpPort `
-Port 80 `
-ApplicationGateway $appgw
$fipconfig = Get-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-ApplicationGateway $appgw
$fp = Get-AzureRmApplicationGatewayFrontendPort `
-Name httpPort `
-ApplicationGateway $appgw
Add-AzureRmApplicationGatewayHttpListener `
-Name myListener `
-Protocol Http `
-FrontendPort $fp `
-FrontendIPConfiguration $fipconfig `
-ApplicationGateway $appgw
$myListener = Get-AzureRmApplicationGatewayHttpListener `
-Name myListener `
-ApplicationGateway $appgw
$redirectConfig = Get-AzureRmApplicationGatewayRedirectConfiguration `
-Name httpToHttps `
-ApplicationGateway $appgw
Add-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule2 `
-RuleType Basic `
-HttpListener $myListener `
-RedirectConfiguration $redirectConfig `
-ApplicationGateway $appgw
Set-AzureRmApplicationGateway -ApplicationGateway $appgw
Install IIS
Next steps
In this tutorial, you learned how to:
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate
Add a listener and redirection rule
Create a virtual machine scale set with the default backend pool
Create an application gateway with HTTP to HTTPS
redirection using the Azure CLI
7/16/2018 • 5 minutes to read • Edit Online
You can use the Azure CLI to create an application gateway with a certificate for SSL termination. A routing rule is
used to redirect HTTP traffic to the HTTPS port in your application gateway. In this example, you also create a
virtual machine scale set for the backend pool of the application gateway that contains two virtual machine
instances.
In this article, you learn how to:
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate
Add a listener and redirection rule
Create a virtual machine scale set with the default backend pool
If you don't have an Azure subscription, create a free account before you begin.
If you choose to install and use the CLI locally, this quickstart requires that you are running the Azure CLI version
2.0.4 or later. To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.
openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout privateKey.key -out appgwcert.crt
Enter values that make sense for your certificate. You can accept the default values.
openssl pkcs12 -export -out appgwcert.pfx -inkey privateKey.key -in appgwcert.crt
Enter the password for the certificate. In this example, Azure123456! is being used.
It may take several minutes for the application gateway to be created. After the application gateway is created, you
can see these new features of it:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.
az vmss create \
--name myvmss \
--resource-group myResourceGroupAG \
--image UbuntuLTS \
--admin-username azureuser \
--admin-password Azure123456! \
--instance-count 2 \
--vnet-name myVNet \
--subnet myBackendSubnet \
--vm-sku Standard_DS2 \
--upgrade-policy-mode Automatic \
--app-gateway myAppGateway \
--backend-pool-name appGatewayBackendPool
Install NGINX
To accept the security warning if you used a self-signed certificate, select Details and then Go on to the webpage.
Your secured NGINX site is then displayed as in the following example:
Next steps
In this tutorial, you learned how to:
Create a self-signed certificate
Set up a network
Create an application gateway with the certificate
Add a listener and redirection rule
Create a virtual machine scale set with the default backend pool
Create an application gateway with internal
redirection using Azure PowerShell
7/13/2018 • 6 minutes to read • Edit Online
You can use Azure Powershell to configure web traffic redirection when you create an application gateway. In this
tutorial, you define a backend pool using a virtual machines scale set. You then configure listeners and rules based
on domains that you own to make sure web traffic arrives at the appropriate pool. This tutorial assumes that you
own multiple domains and uses examples of www.contoso.com and www.contoso.org.
In this article, you learn how to:
Set up the network
Create an application gateway
Add listeners and redirection rule
Create a virtual machine scale set with the backend pool
Create a CNAME record in your domain
If you don't have an Azure subscription, create a free account before you begin.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
If you choose to install and use the PowerShell locally, this tutorial requires the Azure PowerShell module version
3.6 or later. To find the version, run Get-Module -ListAvailable AzureRM . If you need to upgrade, see Install Azure
PowerShell module. If you are running PowerShell locally, you also need to run Login-AzureRmAccount to create a
connection with Azure.
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.2.0/24
$vnet = New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
$pip = New-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$subnet=$vnet.Subnets[0]
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendPort = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 80
$contosoComlistener = New-AzureRmApplicationGatewayHttpListener `
-Name contosoComListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendPort `
-HostName "www.contoso.com"
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name contosoComRule `
-RuleType Basic `
-HttpListener $contosoComListener `
-BackendAddressPool $contosoPool `
-BackendHttpSettings $poolSettings
$sku = New-AzureRmApplicationGatewaySku `
-Name Standard_Medium `
-Tier Standard `
-Capacity 2
$appgw = New-AzureRmApplicationGateway `
-Name myAppGateway `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-BackendAddressPools $contosoPool `
-BackendHttpSettingsCollection $poolSettings `
-FrontendIpConfigurations $fipconfig `
-GatewayIpConfigurations $gipconfig `
-FrontendPorts $frontendPort `
-HttpListeners $contosoComListener `
-RequestRoutingRules $frontendRule `
-Sku $sku
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$contosoComlistener = Get-AzureRmApplicationGatewayHttpListener `
-Name contosoComListener `
-ApplicationGateway $appgw
$contosoOrglistener = Get-AzureRmApplicationGatewayHttpListener `
-Name contosoOrgListener `
-ApplicationGateway $appgw
Add-AzureRmApplicationGatewayRedirectConfiguration `
-ApplicationGateway $appgw `
-Name redirectOrgtoCom `
-RedirectType Found `
-TargetListener $contosoComListener `
-IncludePath $true `
-IncludeQueryString $true
Set-AzureRmApplicationGateway -ApplicationGateway $appgw
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$contosoOrglistener = Get-AzureRmApplicationGatewayHttpListener `
-Name contosoOrgListener `
-ApplicationGateway $appgw
$redirectConfig = Get-AzureRmApplicationGatewayRedirectConfiguration `
-Name redirectOrgtoCom `
-ApplicationGateway $appgw
Add-AzureRmApplicationGatewayRequestRoutingRule `
-ApplicationGateway $appgw `
-Name contosoOrgRule `
-RuleType Basic `
-HttpListener $contosoOrgListener `
-RedirectConfiguration $redirectConfig
Set-AzureRmApplicationGateway -ApplicationGateway $appgw
Create a virtual machine scale set
In this example, you create a virtual machine scale set that supports the backend pool that you created. The scale
set that you create is named myvmss and contains two virtual machine instances on which you install IIS. You
assign the scale set to the backend pool when you configure the IP settings.
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$backendPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name contosoPool `
-ApplicationGateway $appgw
$ipConfig = New-AzureRmVmssIpConfig `
-Name myVmssIPConfig `
-SubnetId $vnet.Subnets[1].Id `
-ApplicationGatewayBackendAddressPoolsId $backendPool.Id
$vmssConfig = New-AzureRmVmssConfig `
-Location eastus `
-SkuCapacity 2 `
-SkuName Standard_DS2 `
-UpgradePolicyMode Automatic
Set-AzureRmVmssStorageProfile $vmssConfig `
-ImageReferencePublisher MicrosoftWindowsServer `
-ImageReferenceOffer WindowsServer `
-ImageReferenceSku 2016-Datacenter `
-ImageReferenceVersion latest
-OsDiskCreateOption FromImage
Set-AzureRmVmssOsProfile $vmssConfig `
-AdminUsername azureuser `
-AdminPassword "Azure123456!" `
-ComputerNamePrefix myvmss
Add-AzureRmVmssNetworkInterfaceConfiguration `
-VirtualMachineScaleSet $vmssConfig `
-Name myVmssNetConfig `
-Primary $true `
-IPConfiguration $ipConfig
New-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss `
-VirtualMachineScaleSet $vmssConfig
Install IIS
Change the address to your other domain, for example http://www.contoso.org and you should see that the traffic
has been redirected back to the listener for www.contoso.com.
Next steps
In this article, you learned how to:
Set up the network
Create an application gateway
Add listeners and redirection rule
Create a virtual machine scale set with the backend pools
Create a CNAME record in your domain
Create an application gateway with internal
redirection using the Azure CLI
7/16/2018 • 6 minutes to read • Edit Online
You can use the Azure CLI to configure web traffic redirection when you create an application gateway. In this
tutorial, you define a backend pool using a virtual machines scale set. You then configure listeners and rules based
on domains that you own to make sure web traffic arrives at the appropriate pool. This tutorial assumes that you
own multiple domains and uses examples of www.contoso.com and www.contoso.org.
In this article, you learn how to:
Set up the network
Create an application gateway
Add listeners and redirection rule
Create a virtual machine scale set with the backend pool
Create a CNAME record in your domain
If you don't have an Azure subscription, create a free account before you begin.
If you choose to install and use the CLI locally, this quickstart requires that you are running the Azure CLI version
2.0.4 or later. To find the version, run az --version . If you need to install or upgrade, see Install Azure CLI 2.0.
It may take several minutes for the application gateway to be created. After the application gateway is created, you
can see these new features of it:
appGatewayBackendPool - An application gateway must have at least one backend address pool.
appGatewayBackendHttpSettings - Specifies that port 80 and an HTTP protocol is used for communication.
appGatewayHttpListener - The default listener associated with appGatewayBackendPool.
appGatewayFrontendIP - Assigns myAGPublicIPAddress to appGatewayHttpListener.
rule1 - The default routing rule that is associated with appGatewayHttpListener.
az vmss create \
--name myvmss \
--resource-group myResourceGroupAG \
--image UbuntuLTS \
--admin-username azureuser \
--admin-password Azure123456! \
--instance-count 2 \
--vnet-name myVNet \
--subnet myBackendSubnet \
--vm-sku Standard_DS2 \
--upgrade-policy-mode Automatic \
--app-gateway myAppGateway \
--backend-pool-name appGatewayBackendPool
Install NGINX
Run this command in the shell window:
Change the address to your other domain, for example http://www.contoso.org and you should see that the traffic
has been redirected back to the listener for www.contoso.com.
Next steps
In this tutorial, you learned how to:
Application gateway allows you to have an Azure Web App or other multi-tenant service as a back-end pool
member. In this article, you learn to configure an Azure web app with Application Gateway. The first example
shows you how to configure an existing application gateway to use a web app as a back-end pool member. The
second example shows you how to create a new application gateway with a web app as a back-end pool member.
# Defines a variable for a dotnet get started web app repository location
$gitrepo="https://github.com/Azure-Samples/app-service-web-dotnet-get-started.git"
# Configure GitHub deployment from your GitHub repo and deploy once to web app.
$PropertiesObject = @{
repoUrl = "$gitrepo";
branch = "master";
isManualIntegration = "true";
}
Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName $rg.ResourceGroupName -ResourceType
Microsoft.Web/sites/sourcecontrols -ResourceName $webappname/web -ApiVersion 2015-08-01 -Force
# Create a new listener using the front-end ip configuration and port created earlier
$listener = New-AzureRmApplicationGatewayHttpListener -Name listener01 -Protocol Http -FrontendIPConfiguration
$fipconfig -FrontendPort $fp
Name : publicIP01
ResourceGroupName : ContosoRG
Location : eastus
Id :
/subscriptions/<subscription_id>/resourceGroups/ContosoRG/providers/Microsoft.Network/publicIPAddresses/publicI
P01
Etag : W/"00000d5b-54ed-4907-bae8-99bd5766d0e5"
ResourceGuid : 00000000-0000-0000-0000-000000000000
ProvisioningState : Succeeded
Tags :
PublicIpAllocationMethod : Dynamic
IpAddress : xx.xx.xxx.xx
PublicIpAddressVersion : IPv4
IdleTimeoutInMinutes : 4
IpConfiguration : {
"Id":
"/subscriptions/<subscription_id>/resourceGroups/ContosoRG/providers/Microsoft.Network/applicationGateways/Cont
osoAppGateway/frontendIP
Configurations/frontend1"
}
DnsSettings : {
"Fqdn": "00000000-0000-xxxx-xxxx-xxxxxxxxxxxx.cloudapp.net"
}
Next steps
Learn how to configure redirection by visiting: Configure redirection on Application Gateway with PowerShell.
Create an application gateway with URL path-based
redirection using Azure PowerShell
7/13/2018 • 9 minutes to read • Edit Online
You can use Azure PowerShell to configure URL -based routing rules when you create an application gateway. In
this tutorial, you create backend pools using virtual machine scale sets. You then create URL routing rules that
make sure web traffic is redirected to the appropriate backend pool.
In this tutorial, you learn how to:
Set up the network
Create an application gateway
Add listeners and routing rules
Create virtual machine scale sets for backend pools
The following example shows site traffic coming from both ports 8080 and 8081 and being directed to the same
backend pools:
If you don't have an Azure subscription, create a free account before you begin.
Click the Cloud Shell button on the menu in the upper right
of the Azure portal.
If you choose to install and use the PowerShell locally, this tutorial requires the Azure PowerShell module version
3.6 or later. To find the version, run Get-Module -ListAvailable AzureRM . If you need to upgrade, see Install Azure
PowerShell module. If you are running PowerShell locally, you also need to run Connect-AzureRmAccount to create
a connection with Azure.
$backendSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$agSubnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name myAGSubnet `
-AddressPrefix 10.0.2.0/24
New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-Subnet $backendSubnetConfig, $agSubnetConfig
New-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-Name myAGPublicIPAddress `
-AllocationMethod Dynamic
$subnet=$vnet.Subnets[0]
$pip = Get-AzureRmPublicIpAddress `
-ResourceGroupName myResourceGroupAG `
-Name myAGPublicIPAddress
$gipconfig = New-AzureRmApplicationGatewayIPConfiguration `
-Name myAGIPConfig `
-Subnet $subnet
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig `
-Name myAGFrontendIPConfig `
-PublicIPAddress $pip
$frontendport = New-AzureRmApplicationGatewayFrontendPort `
-Name myFrontendPort `
-Port 80
$defaultPool = New-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool
$poolSettings = New-AzureRmApplicationGatewayBackendHttpSettings `
-Name myPoolSettings `
-Port 80 `
-Protocol Http `
-CookieBasedAffinity Enabled `
-RequestTimeout 120
$defaultlistener = New-AzureRmApplicationGatewayHttpListener `
-Name defaultListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $frontendport
$frontendRule = New-AzureRmApplicationGatewayRequestRoutingRule `
-Name rule1 `
-RuleType Basic `
-HttpListener $defaultlistener `
-BackendAddressPool $defaultPool `
-BackendHttpSettings $poolSettings
Create the application gateway
Now that you created the necessary supporting resources, specify parameters for the application gateway named
myAppGateway using New -AzureRmApplicationGatewaySku, and then create it using New -
AzureRmApplicationGateway.
$sku = New-AzureRmApplicationGatewaySku `
-Name Standard_Medium `
-Tier Standard `
-Capacity 2
New-AzureRmApplicationGateway `
-Name myAppGateway `
-ResourceGroupName myResourceGroupAG `
-Location eastus `
-BackendAddressPools $defaultPool `
-BackendHttpSettingsCollection $poolSettings `
-FrontendIpConfigurations $fipconfig `
-GatewayIpConfigurations $gipconfig `
-FrontendPorts $frontendport `
-HttpListeners $defaultlistener `
-RequestRoutingRules $frontendRule `
-Sku $sku
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
Add-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name imagesBackendPool
Add-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name videoBackendPool
Add-AzureRmApplicationGatewayFrontendPort `
-ApplicationGateway $appgw `
-Name bport `
-Port 8080
Add-AzureRmApplicationGatewayFrontendPort `
-ApplicationGateway $appgw `
-Name rport `
-Port 8081
$backendPort = Get-AzureRmApplicationGatewayFrontendPort `
-ApplicationGateway $appgw `
-Name bport
$redirectPort = Get-AzureRmApplicationGatewayFrontendPort `
-ApplicationGateway $appgw `
-Name rport
$fipconfig = Get-AzureRmApplicationGatewayFrontendIPConfig `
-ApplicationGateway $appgw
Add-AzureRmApplicationGatewayHttpListener `
-ApplicationGateway $appgw `
-Name backendListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $backendPort
Add-AzureRmApplicationGatewayHttpListener `
-ApplicationGateway $appgw `
-Name redirectedListener `
-Protocol Http `
-FrontendIPConfiguration $fipconfig `
-FrontendPort $redirectPort
$poolSettings = Get-AzureRmApplicationGatewayBackendHttpSettings `
-ApplicationGateway $appgw `
-Name myPoolSettings
$imagePool = Get-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name imagesBackendPool
$videoPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name videoBackendPool
$defaultPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name appGatewayBackendPool
$imagePathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name imagePathRule `
-Paths "/images/*" `
-BackendAddressPool $imagePool `
-BackendHttpSettings $poolSettings
$videoPathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name videoPathRule `
-Paths "/video/*" `
-BackendAddressPool $videoPool `
-BackendHttpSettings $poolSettings
Add-AzureRmApplicationGatewayUrlPathMapConfig `
-ApplicationGateway $appgw `
-Name urlpathmap `
-PathRules $imagePathRule, $videoPathRule `
-DefaultBackendAddressPool $defaultPool `
-DefaultBackendHttpSettings $poolSettings
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$backendListener = Get-AzureRmApplicationGatewayHttpListener `
-ApplicationGateway $appgw `
-Name backendListener
$redirectConfig = Add-AzureRmApplicationGatewayRedirectConfiguration `
-ApplicationGateway $appgw `
-Name redirectConfig `
-RedirectType Found `
-TargetListener $backendListener `
-IncludePath $true `
-IncludeQueryString $true
$poolSettings = Get-AzureRmApplicationGatewayBackendHttpSettings `
-ApplicationGateway $appgw `
-Name myPoolSettings
$defaultPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-ApplicationGateway $appgw `
-Name appGatewayBackendPool
$redirectConfig = Get-AzureRmApplicationGatewayRedirectConfiguration `
-ApplicationGateway $appgw `
-Name redirectConfig
$redirectPathRule = New-AzureRmApplicationGatewayPathRuleConfig `
-Name redirectPathRule `
-Paths "/images/*" `
-RedirectConfiguration $redirectConfig
Add-AzureRmApplicationGatewayUrlPathMapConfig `
-ApplicationGateway $appgw `
-Name redirectpathmap `
-PathRules $redirectPathRule `
-DefaultBackendAddressPool $defaultPool `
-DefaultBackendHttpSettings $poolSettings
$backendlistener = Get-AzureRmApplicationGatewayHttpListener `
-ApplicationGateway $appgw `
-Name backendListener
$redirectlistener = Get-AzureRmApplicationGatewayHttpListener `
-ApplicationGateway $appgw `
-Name redirectedListener
$urlPathMap = Get-AzureRmApplicationGatewayUrlPathMapConfig `
-ApplicationGateway $appgw `
-Name urlpathmap
$redirectPathMap = Get-AzureRmApplicationGatewayUrlPathMapConfig `
-ApplicationGateway $appgw `
-Name redirectpathmap
Add-AzureRmApplicationGatewayRequestRoutingRule `
-ApplicationGateway $appgw `
-Name defaultRule `
-RuleType PathBasedRouting `
-HttpListener $backendlistener `
-UrlPathMap $urlPathMap
Add-AzureRmApplicationGatewayRequestRoutingRule `
-ApplicationGateway $appgw `
-Name redirectedRule `
-RuleType PathBasedRouting `
-HttpListener $redirectlistener `
-UrlPathMap $redirectPathMap
$vnet = Get-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupAG `
-Name myVNet
$appgw = Get-AzureRmApplicationGateway `
-ResourceGroupName myResourceGroupAG `
-Name myAppGateway
$backendPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name appGatewayBackendPool `
-ApplicationGateway $appgw
$imagesPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name imagesBackendPool `
-ApplicationGateway $appgw
$videoPool = Get-AzureRmApplicationGatewayBackendAddressPool `
-Name videoBackendPool `
-ApplicationGateway $appgw
$ipConfig = New-AzureRmVmssIpConfig `
-Name myVmssIPConfig$i `
-SubnetId $vnet.Subnets[1].Id `
-ApplicationGatewayBackendAddressPoolsId $poolId
$vmssConfig = New-AzureRmVmssConfig `
-Location eastus `
-SkuCapacity 2 `
-SkuName Standard_DS2 `
-UpgradePolicyMode Automatic
Set-AzureRmVmssStorageProfile $vmssConfig `
-ImageReferencePublisher MicrosoftWindowsServer `
-ImageReferenceOffer WindowsServer `
-ImageReferenceSku 2016-Datacenter `
-ImageReferenceVersion latest
-OsDiskCreateOption FromImage
Set-AzureRmVmssOsProfile $vmssConfig `
-AdminUsername azureuser `
-AdminPassword "Azure123456!" `
-ComputerNamePrefix myvmss$i
Add-AzureRmVmssNetworkInterfaceConfiguration `
-VirtualMachineScaleSet $vmssConfig `
-Name myVmssNetConfig$i `
-Primary $true `
-IPConfiguration $ipConfig
New-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss$i `
-VirtualMachineScaleSet $vmssConfig
}
Install IIS
$publicSettings = @{ "fileUris" = (,"https://raw.githubusercontent.com/Azure/azure-docs-powershell-
samples/master/application-gateway/iis/appgatewayurl.ps1");
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File appgatewayurl.ps1" }
Update-AzureRmVmss `
-ResourceGroupName myResourceGroupAG `
-Name myvmss$i `
-VirtualMachineScaleSet $vmss
}
Change the URL to http://<ip-address>:8080/video/test.htm, substituting your IP address for <ip-address>, and
you should see something like the following example:
Change the URL to http://<ip-address>:8080/video/test.htm, substituting your IP address for <ip-address>, and
you should see something like the following example:
Now, change the URL to http://<ip-address>:8081/images/test.htm, substituting your IP address for <ip-
address>, and you should see traffic redirected back to the images backend pool at http://<ip-
address>:8080/images.
Clean up resources
When no longer needed, remove the resource group, application gateway, and all related resources using
Remove-AzureRmResourceGroup.
Next steps
In this tutorial, you learned how to:
Set up the network
Create an application gateway
Add listeners and routing rules
Create virtual machine scale sets for backend pools
Learn more about what you can do with application gateway
Create a zone redundant Azure application gateway -
private preview
5/8/2018 • 8 minutes to read • Edit Online
The application gateway zone redundant platform is a new SKU that offers many enhancements over the existing
application gateway SKU including:
Zone resiliency - An application gateway deployment can now span multiple Availability Zones, removing the
need to provision and pin separate application gateway instances in each zone with a traffic manager. You can
choose a single zone or multiple zones where application gateway instances are deployed, thus ensuring zone
failure resiliency. The backend pool for applications can be similarly distributed across availability zones.
Performance enhancements
Static VIP - The application gateway VIP now supports the static VIP type exclusively. This ensures that the
VIP associated with application gateway does not change after a restart.
Key vault integration for customer SSL certificates
Faster deployment and update time
NOTE
The zone redundant application gateway is currently in private preview. This preview is provided without a service level
agreement and is not recommended for production workloads. Certain features may not be supported or may have
constrained capabilities. See the Supplemental Terms of Use for Microsoft Azure Previews for details.
Supported regions
Zone redundant application gateways are currently supported in the East US 2 region. More regions will be added
soon.
Topologies
With the current release, you no longer need to create zone pinned application gateways to get zonal redundancy.
The same application gateway deployment can now span multiple zones.
At least three instances are required to ensure that they are spread across all three zones. Application gateway
distributes instances across zones as more instances are added.
Previous zone redundant topologies looked like the following diagram:
The new zone redundant topology looks like this diagram:
Deployment
Prerequisites
Currently zone redundant capability is only available in private preview. You must email
[email protected] to be whitelisted. Once you receive a confirmation, you can proceed to the next steps.
Include the following information in your email for whitelisting:
Subscription ID
Region name
Approximate count of application gateways required
Resource Manager template deployment
1. Make sure the subscription you use is whitelisted as previously mentioned.
2. After you receive a confirmation, sign in to the Azure account and select the appropriate subscription if more
than one subscription is present. Make sure you select the subscription that was whitelisted.
Login-AzureRmAccount
4. Download the templates from GitHub and note the folder where you save them.
5. Create a new deployment in the resource group you created. Modify the template and parameters file
appropriately before you deploy.
The following diagram shows where you can retrieve the tenant ID on the Azure portal:
PowerShell deployment
1. Ensure that the subscription used is whitelisted as previously mentioned in the prerequisites.
2. Download and install the private PowerShell MSI from GitHub.
3. Download the private PowerShell zip file from the location mentioned in preview registration confirmation
email. Unzip the file to your drive and note the location.
4. Once the preview is enabled, load the preview modules first before signing on to your account:
5. Sign in to the Azure account and select the desired subscription if more than one subscription is present.
Ensure you select the appropriate subscription that was whitelisted.
6. Run the following commands to establish common constants that include names for most of the entities
being created.
Modify the entries as required for your naming preference.
$location = "eastus2"
$version = "300"
$rgname = "RG_A_$version"
$appgwName = "AGW_A_$version"
$vaultName = "KVA$version"
$userAssignedIdentityName = "UI_A_$version"
$certificateName = "KVCA$version"
$nsgName = "NSG_A_$version"
$vnetName = "VN_A_$version"
$gwSubnetName = "SN_A_$version"
$gipconfigname = "GC_A_$version"
$publicIpName = "PIP_A_$version"
$fipconfig01Name = "FC_A_$version"
$poolName = "BP_A_$version"
$frontendPort01Name = "FP1_A_$version"
$frontendPort02Name = "FP2_A_$version"
$poolSetting01Name = "BS_A_$version"
$listener01Name = "HL1_A_$version"
$listener02Name = "HL2_A_$version"
$rule01Name = "RR1_A_$version"
$rule02Name = "RR2_A_$version"
$AddressPrefix = "111.111.222.0"
11. Assign access policy to the Key Vault using the User Assigned Identity. This allows the application gateway
instances to access the Key Vault secret:
12. Create the Network Security Group (NSG ) to allow access to the application gateway subnet on ports where
new listeners are created.
For example, for HTTP/HTTPS on default ports the NSG would allow inbound access to 80, 443 and 65200-
65535 for management operations.
$listeners = @($listener02)
$fipconfigs = @($fipconfig01)
$sslCerts = @($sslCert01)
Diagnostics logs (not metrics) Performance and request/response logs don’t appear currently
Portal/CLI/SDK No support for portal, CLI, or SDK. The portal must not be
used to issue updates to preview gateways.
Update via template fails occasionally This is due to race condition with KeyVault access policy
User supplied certificates and Dynamic VIPs These are not supported in the new model. Use Key Vault for
storing certificates and static VIPs.
Same subnet for old and preview version of application A subnet with an existing application gateway (old model)
gateway cannot be used for the private preview version.
HTTP/2, FIPS mode, WebSocket, Azure Web Apps as backend Currently unsupported
Next steps
Learn about other application gateway features:
What is Azure Application Gateway?
Create a custom probe for Application Gateway by
using the portal
5/1/2018 • 3 minutes to read • Edit Online
In this article, you add a custom probe to an existing application gateway through the Azure portal. Custom
probes are useful for applications that have a specific health check page or for applications that do not provide a
successful response on the default web application.
4. On the Add health probe blade, fill out the required information for the probe, and when complete click
OK.
Path / or another path The remainder of the full url for the
custom probe. A valid path starts
with '/'. For the default path of
http://contoso.com just use '/'
IMPORTANT
The host name is not the same as server name. This value is the name of the virtual host running on the application
server. The probe is sent to http://(host name):(port from httpsetting)/urlPath
Next steps
To learn how to configure SSL Offloading with Azure Application Gateway, see Configure SSL Offload
Create a custom probe for Azure Application
Gateway (classic) by using PowerShell
5/1/2018 • 4 minutes to read • Edit Online
In this article, you add a custom probe to an existing application gateway with PowerShell. Custom probes are
useful for applications that have a specific health check page or for applications that do not provide a successful
response on the default web application.
IMPORTANT
Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. This
article covers using the Classic deployment model. Microsoft recommends that most new deployments use the Resource
Manager model. Learn how to perform these steps using the Resource Manager model.
NOTE
You need an Azure account to complete these steps. If you don't have an Azure account, you can sign up for a free trial.
To validate that the gateway was created, you can use the Get-AzureApplicationGateway cmdlet.
Get-AzureApplicationGateway AppGwTest
NOTE
The default value for InstanceCount is 2, with a maximum value of 10. The default value for GatewaySize is Medium. You can
choose between Small, Medium, and Large.
VirtualIPs and DnsName are shown as blank because the gateway has not started yet. These values are created
once the gateway is in the running state.
Configure an application gateway by using XML
In the following example, you use an XML file to configure all application gateway settings and commit them to
the application gateway resource.
Copy the following text to Notepad.
<ApplicationGatewayConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/windowsazure">
<FrontendIPConfigurations>
<FrontendIPConfiguration>
<Name>fip1</Name>
<Type>Private</Type>
</FrontendIPConfiguration>
</FrontendIPConfigurations>
<FrontendPorts>
<FrontendPort>
<Name>port1</Name>
<Port>80</Port>
</FrontendPort>
</FrontendPorts>
<Probes>
<Probe>
<Name>Probe01</Name>
<Protocol>Http</Protocol>
<Host>contoso.com</Host>
<Path>/path/custompath.htm</Path>
<Interval>15</Interval>
<Timeout>15</Timeout>
<UnhealthyThreshold>5</UnhealthyThreshold>
</Probe>
</Probes>
<BackendAddressPools>
<BackendAddressPool>
<Name>pool1</Name>
<IPAddresses>
<IPAddress>1.1.1.1</IPAddress>
<IPAddress>2.2.2.2</IPAddress>
</IPAddresses>
</BackendAddressPool>
</BackendAddressPools>
<BackendHttpSettingsList>
<BackendHttpSettings>
<Name>setting1</Name>
<Port>80</Port>
<Protocol>Http</Protocol>
<CookieBasedAffinity>Enabled</CookieBasedAffinity>
<RequestTimeout>120</RequestTimeout>
<Probe>Probe01</Probe>
</BackendHttpSettings>
</BackendHttpSettingsList>
<HttpListeners>
<HttpListener>
<Name>listener1</Name>
<FrontendIP>fip1</FrontendIP>
<FrontendPort>port1</FrontendPort>
<Protocol>Http</Protocol>
</HttpListener>
</HttpListeners>
<HttpLoadBalancingRules>
<HttpLoadBalancingRule>
<Name>lbrule1</Name>
<Type>basic</Type>
<BackendHttpSettings>setting1</BackendHttpSettings>
<Listener>listener1</Listener>
<BackendAddressPool>pool1</BackendAddressPool>
</HttpLoadBalancingRule>
</HttpLoadBalancingRules>
</ApplicationGatewayConfiguration>
Edit the values between the parentheses for the configuration items. Save the file with extension .xml.
The following example shows how to use a configuration file to set up the application gateway to load balance
HTTP traffic on public port 80 and send network traffic to back-end port 80 between two IP addresses by using a
custom probe.
IMPORTANT
The protocol item Http or Https is case-sensitive.
PARAMETER DESCRIPTION
Host and Path Complete URL path that is invoked by the application
gateway to determine the health of the instance. For example,
if you have a website http://contoso.com/, then the custom
probe can be configured for
"http://contoso.com/path/custompath.htm" for probe checks
to have a successful HTTP response.
UnhealthyThreshold The number of failed HTTP responses needed to flag the back-
end instance as unhealthy.
The probe name is referenced in the <BackendHttpSettings> configuration to assign which back-end pool uses
custom probe settings.
2. Open the XML file in a text editor. Add a <probe> section after <frontendport> .
<Probes>
<Probe>
<Name>Probe01</Name>
<Protocol>Http</Protocol>
<Host>contoso.com</Host>
<Path>/path/custompath.htm</Path>
<Interval>15</Interval>
<Timeout>15</Timeout>
<UnhealthyThreshold>5</UnhealthyThreshold>
</Probe>
</Probes>
In the backendHttpSettings section of the XML, add the probe name as shown in the following example:
<BackendHttpSettings>
<Name>setting1</Name>
<Port>80</Port>
<Protocol>Http</Protocol>
<CookieBasedAffinity>Enabled</CookieBasedAffinity>
<RequestTimeout>120</RequestTimeout>
<Probe>Probe01</Probe>
</BackendHttpSettings>
Next steps
If you want to configure Secure Sockets Layer (SSL ) offload, see Configure an application gateway for SSL
offload.
If you want to configure an application gateway to use with an internal load balancer, see Create an application
gateway with an internal load balancer (ILB ).
Create a custom probe for Azure Application
Gateway by using PowerShell for Azure Resource
Manager
5/1/2018 • 6 minutes to read • Edit Online
In this article, you add a custom probe to an existing application gateway with PowerShell. Custom probes are
useful for applications that have a specific health check page or for applications that do not provide a successful
response on the default web application.
NOTE
Azure has two different deployment models for creating and working with resources: Resource Manager and classic. This
article covers using the Resource Manager deployment model, which Microsoft recommends for most new deployments
instead of the classic deployment model.
NOTE
You need an Azure account to complete these steps. If you don't have an Azure account, you can sign up for a free trial.
Connect-AzureRmAccount
Get-AzureRmSubscription
4. Create a resource group. You can skip this step if you have an existing resource group.
Azure Resource Manager requires that all resource groups specify a location. This location is used as the default
location for resources in that resource group. Make sure that all commands to create an application gateway use
the same resource group.
In the preceding example, we created a resource group called appgw-RG in location West US.
Create a virtual network and a subnet
The following example creates a virtual network and a subnet for the application gateway. Application gateway
requires its own subnet for use. For this reason, the subnet created for the application gateway should be smaller
than the address space of the VNET to allow for other subnets to be created and used.
# Assign the address range 10.0.0.0/24 to a subnet variable to be used to create a virtual network.
$subnet = New-AzureRmVirtualNetworkSubnetConfig -Name subnet01 -AddressPrefix 10.0.0.0/24
# Create a virtual network named appgwvnet in resource group appgw-rg for the West US region using the prefix
10.0.0.0/16 with subnet 10.0.0.0/24.
$vnet = New-AzureRmVirtualNetwork -Name appgwvnet -ResourceGroupName appgw-rg -Location 'West US' -
AddressPrefix 10.0.0.0/16 -Subnet $subnet
# Assign a subnet variable for the next steps, which create an application gateway.
$subnet = $vnet.Subnets[0]
COMPONENT DESCRIPTION
Health probe A custom probe used to monitor the health of the backend
pool members
Frontend port The port that the application gateway listens for traffic on
#Creates a back-end IP address pool named pool01 with IP addresses 134.170.185.46, 134.170.188.221,
134.170.185.50.
$pool = New-AzureRmApplicationGatewayBackendAddressPool -Name pool01 -BackendIPAddresses 134.170.185.46,
134.170.188.221, 134.170.185.50
# Creates the backend http settings to be used. This component references the $probe created in the previous
command.
$poolSetting = New-AzureRmApplicationGatewayBackendHttpSettings -Name poolsetting01 -Port 80 -Protocol Http -
CookieBasedAffinity Disabled -Probe $probe -RequestTimeout 80
# Creates a frontend port for the application gateway to listen on port 80 that will be used by the listener.
$fp = New-AzureRmApplicationGatewayFrontendPort -Name frontendport01 -Port 80
# Creates a frontend IP configuration. This associates the $publicip variable defined previously with the
front-end IP that will be used by the listener.
$fipconfig = New-AzureRmApplicationGatewayFrontendIPConfig -Name fipconfig01 -PublicIPAddress $publicip
# Creates the listener. The listener is a combination of protocol and the frontend IP configuration
$fipconfig and frontend port $fp created in previous steps.
$listener = New-AzureRmApplicationGatewayHttpListener -Name listener01 -Protocol Http -
FrontendIPConfiguration $fipconfig -FrontendPort $fp
# Creates the rule that routes traffic to the backend pools. In this example we create a basic rule that
uses the previous defined http settings and backend address pool. It also associates the listener to the
rule
$rule = New-AzureRmApplicationGatewayRequestRoutingRule -Name rule01 -RuleType Basic -BackendHttpSettings
$poolSetting -HttpListener $listener -BackendAddressPool $pool
# Sets the SKU of the application gateway, in this example we create a small standard application gateway
with 2 instances.
$sku = New-AzureRmApplicationGatewaySku -Name Standard_Small -Tier Standard -Capacity 2
# The final step creates the application gateway with all the previously defined components.
$appgw = New-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName appgw-rg -Location 'West US' -
BackendAddressPools $pool -Probes $probe -BackendHttpSettingsCollection $poolSetting -
FrontendIpConfigurations $fipconfig -GatewayIpConfigurations $gipconfig -FrontendPorts $fp -HttpListeners
$listener -RequestRoutingRules $rule -Sku $sku
# Load the application gateway resource into a PowerShell variable by using Get-AzureRmApplicationGateway.
$getgw = Get-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName appgw-rg
# Load the application gateway resource into a PowerShell variable by using Get-AzureRmApplicationGateway.
$getgw = Get-AzureRmApplicationGateway -Name appgwtest -ResourceGroupName appgw-rg
# Set the backend HTTP settings to remove the reference to the probe. The backend http settings now use the
default probe
$getgw = Set-AzureRmApplicationGatewayBackendHttpSettings -ApplicationGateway $getgw -Name
$getgw.BackendHttpSettingsCollection.name -Port 80 -Protocol http -CookieBasedAffinity Disabled
Name : publicIP01
ResourceGroupName : appgw-RG
Location : westus
Id : /subscriptions/<subscription_id>/resourceGroups/appgw-
RG/providers/Microsoft.Network/publicIPAddresses/publicIP01
Etag : W/"00000d5b-54ed-4907-bae8-99bd5766d0e5"
ResourceGuid : 00000000-0000-0000-0000-000000000000
ProvisioningState : Succeeded
Tags :
PublicIpAllocationMethod : Dynamic
IpAddress : xx.xx.xxx.xx
PublicIpAddressVersion : IPv4
IdleTimeoutInMinutes : 4
IpConfiguration : {
"Id": "/subscriptions/<subscription_id>/resourceGroups/appgw-
RG/providers/Microsoft.Network/applicationGateways/appgwtest/frontendIP
Configurations/frontend1"
}
DnsSettings : {
"Fqdn": "00000000-0000-xxxx-xxxx-xxxxxxxxxxxx.cloudapp.net"
}
Next steps
Learn to configure SSL offloading by visiting: Configure SSL Offload
Troubleshooting bad gateway errors in Application
Gateway
5/21/2018 • 6 minutes to read • Edit Online
Learn how to troubleshoot bad gateway (502) errors received when using application gateway.
Overview
After configuring an application gateway, one of the errors that users may encounter is "Server Error: 502 - Web
server received an invalid response while acting as a gateway or proxy server". This error may happen due to the
following main reasons:
NSG, UDR or Custom DNS is blocking access to backend pool members.
Back-end VMs or instances of virtual machine scale set are not responding to the default health probe.
Invalid or improper configuration of custom health probes.
Azure Application Gateway's back-end pool is not configured or empty.
None of the VMs or instances in virtual machine scale set are healthy.
Request time-out or connectivity issues with user requests.
Check presence of custom DNS in the VNet. DNS can be checked by looking at details of the VNet properties
in the output.
Get-AzureRmVirtualNetwork -Name vnetName -ResourceGroupName rgName
DhcpOptions : {
"DnsServers": [
"x.x.x.x"
]
}
If present, ensure that the DNS server is able to resolve backend pool member's FQDN correctly.
Solution
Ensure that a default site is configured and is listening at 127.0.0.1.
If BackendHttpSetting specifies a port other than 80, the default site should be configured to listen at that port.
The call to http://127.0.0.1:port should return an HTTP result code of 200. This should be returned within the 30
sec time-out period.
Ensure that port configured is open and that there are no firewall rules or Azure Network Security Groups,
which block incoming or outgoing traffic on the port configured.
If Azure classic VMs or Cloud Service is used with FQDN or Public IP, ensure that the corresponding endpoint
is opened.
If the VM is configured via Azure Resource Manager and is outside the VNet where Application Gateway is
deployed, Network Security Group must be configured to allow access on the desired port.
Name Name of the probe. This name is used to refer to the probe in
back-end HTTP settings.
Protocol Protocol used to send the probe. The probe uses the protocol
defined in the back-end HTTP settings
Host Host name to send the probe. Applicable only when multi-site
is configured on Application Gateway. This is different from
VM host name.
Path Relative path of the probe. The valid path starts from '/'. The
probe is sent to <protocol>://<host>:<port><path>
Unhealthy threshold Probe retry count. The back-end server is marked down after
the consecutive probe failure count reaches the unhealthy
threshold.
Solution
Validate that the Custom Health Probe is configured correctly as the preceding table. In addition to the preceding
troubleshooting steps, also ensure the following:
Ensure that the probe is correctly specified as per the guide.
If Application Gateway is configured for a single site, by default the Host name should be specified as
'127.0.0.1', unless otherwise configured in custom probe.
Ensure that a call to http://<host>:<port><path> returns an HTTP result code of 200.
Ensure that Interval, Time-out and UnhealtyThreshold are within the acceptable ranges.
If using an HTTPS probe, make sure that the backend server doesn't require SNI by configuring a fallback
certificate on the backend server itself.
Request time-out
Cause
When a user request is received, Application Gateway applies the configured rules to the request and routes it to a
back-end pool instance. It waits for a configurable interval of time for a response from the back-end instance. By
default, this interval is 30 seconds. If Application Gateway does not receive a response from back-end application
in this interval, user request would see a 502 error.
Solution
Application Gateway allows users to configure this setting via BackendHttpSetting, which can be then applied to
different pools. Different back-end pools can have different BackendHttpSetting and hence different request time-
out configured.
The output from the preceding cmdlet should contain non-empty back-end address pool. Following is an example
where two pools are returned which are configured with FQDN or IP addresses for backend VMs. The
provisioning state of the BackendAddressPool must be 'Succeeded'.
BackendAddressPoolsText:
[{
"BackendAddresses": [{
"ipAddress": "10.0.0.10",
"ipAddress": "10.0.0.11"
}],
"BackendIpConfigurations": [],
"ProvisioningState": "Succeeded",
"Name": "Pool01",
"Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
"Id": "/subscriptions/<subscription id>/resourceGroups/<resource group
name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
"BackendAddresses": [{
"Fqdn": "xyx.cloudapp.net",
"Fqdn": "abc.cloudapp.net"
}],
"BackendIpConfigurations": [],
"ProvisioningState": "Succeeded",
"Name": "Pool02",
"Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
"Id": "/subscriptions/<subscription id>/resourceGroups/<resource group
name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]
Next steps
If the preceding steps do not resolve the issue, open a support ticket.
Back-end health, diagnostic logs, and metrics for
Application Gateway
6/21/2018 • 12 minutes to read • Edit Online
By using Azure Application Gateway, you can monitor resources in the following ways:
Back-end health: Application Gateway provides the capability to monitor the health of the servers in the
back-end pools through the Azure portal and through PowerShell. You can also find the health of the back-
end pools through the performance diagnostic logs.
Logs: Logs allow for performance, access, and other data to be saved or consumed from a resource for
monitoring purposes.
Metrics: Application Gateway currently has seven metrics to view performance counters.
Back-end health
Application Gateway provides the capability to monitor the health of individual members of the back-end pools
through the portal, PowerShell, and the command-line interface (CLI). You can also find an aggregated health
summary of back-end pools through the performance diagnostic logs.
The back-end health report reflects the output of the Application Gateway health probe to the back-end instances.
When probing is successful and the back end can receive traffic, it's considered healthy. Otherwise, it's considered
unhealthy.
IMPORTANT
If there is a network security group (NSG) on an Application Gateway subnet, open port ranges 65503-65534 on the
Application Gateway subnet for inbound traffic. This port range is required for Azure infrastructure communication. They are
protected (locked down) by Azure certificates. Without proper certificates, external entities, including the customers of those
gateways, will not be able to initiate any changes on those endpoints.
NOTE
If you see a back-end health status of Unknown, ensure that access to the back end is not blocked by an NSG rule, a user-
defined route (UDR), or a custom DNS in the virtual network.
View back-end health through PowerShell
The following PowerShell code shows how to view back-end health by using the
Get-AzureRmApplicationGatewayBackendHealth cmdlet:
Results
The following snippet shows an example of the response:
{
"BackendAddressPool": {
"Id": "/subscriptions/00000000-0000-0000-
000000000000/resourceGroups/ContosoRG/providers/Microsoft.Network/applicationGateways/applicationGateway1/back
endAddressPools/appGatewayBackendPool"
},
"BackendHttpSettingsCollection": [
{
"BackendHttpSettings": {
"Id": "/00000000-0000-0000-
000000000000/resourceGroups/ContosoRG/providers/Microsoft.Network/applicationGateways/applicationGateway1/back
endHttpSettingsCollection/appGatewayBackendHttpSettings"
},
"Servers": [
{
"Address": "hostname.westus.cloudapp.azure.com",
"Health": "Healthy"
},
{
"Address": "hostname.westus.cloudapp.azure.com",
"Health": "Healthy"
}
]
}
]
}
Diagnostic logs
You can use different types of logs in Azure to manage and troubleshoot application gateways. You can access
some of these logs through the portal. All logs can be extracted from Azure Blob storage and viewed in different
tools, such as Log Analytics, Excel, and Power BI. You can learn more about the different types of logs from the
following list:
Activity log: You can use Azure activity logs (formerly known as operational logs and audit logs) to view all
operations that are submitted to your Azure subscription, and their status. Activity log entries are collected by
default, and you can view them in the Azure portal.
Access log: You can use this log to view Application Gateway access patterns and analyze important
information, including the caller's IP, requested URL, response latency, return code, and bytes in and out. An
access log is collected every 300 seconds. This log contains one record per instance of Application Gateway.
The Application Gateway instance can be identified by the instanceId property.
Performance log: You can use this log to view how Application Gateway instances are performing. This log
captures performance information for each instance, including total requests served, throughput in bytes, total
requests served, failed request count, and healthy and unhealthy back-end instance count. A performance log is
collected every 60 seconds.
Firewall log: You can use this log to view the requests that are logged through either detection or prevention
mode of an application gateway that is configured with the web application firewall.
NOTE
Logs are available only for resources deployed in the Azure Resource Manager deployment model. You cannot use logs for
resources in the classic deployment model. For a better understanding of the two models, see the Understanding Resource
Manager deployment and classic deployment article.
TIP
Activity logs do not require a separate storage account. The use of storage for access and performance logging incurs
service charges.
3. The Diagnostics settings blade provides the settings for the diagnostic logs. In this example, Log
Analytics stores the logs. Click Configure under Log Analytics to configure your workspace. You can also
use event hubs and a storage account to save the diagnostic logs.
4. Choose an existing Log Analytics workspace or create a new one. This example uses an existing one.
5. Confirm the settings and click Save.
Activity log
Azure generates the activity log by default. The logs are preserved for 90 days in the Azure event logs store. Learn
more about these logs by reading the View events and activity log article.
Access log
The access log is generated only if you've enabled it on each Application Gateway instance, as detailed in the
preceding steps. The data is stored in the storage account that you specified when you enabled the logging. Each
access of Application Gateway is logged in JSON format, as shown in the following example:
VALUE DESCRIPTION
Performance log
The performance log is generated only if you have enabled it on each Application Gateway instance, as detailed in
the preceding steps. The data is stored in the storage account that you specified when you enabled the logging.
The performance log data is generated in 1-minute intervals. The following data is logged:
VALUE DESCRIPTION
throughput Average throughput since the last log, measured in bytes per
second.
{
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGAT
EWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
NOTE
Latency is calculated from the time when the first byte of the HTTP request is received to the time when the last byte of the
HTTP response is sent. It's the sum of the Application Gateway processing time plus the network cost to the back end, plus
the time that the back end takes to process the request.
Firewall log
The firewall log is generated only if you have enabled it for each application gateway, as detailed in the preceding
steps. This log also requires that the web application firewall is configured on an application gateway. The data is
stored in the storage account that you specified when you enabled the logging. The following data is logged:
VALUE DESCRIPTION
ruleSetVersion Rule set version used. Available values are 2.2.9 and 3.0.
action Action taken on the request. Available values are Blocked and
Allowed.
site Site for which the log was generated. Currently, only Global is
listed because rules are global.
VALUE DESCRIPTION
details.line Line number in the configuration file that triggered the event.
{
"resourceId":
"/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGAT
EWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"time": "2017-03-20T15:52:09.1494499Z",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIp": "104.210.252.3",
"clientPort": "4835",
"requestUri": "/?a=%3Cscript%3Ealert(%22Hello%22);%3C/script%3E",
"ruleSetType": "OWASP",
"ruleSetVersion": "3.0",
"ruleId": "941320",
"message": "Possible XSS Attack Detected - HTML Tag Handler",
"action": "Blocked",
"site": "Global",
"details": {
"message": "Warning. Pattern match \"
<(a|abbr|acronym|address|applet|area|audioscope|b|base|basefront|bdo|bgsound|big|blackface|blink|blockquote|bo
dy|bq|br|button|caption|center|cite|code|col|colgroup|comment|dd|del|dfn|dir|div|dl|dt|em|embed|fieldset|fn|fo
nt|form|frame|frameset|h1|head|h ...\" at ARGS:a.",
"data": "Matched Data: <script> found within ARGS:a: <script>alert(\\x22hello\\x22);</script>",
"file": "rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf",
"line": "865"
}
}
}
TIP
If you are familiar with Visual Studio and basic concepts of changing values for constants and variables in C#, you can use
the log converter tools available from GitHub.
Metrics
Metrics are a feature for certain Azure resources where you can view performance counters in the portal. For
Application Gateway, the following metrics are available:
Current Connections
Failed Requests
Healthy Host Count
You can filter on a per backend pool basis to show healthy/unhealthy hosts in a specific backend pool.
Response Status
The response status code distribution can be further categorized to show responses in 2xx, 3xx, 4xx, and 5xx
categories.
Throughput
Total Requests
Unhealthy Host count
You can filter on a per backend pool basis to show healthy/unhealthy hosts in a specific backend pool.
Browse to an application gateway, under Monitoring click Metrics. To view the available values, select the
METRIC drop-down list.
In the following image, you see an example with three metrics displayed for the last 30 minutes:
To see a current list of metrics, see Supported metrics with Azure Monitor.
Alert rules
You can start alert rules based on metrics for a resource. For example, an alert can call a webhook or email an
administrator if the throughput of the application gateway is above, below, or at a threshold for a specified period.
The following example walks you through creating an alert rule that sends an email to an administrator after
throughput breaches a threshold:
1. Click Add metric alert to open the Add rule blade. You can also reach this blade from the metrics blade.
2. On the Add rule blade, fill out the name, condition, and notify sections, and click OK.
In the Condition selector, select one of the four values: Greater than, Greater than or equal, Less
than, or Less than or equal to.
In the Period selector, select a period from five minutes to six hours.
If you select Email owners, contributors, and readers, the email can be dynamic based on the
users who have access to that resource. Otherwise, you can provide a comma-separated list of users
in the Additional administrator email(s) box.
If the threshold is breached, an email that's similar to the one in the following image arrives:
A list of alerts appears after you create a metric alert. It provides an overview of all the alert rules.
Next steps
Visualize counter and event logs by using Log Analytics.
Visualize your Azure activity log with Power BI blog post.
View and analyze Azure activity logs in Power BI and more blog post.
List of web application firewall CRS rule groups and
rules offered
4/16/2018 • 12 minutes to read • Edit Online
Application Gateway web application firewall (WAF ) protects web applications from common vulnerabilities and
exploits. This is done through rules that are defined based on the OWASP core rule sets 2.2.9 or 3.0. These rules
can be disabled on a rule by rule basis. This article contains the current rules and rulesets offered.
The following tables are the Rule groups and rules that are available when using Application Gateway with web
application firewall. Each table represents the rules found in a rule group for a specific CRS version.
OWASP_3.0
REQUEST -911-METHOD-ENFORCEMENT
RULEID DESCRIPTION
RULEID DESCRIPTION
RULEID DESCRIPTION
920201 Range = Too many fields for pdf request (35 or more)
RULEID DESCRIPTION
921160 HTTP Header Injection Attack via payload (CR/LF and header-
name detected)
RULEID DESCRIPTION
RULEID DESCRIPTION
RULEID DESCRIPTION
RULEID DESCRIPTION
RULEID DESCRIPTION
RULEID DESCRIPTION
942270 Looking for basic sql injection. Common attack string for
mysql oracle and others.
RULEID DESCRIPTION
OWASP_2.2.9
crs_20_protocol_violations
RULEID DESCRIPTION
crs_21_protocol_anomalies
RULEID DESCRIPTION
crs_23_request_limits
RULEID DESCRIPTION
crs_30_http_policy
RULEID DESCRIPTION
crs_35_bad_robots
RULEID DESCRIPTION
crs_40_generic_attacks
RULEID DESCRIPTION
crs_41_sql_injection_attacks
RULEID DESCRIPTION
981276 Looking for basic sql injection. Common attack string for
mysql oracle and others.
crs_41_xss_attacks
RULEID DESCRIPTION
crs_42_tight_security
RULEID DESCRIPTION
crs_45_trojans
RULEID DESCRIPTION
The infrastructure for your application is typically made up of many components – maybe a virtual machine,
storage account, and virtual network, or a web app, database, database server, and third-party services. You don't
see these components as separate entities, instead you see them as related and interdependent parts of a single
entity. You want to deploy, manage, and monitor them as a group. Azure Resource Manager enables you to work
with the resources in your solution as a group. You can deploy, update, or delete all the resources for your solution
in a single, coordinated operation. You use a template for deployment and that template can work for different
environments such as testing, staging, and production. Resource Manager provides security, auditing, and tagging
features to help you manage your resources after deployment.
Terminology
If you're new to Azure Resource Manager, there are some terms you might not be familiar with.
resource - A manageable item that is available through Azure. Some common resources are a virtual machine,
storage account, web app, database, and virtual network, but there are many more.
resource group - A container that holds related resources for an Azure solution. The resource group can
include all the resources for the solution, or only those resources that you want to manage as a group. You
decide how you want to allocate resources to resource groups based on what makes the most sense for your
organization. See Resource groups.
resource provider - A service that supplies the resources you can deploy and manage through Resource
Manager. Each resource provider offers operations for working with the resources that are deployed. Some
common resource providers are Microsoft.Compute, which supplies the virtual machine resource,
Microsoft.Storage, which supplies the storage account resource, and Microsoft.Web, which supplies resources
related to web apps. See Resource providers.
Resource Manager template - A JavaScript Object Notation (JSON ) file that defines one or more resources
to deploy to a resource group. It also defines the dependencies between the deployed resources. The template
can be used to deploy the resources consistently and repeatedly. See Template deployment.
declarative syntax - Syntax that lets you state "Here is what I intend to create" without having to write the
sequence of programming commands to create it. The Resource Manager template is an example of declarative
syntax. In the file, you define the properties for the infrastructure to deploy to Azure.
Guidance
The following suggestions help you take full advantage of Resource Manager when working with your solutions.
1. Define and deploy your infrastructure through the declarative syntax in Resource Manager templates, rather
than through imperative commands.
2. Define all deployment and configuration steps in the template. You should have no manual steps for setting up
your solution.
3. Run imperative commands to manage your resources, such as to start or stop an app or machine.
4. Arrange resources with the same lifecycle in a resource group. Use tags for all other organizing of resources.
For guidance on how enterprises can use Resource Manager to effectively manage subscriptions, see Azure
enterprise scaffold - prescriptive subscription governance.
For recommendations on creating Resource Manager templates that you can use across global Azure, Azure
sovereign clouds, and Azure Stack, see Develop Azure Resource Manager templates for cloud consistency.
Resource groups
There are some important factors to consider when defining your resource group:
1. All the resources in your group should share the same lifecycle. You deploy, update, and delete them together. If
one resource, such as a database server, needs to exist on a different deployment cycle it should be in another
resource group.
2. Each resource can only exist in one resource group.
3. You can add or remove a resource to a resource group at any time.
4. You can move a resource from one resource group to another group. For more information, see Move
resources to new resource group or subscription.
5. A resource group can contain resources that reside in different regions.
6. A resource group can be used to scope access control for administrative actions.
7. A resource can interact with resources in other resource groups. This interaction is common when the two
resources are related but don't share the same lifecycle (for example, web apps connecting to a database).
When creating a resource group, you need to provide a location for that resource group. You may be wondering,
"Why does a resource group need a location? And, if the resources can have different locations than the resource
group, why does the resource group location matter at all?" The resource group stores metadata about the
resources. Therefore, when you specify a location for the resource group, you're specifying where that metadata is
stored. For compliance reasons, you may need to ensure that your data is stored in a particular region.
Resource providers
Each resource provider offers a set of resources and operations for working with an Azure service. For example, if
you want to store keys and secrets, you work with the Microsoft.KeyVault resource provider. This resource
provider offers a resource type called vaults for creating the key vault.
The name of a resource type is in the format: {resource-provider}/{resource-type}. For example, the key vault
type is Microsoft.KeyVault/vaults.
Before getting started with deploying your resources, you should gain an understanding of the available resource
providers. Knowing the names of resource providers and resources helps you define resources you want to deploy
to Azure. Also, you need to know the valid locations and API versions for each resource type. For more
information, see Resource providers and types.
Template deployment
With Resource Manager, you can create a template (in JSON format) that defines the infrastructure and
configuration of your Azure solution. By using a template, you can repeatedly deploy your solution throughout its
lifecycle and have confidence your resources are deployed in a consistent state. When you create a solution from
the portal, the solution automatically includes a deployment template. You don't have to create your template from
scratch because you can start with the template for your solution and customize it to meet your specific needs. You
can retrieve a template for an existing resource group by either exporting the current state of the resource group,
or viewing the template used for a particular deployment. Viewing the exported template is a helpful way to learn
about the template syntax.
To learn about the format of the template and how you construct it, see Create your first Azure Resource Manager
template. To view the JSON syntax for resources types, see Define resources in Azure Resource Manager
templates.
Resource Manager processes the template like any other request (see the image for Consistent management
layer). It parses the template and converts its syntax into REST API operations for the appropriate resource
providers. For example, when Resource Manager receives a template with the following resource definition:
"resources": [
{
"apiVersion": "2016-01-01",
"type": "Microsoft.Storage/storageAccounts",
"name": "mystorageaccount",
"location": "westus",
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"properties": {
}
}
]
It converts the definition to the following REST API operation, which is sent to the Microsoft.Storage resource
provider:
PUT
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Micro
soft.Storage/storageAccounts/mystorageaccount?api-version=2016-01-01
REQUEST BODY
{
"location": "westus",
"properties": {
}
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage"
}
How you define templates and resource groups is entirely up to you and how you want to manage your solution.
For example, you can deploy your three tier application through a single template to a single resource group.
But, you don't have to define your entire infrastructure in a single template. Often, it makes sense to divide your
deployment requirements into a set of targeted, purpose-specific templates. You can easily reuse these templates
for different solutions. To deploy a particular solution, you create a master template that links all the required
templates. The following image shows how to deploy a three tier solution through a parent template that includes
three nested templates.
If you envision your tiers having separate lifecycles, you can deploy your three tiers to separate resource groups.
Notice the resources can still be linked to resources in other resource groups.
For information about nested templates, see Using linked templates with Azure Resource Manager.
Azure Resource Manager analyzes dependencies to ensure resources are created in the correct order. If one
resource relies on a value from another resource (such as a virtual machine needing a storage account for disks),
you set a dependency. For more information, see Defining dependencies in Azure Resource Manager templates.
You can also use the template for updates to the infrastructure. For example, you can add a resource to your
solution and add configuration rules for the resources that are already deployed. If the template specifies creating a
resource but that resource already exists, Azure Resource Manager performs an update instead of creating a new
asset. Azure Resource Manager updates the existing asset to the same state as it would be as new.
Resource Manager provides extensions for scenarios when you need additional operations such as installing
particular software that isn't included in the setup. If you're already using a configuration management service, like
DSC, Chef or Puppet, you can continue working with that service by using extensions. For information about
virtual machine extensions, see About virtual machine extensions and features.
Finally, the template becomes part of the source code for your app. You can check it in to your source code
repository and update it as your app evolves. You can edit the template through Visual Studio.
After defining your template, you're ready to deploy the resources to Azure. For the commands to deploy the
resources, see:
Deploy resources with Resource Manager templates and Azure PowerShell
Deploy resources with Resource Manager templates and Azure CLI
Deploy resources with Resource Manager templates and Azure portal
Deploy resources with Resource Manager templates and Resource Manager REST API
Tags
Resource Manager provides a tagging feature that enables you to categorize resources according to your
requirements for managing or billing. Use tags when you have a complex collection of resource groups and
resources, and need to visualize those assets in the way that makes the most sense to you. For example, you could
tag resources that serve a similar role in your organization or belong to the same department. Without tags, users
in your organization can create multiple resources that may be difficult to later identify and manage. For example,
you may wish to delete all the resources for a particular project. If those resources aren't tagged for the project,
you have to manually find them. Tagging can be an important way for you to reduce unnecessary costs in your
subscription.
Resources do not need to reside in the same resource group to share a tag. You can create your own tag taxonomy
to ensure that all users in your organization use common tags rather than users inadvertently applying slightly
different tags (such as "dept" instead of "department").
The following example shows a tag applied to a virtual machine.
"resources": [
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2015-06-15",
"name": "SimpleWindowsVM",
"location": "[resourceGroup().location]",
"tags": {
"costCenter": "Finance"
},
...
}
]
To retrieve all the resources with a tag value, use the following PowerShell cmdlet:
You can also view tagged resources through the Azure portal.
The usage report for your subscription includes tag names and values, which enables you to break out costs by
tags. For more information about tags, see Using tags to organize your Azure resources.
Access control
Resource Manager enables you to control who has access to specific actions for your organization. It natively
integrates role-based access control (RBAC ) into the management platform and applies that access control to all
services in your resource group.
There are two main concepts to understand when working with role-based access control:
Role definitions - describe a set of permissions and can be used in many assignments.
Role assignments - associate a definition with an identity (user or group) for a particular scope (subscription,
resource group, or resource). The assignment is inherited by lower scopes.
You can add users to pre-defined platform and resource-specific roles. For example, you can take advantage of the
pre-defined role called Reader that permits users to view resources but not change them. You add users in your
organization that need this type of access to the Reader role and apply the role to the subscription, resource group,
or resource.
Azure provides the following four platform roles:
1. Owner - can manage everything, including access
2. Contributor - can manage everything except access
3. Reader - can view everything, but can't make changes
4. User Access Administrator - can manage user access to Azure resources
Azure also provides several resource-specific roles. Some common ones are:
1. Virtual Machine Contributor - can manage virtual machines but not grant access to them, and can't manage the
virtual network or storage account to which they're connected
2. Network Contributor - can manage all network resources, but not grant access to them
3. Storage Account Contributor - Can manage storage accounts, but not grant access to them
4. SQL Server Contributor - Can manage SQL servers and databases, but not their security-related policies
5. Website Contributor - Can manage websites, but not the web plans to which they're connected
For the full list of roles and permitted actions, see RBAC: Built in Roles. For more information about role-based
access control, see Azure Role-based Access Control.
In some cases, you want to run code or script that accesses resources, but you don't want to run it under a user’s
credentials. Instead, you want to create an identity called a service principal for the application and assign the
appropriate role for the service principal. Resource Manager enables you to create credentials for the application
and programmatically authenticate the application. To learn about creating service principals, see one of following
topics:
Use Azure PowerShell to create a service principal to access resources
Use Azure CLI to create a service principal to access resources
Use portal to create Azure Active Directory application and service principal that can access resources
You can also explicitly lock critical resources to prevent users from deleting or modifying them. For more
information, see Lock resources with Azure Resource Manager.
Activity logs
Resource Manager logs all operations that create, modify, or delete a resource. You can use the activity logs to find
an error when troubleshooting or to monitor how a user in your organization modified a resource. You can filter
the logs by many different values including which user initiated the operation. For information about working with
the activity logs, see View activity logs to manage Azure resources.
Customized policies
Resource Manager enables you to create customized policies for managing your resources. The types of policies
you create can include diverse scenarios. You can enforce a naming convention on resources, limit which types and
instances of resources can be deployed, or limit which regions can host a type of resource. You can require a tag
value on resources to organize billing by departments. You create policies to help reduce costs and maintain
consistency in your subscription.
You define policies with JSON and then apply those policies either across your subscription or within a resource
group. Policies are different than role-based access control because they're applied to resource types.
The following example shows a policy that ensures tag consistency by specifying that all resources include a
costCenter tag.
{
"if": {
"not" : {
"field" : "tags",
"containsKey" : "costCenter"
}
},
"then" : {
"effect" : "deny"
}
}
There are many more types of policies you can create. For more information, see What is Azure Policy?.
SDKs
Azure SDKs are available for multiple languages and platforms. Each of these language implementations is
available through its ecosystem package manager and GitHub.
Here are the Open Source SDK repositories.
Azure SDK for .NET
Azure Management Libraries for Java
Azure SDK for Node.js
Azure SDK for PHP
Azure SDK for Python
Azure SDK for Ruby
For information about using these languages with your resources, see:
Azure for .NET developers
Azure for Java developers
Azure for Node.js developers
Azure for Python developers
NOTE
If the SDK doesn't provide the required functionality, you can also call to the Azure REST API directly.
Next steps
For a simple introduction to working with templates, see Export an Azure Resource Manager template from
existing resources.
For a more thorough walkthrough of creating a template, see Create your first Azure Resource Manager
template.
To understand the functions you can use in a template, see Template functions
For information about using Visual Studio with Resource Manager, see Creating and deploying Azure resource
groups through Visual Studio.
For information on migration of resources from Classic to ARM, see Migrate from Classic to Azure Resource
Manager
Here's a video demonstration of this overview:
Understand the structure and syntax of Azure
Resource Manager Templates
7/17/2018 • 6 minutes to read • Edit Online
This article describes the structure of an Azure Resource Manager template. It presents the different sections of a
template and the properties that are available in those sections. The template consists of JSON and expressions
that you can use to construct values for your deployment. For a step-by-step tutorial on creating a template, see
Create your first Azure Resource Manager template.
Template format
In its simplest structure, a template has the following elements:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "",
"parameters": { },
"variables": { },
"functions": { },
"resources": [ ],
"outputs": { }
}
Each element has properties you can set. The following example shows the full syntax for a template:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "",
"parameters": {
"<parameter-name>" : {
"type" : "<type-of-parameter-value>",
"defaultValue": "<default-value-of-parameter>",
"allowedValues": [ "<array-of-allowed-values>" ],
"minValue": <minimum-value-for-int>,
"maxValue": <maximum-value-for-int>,
"minLength": <minimum-length-for-string-or-array>,
"maxLength": <maximum-length-for-string-or-array-parameters>,
"metadata": {
"description": "<description-of-the parameter>"
}
}
},
"variables": {
"<variable-name>": "<variable-value>",
"<variable-object-name>": {
<variable-complex-type-value>
},
"<variable-object-name>": {
"copy": [
{
"name": "<name-of-array-property>",
"count": <number-of-iterations>,
"input": {
<properties-to-repeat>
}
}
]
},
"copy": [
{
"name": "<variable-array-name>",
"count": <number-of-iterations>,
"input": {
<properties-to-repeat>
}
}
]
},
"functions": [
{
"namespace": "<namespace-for-your-function>",
"members": {
"<function-name>": {
"parameters": [
{
"name": "<parameter-name>",
"type": "<type-of-parameter-value>"
}
],
"output": {
"type": "<type-of-output-value>",
"value": "<function-expression>"
}
}
}
}
}
],
"resources": [
{
"condition": "<boolean-value-whether-to-deploy>",
"apiVersion": "<api-version-of-resource>",
"type": "<resource-provider-namespace/resource-type-name>",
"name": "<name-of-the-resource>",
"location": "<location-of-resource>",
"tags": {
"<tag-name1>": "<tag-value1>",
"<tag-name2>": "<tag-value2>"
},
"comments": "<your-reference-notes>",
"copy": {
"name": "<name-of-copy-loop>",
"count": "<number-of-iterations>",
"mode": "<serial-or-parallel>",
"batchSize": "<number-to-deploy-serially>"
},
"dependsOn": [
"<array-of-related-resource-names>"
],
"properties": {
"<settings-for-the-resource>",
"copy": [
{
"name": ,
"count": ,
"input": {}
}
]
},
"resources": [
"<array-of-child-resources>"
]
}
],
"outputs": {
"<outputName>" : {
"type" : "<type-of-output-value>",
"value": "<output-value-expression>"
}
}
}
Syntax
The basic syntax of the template is JSON. However, expressions and functions extend the JSON values available
within the template. Expressions are written within JSON string literals whose first and last characters are the
brackets: [ and ] , respectively. The value of the expression is evaluated when the template is deployed. While
written as a string literal, the result of evaluating the expression can be of a different JSON type, such as an array
or integer, depending on the actual expression. To have a literal string start with a bracket [ , but not have it
interpreted as an expression, add an extra bracket to start the string with [[ .
Typically, you use expressions with functions to perform operations for configuring the deployment. Just like in
JavaScript, function calls are formatted as functionName(arg1,arg2,arg3) . You reference properties by using the dot
and [index] operators.
The following example shows how to use several functions when constructing a value:
"variables": {
"storageName": "[concat(toLower(parameters('storageNamePrefix')), uniqueString(resourceGroup().id))]"
}
For the full list of template functions, see Azure Resource Manager template functions.
Parameters
In the parameters section of the template, you specify which values you can input when deploying the resources.
These parameter values enable you to customize the deployment by providing values that are tailored for a
particular environment (such as dev, test, and production). You don't have to provide parameters in your template,
but without parameters your template would always deploy the same resources with the same names, locations,
and properties.
The following example shows a simple parameter definition:
"parameters": {
"siteNamePrefix": {
"type": "string",
"metadata": {
"description": "The name prefix of the web app that you wish to create."
}
},
},
For information about defining parameters, see Parameters section of Azure Resource Manager templates.
Variables
In the variables section, you construct values that can be used throughout your template. You don't need to define
variables, but they often simplify your template by reducing complex expressions.
The following example shows a simple variable definition:
"variables": {
"webSiteName": "[concat(parameters('siteNamePrefix'), uniqueString(resourceGroup().id))]",
},
For information about defining variables, see Variables section of Azure Resource Manager templates.
Functions
Within your template, you can create your own functions. These functions are available for use in your template.
Typically, you define complicated expression that you don't want to repeat throughout your template. You create
the user-defined functions from expressions and functions that are supported in templates.
When defining a user function, there are some restrictions:
The function can't access variables.
The function can't access template parameters. That is, the parameters function is restricted to function
parameters.
The function can't call other user-defined functions.
The function can't use the reference function.
Parameters for the function can't have default values.
Your functions require a namespace value to avoid naming conflicts with template functions. The following
example shows a function that returns a storage account name:
"functions": [
{
"namespace": "contoso",
"members": {
"uniqueName": {
"parameters": [
{
"name": "namePrefix",
"type": "string"
}
],
"output": {
"type": "string",
"value": "[concat(toLower(parameters('namePrefix')), uniqueString(resourceGroup().id))]"
}
}
}
}
],
"resources": [
{
"name": "[contoso.uniqueName(parameters('storageNamePrefix'))]",
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2016-01-01",
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"location": "South Central US",
"tags": {},
"properties": {}
}
]
Resources
In the resources section, you define the resources that are deployed or updated. This section can get complicated
because you must understand the types you're deploying to provide the right values.
"resources": [
{
"apiVersion": "2016-08-01",
"name": "[variables('webSiteName')]",
"type": "Microsoft.Web/sites",
"location": "[resourceGroup().location]",
"properties": {
"serverFarmId": "/subscriptions/<subscription-id>/resourcegroups/<resource-group-
name>/providers/Microsoft.Web/serverFarms/<plan-name>"
}
}
],
For more information, see Resources section of Azure Resource Manager templates.
Outputs
In the Outputs section, you specify values that are returned from deployment. For example, you could return the
URI to access a deployed resource.
"outputs": {
"newHostName": {
"type": "string",
"value": "[reference(variables('webSiteName')).defaultHostName]"
}
}
For more information, see Outputs section of Azure Resource Manager templates.
Template limits
Limit the size of your template to 1 MB, and each parameter file to 64 KB. The 1-MB limit applies to the final state
of the template after it has been expanded with iterative resource definitions, and values for variables and
parameters.
You're also limited to:
256 parameters
256 variables
800 resources (including copy count)
64 output values
24,576 characters in a template expression
You can exceed some template limits by using a nested template. For more information, see Using linked templates
when deploying Azure resources. To reduce the number of parameters, variables, or outputs, you can combine
several values into an object. For more information, see Objects as parameters.
Next steps
To view complete templates for many different types of solutions, see the Azure Quickstart Templates.
For details about the functions you can use from within a template, see Azure Resource Manager Template
Functions.
To combine multiple templates during deployment, see Using linked templates with Azure Resource Manager.
For recommendations on creating Resource Manager templates that you can use across global Azure, Azure
sovereign clouds, and Azure Stack, see Develop Azure Resource Manager templates for cloud consistency.
Frequently asked questions for Application Gateway
6/21/2018 • 13 minutes to read • Edit Online
General
Q. What is Application Gateway?
Azure Application Gateway is an Application Delivery Controller (ADC ) as a service, offering various layer 7 load
balancing capabilities for your applications. It offers highly available and scalable service, which is fully managed by
Azure.
Q. What features does Application Gateway support?
Application Gateway supports SSL offloading and end to end SSL, Web Application Firewall, cookie-based session
affinity, url path-based routing, multi site hosting, and others. For a full list of supported features, visit Introduction
to Application Gateway
Q. What is the difference between Application Gateway and Azure Load Balancer?
Application Gateway is a layer 7 load balancer, which means it works with web traffic only
(HTTP/HTTPS/WebSocket). It supports capabilities such as SSL termination, cookie-based session affinity, and
round robin for load balancing traffic. Load Balancer, load balances traffic at layer 4 (TCP/UDP ).
Q. What protocols does Application Gateway support?
Application Gateway supports HTTP, HTTPS, HTTP/2, and WebSocket.
Q. How does Application Gateway support HTTP/2?
HTTP/2 protocol support is available to clients connecting to Application Gateway listeners only. The
communication to backend server pools is over HTTP/1.1.
By default, HTTP/2 support is disabled. The following Azure PowerShell code snippet example shows how you can
enable it:
Configuration
Q. Is Application Gateway always deployed in a virtual network?
Yes, Application Gateway is always deployed in a virtual network subnet. This subnet can only contain Application
Gateways.
Q. Can Application Gateway talk to instances outside its virtual network?
Application Gateway can talk to instances outside of the virtual network that it is in as long as there is IP
connectivity. If you plan to use internal IPs as backend pool members, then it requires VNET Peering or VPN
Gateway.
Q. Can I deploy anything else in the Application Gateway subnet?
No, but you can deploy other application gateways in the subnet.
Q. Are Network Security Groups supported on the Application Gateway subnet?
Network Security Groups are supported on the Application Gateway subnet with the following restrictions:
Exceptions must be put in for incoming traffic on ports 65503-65534. This port-range is required for Azure
infrastructure communication. They are protected (locked down) by Azure certificates. Without proper
certificates, external entities, including the customers of those gateways, will not be able to initiate any
changes on those endpoints.
Outbound internet connectivity can't be blocked.
Traffic from the AzureLoadBalancer tag must be allowed.
Q. What are the limits on Application Gateway? Can I increase these limits?
Visit Application Gateway Limits to view the limits.
Q. Can I use Application Gateway for both external and internal traffic simultaneously?
Yes, Application Gateway supports having one internal IP and one external IP per Application Gateway.
Q. Is VNet peering supported?
Yes, VNet peering is supported and is beneficial for load balancing traffic in other virtual networks.
Q. Can I talk to on-premises servers when they are connected by ExpressRoute or VPN tunnels?
Yes, as long as traffic is allowed.
Q. Can I have one backend pool serving many applications on different ports?
Micro service architecture is supported. You would need multiple http settings configured to probe on different
ports.
Q. Do custom probes support wildcards/regex on response data?
Custom probes do not support wildcard or regex on response data.
Q. How are rules processed?
Rules are processed in the order they are configured. It is recommended that multi-site rules are configured before
basic rules to reduce the chance that traffic is routed to the inappropriate backend as the basic rule would match
traffic based on port prior to the multi-site rule being evaluated.
Q. What does the Host field for custom probes signify?
Host field specifies the name to send the probe to. Applicable only when multi-site is configured on Application
Gateway, otherwise use '127.0.0.1'. This value is different from VM host name and is in format
<protocol>://<host>:<port><path>.
Q. Can I whitelist Application Gateway access to a few source IPs?
This scenario can be done using NSGs on Application Gateway subnet. The following restrictions should be put on
the subnet in the listed order of priority:
Allow incoming traffic from source IP/IP range.
Allow incoming requests from all sources to ports 65503-65534 for backend health communication. This
port range is required for Azure infrastructure communication. They are protected (locked down) by Azure
certificates. Without proper certificates, external entities, including the customers of those gateways, will not
be able to initiate any changes on those endpoints.
Allow incoming Azure Load Balancer probes (AzureLoadBalancer tag) and inbound virtual network traffic
(VirtualNetwork tag) on the NSG.
Block all other incoming traffic with a Deny all rule.
Allow outbound traffic to the internet for all destinations.
Q. Can the same port be used for both public and private facing listeners?
No, this is not supported.
Performance
Q. How does Application Gateway support high availability and scalability?
Application Gateway supports high availability scenarios when you have two or more instances deployed. Azure
distributes these instances across update and fault domains to ensure that all instances do not fail at the same time.
Application Gateway supports scalability by adding multiple instances of the same gateway to share the load.
Q. How do I achieve DR scenario across data centers with Application Gateway?
Customers can use Traffic Manager to distribute traffic across multiple Application Gateways in different
datacenters.
Q. Is auto scaling supported?
No, but Application Gateway has a throughput metric that can be used to alert you when a threshold is reached.
Manually adding instances or changing size does not restart the gateway and does not impact existing traffic.
Q. Does manual scale up/down cause downtime?
There is no downtime, instances are distributed across upgrade domains and fault domains.
Q. Does application gateway support connection draining?
Yes. You can configure connection draining to change members within a backend pool without disruption. This will
allow existing connections to continue to be sent to their previous destination until either that connection is closed
or a configurable timeout expires. Note that connection draining only waits for current in-flight connections to
complete. Application Gateway is not aware of application session state.
Q. What are application gateway sizes?
Application Gateway is currently offered in three sizes: Small, Medium, and Large. Small instance sizes are
intended for development and testing scenarios.
You can create up to 50 application gateways per subscription, and each application gateway can have up to 10
instances each. Each application gateway can consist of 20 http listeners. For a complete list of application gateway
limits, see Application Gateway service limits.
The following table shows an average performance throughput for each application gateway instance with SSL
offload enabled:
AVERAGE BACK-END PAGE
RESPONSE SIZE SMALL MEDIUM LARGE
NOTE
These values are approximate values for an application gateway throughput. The actual throughput depends on various
environment details, such as average page size, location of back-end instances, and processing time to serve a page. For exact
performance numbers, you should run your own tests. These values are only provided for capacity planning guidance.
SSL Configuration
Q. What certificates are supported on Application Gateway?
Self signed certs, CA certs, and wild-card certs are supported. EV certs are not supported.
Q. What are the current cipher suites supported by Application Gateway?
The following are the current cipher suites supported by application gateway. Visit: Configure SSL policy versions
and cipher suites on Application Gateway to learn how to customize SSL options.
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
Q. Does Application Gateway also support re-encryption of traffic to the backend?
Yes, Application Gateway supports SSL offload, and end to end SSL, which re-encrypts the traffic to the backend.
Q. Can I configure SSL policy to control SSL Protocol versions?
Yes, you can configure Application Gateway to deny TLS1.0, TLS1.1, and TLS1.2. SSL 2.0 and 3.0 are already
disabled by default and are not configurable.
Q. Can I configure cipher suites and policy order?
Yes, configuration of cipher suites is supported. When defining a custom policy, at least one of the following cipher
suites must be enabled. Application gateway uses SHA256 to for backend management.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
Q. How many SSL certificates are supported?
Up to 20 SSL certificates are supported.
Q. How many authentication certificates for backend re-encryption are supported?
Up to 10 authentication certificates are supported with a default of 5.
Q. Does Application Gateway integrate with Azure Key Vault natively?
No, it is not integrated with Azure Key Vault.
Next Steps
To learn more about Application Gateway visit What is Azure Application Gateway?