Application Gateway Listeners

Listeners are the core component of an Azure Application Gateway. They are responsible for accepting incoming traffic to your web applications. A listener inspects incoming requests and uses a configured port, protocol, host name, and certificate to match the request to a rule.

What is a Listener?

An Application Gateway listener can be configured to listen for requests on a specific IP address, port, protocol, and with an optional host name. This allows you to route traffic to different backend pools based on the incoming request's characteristics.

Listener Properties

Property	Description	Required
Name	A unique name for the listener.	Yes
Frontend IP address	Specifies whether the listener uses a public or private frontend IP.	Yes
Protocol	The protocol the listener listens on (HTTP or HTTPS).	Yes
Port	The port number the listener listens on (e.g., 80 for HTTP, 443 for HTTPS).	Yes
Host name	(Optional) The host name to match the incoming request (e.g., `www.example.com`). Wildcard hosts are supported.	No
SSL certificate	(Required for HTTPS listeners) The SSL certificate to use for SSL termination. This can be a certificate uploaded directly or referenced from Azure Key Vault.	Yes (for HTTPS)
SSL Policy	(Optional) Defines the SSL/TLS cipher suites and SSL/TLS version that are allowed for HTTPS connections.	No

Types of Listeners

Basic Listener

A basic listener is the simplest type and requires only a name, frontend IP, protocol, and port. It's suitable for simple setups where you don't need to differentiate traffic based on host name or SSL certificates.

Multi-site Listener

A multi-site listener allows you to host multiple websites on a single Application Gateway instance. You achieve this by specifying a unique Host name for each listener. The Application Gateway then routes traffic based on the host header in the incoming request.

Custom Host Listener

This is similar to a multi-site listener but specifically refers to listeners that use a custom domain name configured for your application.

Configuring an HTTPS Listener

To enable secure communication over HTTPS, you need to configure an HTTPS listener. This involves providing an SSL certificate.

Important: For HTTPS listeners, you must associate an SSL certificate with the listener. This certificate is used for SSL termination at the Application Gateway. You can either upload a certificate in PFX format or reference a certificate stored in Azure Key Vault.

SSL Termination vs. End-to-End SSL

SSL Termination: The Application Gateway decrypts the HTTPS traffic using its SSL certificate and then sends unencrypted HTTP traffic to the backend servers. This is the most common configuration.
End-to-End SSL: The Application Gateway decrypts the HTTPS traffic, then re-encrypts it using a certificate configured on the backend server before sending it. This provides an extra layer of security.

Example: Creating a Listener

Here's a conceptual example of how you might define a listener using Azure CLI:


az network application-gateway listener create \
  --resource-group myResourceGroup \
  --gateway-name myAppGateway \
  --name myhttplistenerssl \
  --frontend-ip myFrontendIP \
  --frontend-port 443 \
  --protocol Https \
  --host-name www.example.com \
  --ssl-cert /path/to/your/certificate.pfx \
  --ssl-cert-password your_certificate_password

Listener Association with Rules

Once a listener is configured, it needs to be associated with a request routing rule. The rule defines how traffic received by the listener is processed, including which backend pool to send it to and any content-based routing or redirection rules.

Tip: A single listener can be associated with multiple request routing rules, allowing for complex routing scenarios.

Best Practices

Use distinct host names for different applications or subdomains hosted on the same Application Gateway.
Always configure HTTPS listeners with up-to-date SSL certificates.
Utilize SSL policies to enforce strong security settings.
Ensure your listener ports and protocols align with your application requirements.