Intro

My notes on this service

Documentation

• What is Azure Application Gateway?

• Tutorial: Configure an application gateway with TLS termination using the Azure portal

Tips and Tidbits

• Azure Application Gateway is a REGIONAL web traffic load balancer that enables you to manage traffic to your web applications.

• Application Gateway routes traffic to a pool of web servers based on the URL of a request

• 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.

• Application Gateway can make routing decisions based on additional attributes of an HTTP request, for example URI path or host headers.

• 

• This type of routing is known as application layer (OSI layer 7) load balancing

Azure provides a suite of fully managed load-balancing solutions for your scenarios.

• If you are looking to do DNS based global routing and do not have requirements for Transport Layer Security (TLS) protocol termination ("SSL offload"), per-HTTP/HTTPS request or application-layer processing, review Traffic Manager.

• If you need to optimize global routing of your web traffic and optimize top-tier end-user performance and reliability through quick global failover, see Front Door.

• To do network layer load balancing, review Load Balancer.

• Deployment of an Azure Application Gateway requires a dedicated subnet

• Azure Application Gateway offers a web application firewall (WAF) that provides centralized protection of your web applications from common exploits and vulnerabilities.

  • Web applications are increasingly targeted by malicious attacks that exploit commonly known vulnerabilities.

  • SQL injection and cross-site scripting are among the most common attacks.

• Application Gateway operates as an application delivery controller (ADC).

  • It offers Secure Sockets Layer (SSL) termination, cookie-based session affinity, round- robin load distribution, content-based routing, ability to host multiple websites, and security enhancements.

Load Balancing

• Understand Azure load balancing - Pay attention to the global vs regional use and the type of traffic.

• The following table summarizes the Azure load balancing services by these categories:

SSL Termination

Tutorial: Configure an application gateway with TLS termination using the Azure portal

The following image shows how incoming traffic from a client to Application Gateway over SSL is decrypted and then re-encrypted when it's sent to a server in the backend pool.

• The listener can use an SSL certificate to decrypt the traffic that enters the gateway.

  • The listener then uses a rule that you define to direct the incoming requests to a backend pool.

• The backend pool has an HTTP setting that references a certificate used to authenticate the backend servers.

  • The gateway re-encrypts the traffic by using this certificate before sending it to one of your servers in the backend pool.

• If you're using Azure App Service to host the backend application, you don't need to install any certificates in Application Gateway to connect to the backend pool.

  • All communications are automatically encrypted

Application Gateway configuration overview

• Application Gateway configuration overview

• A public IP is required when you host a back end that clients must access over the Internet via an Internet-facing virtual IP (VIP).

• A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address.

  • When you configure the listener, you must enter values for these that match the corresponding values in the incoming request on the gateway.

• After you create the gateway, you can edit the settings of the default rule or create new rules.

• After you create an HTTP setting, you must associate it with one or more request-routing rules.

• After you create a back-end pool, you must associate it with one or more request-routing rules.

  • You must also configure health probes for each back-end pool on your application gateway.

Application Gateway HTTP settings configuration

• Application Gateway HTTP settings configuration

• The application gateway routes traffic to the back-end servers by using the configuration that you specify here.

  • After you create an HTTP setting, you must associate it with one or more request-routing rules.

• Host name override

  • This capability replaces the host header in the incoming request on the application gateway with the host name that you specify.

  • For example, if www.contoso.com is specified in the Host name setting, the original request *https://appgw.eastus.cloudapp.azure.com/path1 is changed to *https://www.contoso.com/path1 when the request is forwarded to the back-end server.

• Application Gateway support for multi-tenant back ends such as App service

• In multi-tenant architectural designs in web servers, multiple websites are running on the same web server instance.

  • Hostnames are used to differentiate between the different applications which are hosted.

  • By default, application gateway does not change the incoming HTTP host header from the client and sends the header unaltered to the back end.

• Override back-end path

• This setting lets you configure an optional custom forwarding path to use when the request is forwarded to the back end.

• Any part of the incoming path that matches the custom path in the override backend path field is copied to the forwarded path.

TLS termination and end to end TLS with multi-tenant services

• TLS termination and end to end TLS with multi-tenant services

• Both TLS termination and end to end TLS encryption is supported with multi-tenant services.

• For TLS termination at the application gateway, TLS certificate continues to be required to be added to the application gateway listener.

• However, in case of end to end TLS, trusted Azure services such as Azure App service web apps do not require allowing the backends in the application gateway.

  • Therefore, there is no need to add any authentication certificates.

• Notice that in the above image, there is no requirement to add authentication certificates when App service is selected as backend.

• Tutorial: Create an application gateway with a Web Application Firewall using the Azure portal

Application Gateway Routing

• The gateway routes requests to a selected web server in the back-end pool, using a set of rules configured for the gateway to determine where the request should go.

• There are two primary methods of routing traffic, path-based routing and multiple site hosting.

• Path-based routing enables you to send requests with different paths in the URL to a different pool of back-end servers.

• Multiple site hosting enables you to configure more than one web application on the same application gateway instance.

  • In a multi-site configuration, you register multiple DNS names (CNAMEs) for the IP address of the Application Gateway, specifying the name of each site.

  • Application Gateway uses separate listeners to wait for requests for each site.

    • Each listener passes the request to a different rule, which can route the requests to servers in a different back-end pool.

  • Multi-site configurations are useful for supporting multi-tenant applications, where each tenant has its own set of virtual machines or other resources hosting a web application.

MultiSite Hosting

• Application Gateway multiple site hosting

• Multiple site hosting enables you to configure more than one web application on the same port of application gateways using public-facing listeners.

• up to 100+ websites to one application gateway

• Each website can be directed to its own backend pool.

  • For example, three domains, http://contoso.com , http://fabrikam.com , and http://adatum.com , point to the IP address of the application gateway.

  • You'd create three multi-site listeners and configure each listener for the respective port and protocol setting.

• You can also define wildcard host names in a multi-site listener

Design Azure Application Gateway

• Design Azure Application Gateway

• Support for the HTTP, HTTPS, HTTP/2 and WebSocket protocols.

• A web application firewall to protect against web application vulnerabilities.

• End-to-end request encryption.

• Autoscaling, to dynamically adjust capacity as your web traffic load change.

• Redirection: Redirection can be used to another site, or from HTTP to HTTPS.

• Rewrite HTTP headers: HTTP headers allow the client and server to pass parameter information with the request or the response.

• Custom error pages: Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.

Choosing an Azure Application Gateway SKU

• Application Gateway is available under a Standard_v2 SKU. Web Application Firewall (WAF) is available under a WAF_v2 SKU.

• The v2 SKU offers performance enhancements and adds support for critical new features like autoscaling, zone redundancy, and support for static VIPs.

• Existing features under the Standard and WAF SKU continue to be supported in the new v2 SKU.

• The new v2 SKU includes the following enhancements:

• Autoscaling: Application Gateway or WAF deployments under the autoscaling SKU can scale out or in based on changing traffic load patterns.

  • Autoscaling also removes the requirement to choose a deployment size or instance count during provisioning. This SKU offers true elasticity.

• Zone redundancy: An Application Gateway or WAF deployment can span multiple Availability Zones, removing the need to provision 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, which makes it more resilient to zone failure.

• Static VIP: Application Gateway v2 SKU supports the static VIP type exclusively. This ensures that the VIP associated with the application gateway doesn't change for the lifecycle of the deployment, even after a restart.

• Header Rewrite: Application Gateway allows you to add, remove, or update HTTP request and response headers with v2 SKU.

• Key Vault Integration: Application Gateway v2 supports integration with Key Vault for server certificates that are attached to HTTPS enabled listeners.

• Azure Kubernetes Service Ingress Controller: The Application Gateway v2 Ingress Controller allows the Azure Application Gateway to be used as the ingress for an Azure Kubernetes Service (AKS) known as AKS Cluster.

• Performance enhancements: The v2 SKU offers up to 5X better TLS offload performance as compared to the Standard/WAF SKU.

• Faster deployment and update time: The v2 SKU provides faster deployment and update time as compared to Standard/WAF SKU. This also includes WAF configuration changes.

• With the v2 SKU, the pricing model is driven by consumption and is no longer attached to instance counts or sizes.

• Each capacity unit is composed of at most: 1 compute unit, 2500 persistent connections, and 2.22-Mbps throughput.

  
  

Configure Azure Application Gateway

• Configure Azure Application Gateway

• Application Gateway has a series of components that combine to route requests to a pool of web servers and to check the health of these web servers.

• You can configure the application gateway to have a public IP address, a private IP address, or both.

  • A public IP address is required when you host a back end that clients must access over the Internet via an Internet-facing virtual IP (VIP).

• Backend pools can be composed of NICs, virtual machine scale sets, public IP addresses, internal IP addresses, fully qualified domain names (FQDN), and multi-tenant back-ends like Azure App Service.

• 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.

• The source IP address Application Gateway uses for health probes depends on the backend pool:

  • If the server address in the backend pool is a public endpoint, then the source address is the application gateway's frontend public IP address.

  • If the server address in the backend pool is a private endpoint, then the source IP address is from the application gateway subnet's private IP address space.

Default health probe

• Default health probe

• An application gateway automatically configures a default health probe when you don't set up any custom probe configurations.

• The monitoring behavior works by making an HTTP GET request to the IP addresses or FQDN configured in the back-end pool.

• The following table lists the default health probe settings:

• All instances of Application Gateway probe the backend independent of each other.

• The same probe configuration applies to each Application Gateway instance.

• If there are multiple listeners, then each listener probes the backend independent of each other.

• Custom probes give you more granular control over the health monitoring.

  • When using custom probes, you can configure a custom hostname, URL path, probe interval, and how many failed responses to accept before marking the back-end pool instance as unhealthy

• By default, an HTTP(S) response with status code between 200 and 399 is considered healthy.

• Custom health probes additionally support two matching criteria.

  • HTTP response status code match - Probe matching criterion for accepting user specified http response code or response code ranges.

    • Individual comma-separated response status codes or a range of status code is supported.

  • HTTP response body match - Probe matching criterion that looks at HTTP response body and matches with a user specified string.

    • The match only looks for presence of user specified string in response body and isn't a full regular expression match.

  • Match criteria can be specified using the New-AzApplicationGatewayProbeHealthResponseMatch cmdlet.

    
    

Configure listeners

• A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address.

• When you configure a listener, you must enter values that match the corresponding values in the incoming request on the gateway.

• After you create the application gateway, you can edit the settings of that default listener (appGatewayHttpListener) or create new listeners.

  • Basic: All requests for any domain will be accepted and forwarded to backend pools.

  • Multi-site: Forward requests to different backend pools based on the host header or host names.

    • You must specify a host name that matches with the incoming request.

    • This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port.

• For the v2 SKU, multi-site listeners are processed before basic listeners.

• Choose the front-end IP address that you plan to associate with this listener

• Choose the front-end port.

• HTTPS: enables TLS termination or end-to-end TLS encryption.

  • The TLS connection terminates at the application gateway.

  • Traffic between the client and the application gateway is encrypted.

  • If you want end-to-end TLS encryption, you must choose HTTPS and configure the back-end HTTP setting.

    • This ensures that traffic is re-encrypted when it travels from the application gateway to the back end.

• To configure TLS termination and end-to-end TLS encryption, you must add a certificate to the listener to enable the application gateway to derive a symmetric key.

  • This is dictated by the TLS protocol specification.

  • The symmetric key is used to encrypt and decrypt the traffic that's sent to the gateway.

  • The gateway certificate must be in Personal Information Exchange (PFX) format.

    • This format lets you export the private key that the gateway uses to encrypt and decrypt traffic.

• Configure end-to-end TLS by using Application Gateway with the portal

• Application Gateway v2 SKU requires trusted root certificates for enabling end-to-end configuration.

• To configure end-to-end TLS with an application gateway, you need a certificate for the gateway.

  • Certificates are also required for the back-end servers.

• For end-to-end TLS encryption, the right back-end servers must be allowed in the application gateway.

  • To allow this access, upload the public certificate of the back-end servers, also known as Authentication Certificates (v1) or Trusted Root Certificates (v2), to the application gateway.

    • For Standard and WAF (v1) application gateways, you should upload the public key of your back-end server certificate in .cer format.

    • For Standard_v2 and WAF_v2 application gateways, you should upload the root certificate of the back-end server certificate in .cer format.

      • If the back-end certificate is issued by a well-known certificate authority (CA), you can select the Use Well Known CA Certificate check box, and then you don't have to upload a certificate.

  • Adding the certificate ensures that the application gateway communicates only with known back-end instances.

• To create a new application gateway with end-to-end TLS encryption, you'll need to first enable TLS termination while creating a new application gateway.

  • This action enables TLS encryption for communication between the client and application gateway.

  • Then, you'll need to put on the Safe Recipients list the certificates for the back-end servers in the HTTP settings.

    • This configuration enables TLS encryption for communication between the application gateway and the back-end servers.

  • That accomplishes end-to-end TLS encryption.

Redirection overview

• You can use application gateway to redirect traffic.

• It has a generic redirection mechanism which allows for redirecting traffic received at one listener to another listener or to an external site.

• A common redirection 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.

• The following types of redirection are supported:

  • 301 Permanent Redirect

  • 302 Found

  • 303 See Other

  • 307 Temporary Redirect
    

• see URL path-based redirection using PowerShell - Azure Application Gateway | Microsoft Docs.

Application Gateway request routing rules

• When you create an application gateway using the Azure portal, you create a default rule (rule1).

  • This rule binds the default listener (appGatewayHttpListener) with the default back-end pool (appGatewayBackendPool) and the default back-end HTTP settings (appGatewayBackendHttpSettings).

• For a basic rule, only one back-end pool is allowed.

  • All requests on the associated listener are forwarded to that back-end pool.

• For a path-based rule, add multiple back-end pools that correspond to each URL path.

  • The requests that match the URL path that's entered are forwarded to the corresponding back-end pool.

• Add a back-end HTTP setting for each rule.

  • Requests are routed from the application gateway to the back-end targets by using the port number, protocol, and other information that's specified in this setting.

Rewrite HTTP headers and URL

• By using rewrite rules, you can add, remove, or update HTTP(S) request and response headers as well as URL path and query string parameters as the request and response packets move between the client and backend pools via the application gateway.

• The headers and URL parameters can be set to static values or to other headers and server variables.

• HTTP header and URL rewrite features are only available for the Application Gateway v2 SKU.

• By rewriting these headers, you can accomplish important tasks, such as adding security-related header fields like HSTS/ X-XSS-Protection, removing response header fields that might reveal sensitive information, and removing port information from X-Forwarded-For headers.

• Rewrite the host name, path, and query string of the request URL

The value of a URL or a new or existing header can be set to these types of values:

• Text

• Request header. To specify a request header, you need to use the syntax {http_req_headerName}

• Response header. To specify a response header, you need to use the syntax {http_resp_headerName}

• Server variable. To specify a server variable, you need to use the syntax {var_serverVariable}. See the list of supported server variables

• Rewrite HTTP headers and URL with Application Gateway

• Application Gateway allows you to rewrite selected content of requests and responses.

• With this feature, you can translate URLs, query string parameters as well as modify request and response headers.

• It also allows you to add conditions to ensure that the URL or the specified headers are rewritten only when certain conditions are met

URL rewrite vs URL redirect

• URL rewrite vs URL redirect

• In the case of a URL rewrite, Application Gateway rewrites the URL before the request is sent to the backend.

  • This will not change what users see in the browser because the changes are hidden from the user.

• In the case of a URL redirect, Application Gateway sends a redirect response to the client with the new URL.

  • That, in turn, requires the client to resend its request to the new URL provided in the redirect.

  • The URL that the user sees in the browser will update to the new URL.

• Rewrites are not supported when the application gateway is configured to redirect the requests or to show a custom error page.

UrlPathMap configuration element

• UrlPathMap configuration element

"urlPathMaps": [{

 "name": "{urlpathMapName}",

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/urlPathMaps/{urlpathMapName}",

 "properties": {

 "defaultBackendAddressPool": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName1}"

 },

 "defaultBackendHttpSettings": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpSettingsList/{settingname1}"

 },

 "pathRules": [{

 "name": "{pathRuleName}",

 "properties": {

 "paths": [

 "{pathPattern}"

 ],

 "backendAddressPool": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendAddressPools/{poolName2}"

 },

 "backendHttpsettings": {

 "id": "/subscriptions/{subscriptionId}/../microsoft.network/applicationGateways/{gatewayName}/backendHttpsettingsList/{settingName2}"

 }

 }

 }]

 }

}]

• PathPattern 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 "/."

WAF Policy Priorities

• Azure Web Application Firewall (WAF) policy overview

• These policies are then associated to an application gateway (global), a listener (per-site), or a path-based rule (per-URI) for them to take effect.

• When you associate a WAF policy globally, every site behind your Application Gateway WAF is protected with the same managed rules, custom rules, exclusions, and any other configured settings.

  • If you want a single policy to apply to all sites, you can associate the policy with the application gateway.

• With per-site WAF policies, you can protect multiple sites with differing security needs behind a single WAF by using per-site policies.

  • For example, if there are five sites behind your WAF, you can have five separate WAF policies (one for each listener) to customize the exclusions, custom rules, managed rule sets, and all other WAF settings for each site.

  • Say your application gateway has a global policy applied to it.

    • Then you apply a different policy to a listener on that application gateway.

    • The listener's policy now takes effect for just that listener.

    • The application gateway’s global policy still applies to all other listeners and path-based rules that don't have a specific policy assigned to them.

  • For even more customization down to the URI level, you can associate a WAF policy with a path-based rule. If there are certain pages within a single site that require different policies, you can make changes to the WAF policy that only affect a given URI.

• Priotity value: Determines the rule valuation order.

  • The lower the value, the earlier the evaluation of the rule. The allowable range is from 1-100.

  • Must be unique across all custom rules.

  • A rule with priority 40 is evaluated before a rule with priority 80.