Keeping an Azure Application Gateway Private Without Losing Layer 7 Routing

The gateway needs to present a certificate that matches the hostname used by clients.

For example:

Client requests:

finance.internal.example.com

Certificate must cover:

finance.internal.example.com

If the certificate does not match, clients may report TLS errors even though network connectivity is working.

When troubleshooting HTTPS, separate the problem into:

DNS
  ↓
Network connectivity
  ↓
TCP connection
  ↓
TLS handshake
  ↓
HTTP routing
  ↓
Backend response

This layered approach prevents certificate problems from being confused with routing problems.

Backend Pools

Application Gateway sends requests to backend pools.

A backend pool might contain:

• Virtual machines

• Virtual machine scale sets

• Private IP addresses

• App Service resources

• Kubernetes-related endpoints

• Other supported backend targets

The gateway does not simply forward traffic to anything that responds.

It uses its configured backend settings and health probes to determine whether a backend is available.

For example:

Application Gateway
       |
       v
Backend Pool
   |
   +-- Server 1 → Healthy
   |
   +-- Server 2 → Healthy
   |
   +-- Server 3 → Unhealthy

Traffic can then be routed according to the gateway configuration.

Health Probes Matter

A private Application Gateway can have a healthy frontend but unhealthy backends.

This creates a common troubleshooting situation:

Client
   |
   v
Private IP
   |
   v
Gateway responds
   |
   X
Backend unavailable

The client may receive errors such as 502 or another gateway-level response.

When this happens, check the backend health rather than immediately changing DNS or network rules.

Verify:

• Probe protocol

• Probe hostname

• Probe path

• Probe port

• Expected status code

• Backend listener

• Backend network connectivity

The health probe should test something that represents actual application readiness.

Host Headers Can Cause Problems

Some backend applications expect a specific Host header.

For example, the gateway may receive:

Host: portal.internal.example.com

but the backend application may expect:

Host: backend.internal.local

If the gateway's backend settings do not handle this correctly, the backend may return an error even though the network connection works.

This is particularly important with:

• Web servers

• Multi-tenant applications

• Frameworks that validate hostnames

• Applications using virtual hosts

• Authentication systems

Always test the complete HTTP request path rather than only testing whether the backend IP is reachable.

Private Application Gateway and AKS

Application Gateway is often used in front of Azure Kubernetes Service applications.

A simplified architecture is:

Private Client
      |
      v
Private Application Gateway
      |
      v
AKS Ingress
      |
      v
Kubernetes Service
      |
      v
Pods

The gateway provides the Azure-side application entry point.

The Kubernetes ingress layer handles application routing inside the cluster.

This can be useful when an organization wants Azure-native traffic management while keeping the Kubernetes workloads private.

However, it introduces another layer that must be monitored.

A request can fail at:

Client
  ↓
DNS
  ↓
Application Gateway
  ↓
Ingress
  ↓
Service
  ↓
Pod

Troubleshooting should follow the same order.

Private Access From Another VNet

Suppose Application Gateway is deployed in VNet A and the client application is deployed in VNet B.

The architecture may look like:

VNet A
|
+-- Private Application Gateway
|
|
+--------- VNet Peering ---------
|
|
VNet B
|
+-- Client Application

The client needs:

• DNS resolution

• Route to the private frontend

• Network security permission

• Return route

• Correct port access

VNet peering by itself does not guarantee that every traffic path is valid.

Always test the actual route.

Private Access From On-Premises

Enterprise environments may also expose the private gateway to on-premises clients.

For example:

Corporate Network
       |
       v
ExpressRoute / VPN
       |
       v
Azure VNet
       |
       v
Private Application Gateway
       |
       v
Application

The private gateway can therefore serve as an internal application entry point for employees and corporate systems.

The network team must ensure that the private IP range is advertised or routed correctly to the corporate environment.

DNS must also return the private address to those clients.

Network Security Rules

Private Application Gateway should not be treated as automatically trusted simply because it has a private IP.

Restrict network access to the gateway based on the actual client requirements.

For example:

Corporate subnet
      |
      | TCP 443
      v
Application Gateway

may be allowed.

But:

Every VNet
      |
      | TCP 443
      v
Application Gateway

may be unnecessarily broad.

Review:

• Source networks

• Destination subnet

• Destination port

• Required protocols

• Network security groups

• Azure Firewall policies

• Route tables

Network security should reinforce the application's intended access model.

Web Application Firewall

A private Application Gateway can still be useful when Web Application Firewall capabilities are required.

The security architecture can therefore be:

Private Client
      |
      v
Private Application Gateway + WAF
      |
      v
Backend Application

The application does not need to be public simply because WAF functionality is required.

This can be useful for internal applications that still need protection against application-layer attacks.

However, WAF rules should be tested against the application's actual behavior.

Internal applications can still generate false positives when they use:

• Complex JSON

• File uploads

• Special URL parameters

• Unusual headers

• Custom API formats

Troubleshooting Private Application Gateway

Use a layered approach.

Step 1: Verify DNS

Confirm the hostname resolves to the expected private frontend IP.

nslookup app.internal.example.com

Step 2: Verify Network Connectivity

Confirm that the client can reach the private IP over the expected port.

Check:

• VNet connectivity

• VNet peering

• VPN

• ExpressRoute

• Network security groups

• Azure Firewall

• Route tables

Step 3: Check Gateway Listener

Verify:

• Frontend IP

• Frontend port

• HTTPS configuration

• Certificate

• Hostname

• Listener state

Step 4: Check Routing Rules

Verify that the incoming hostname or path matches the expected rule.

For example:

api.internal.example.com
        |
        v
API backend

portal.internal.example.com
        |
        v
Portal backend

Step 5: Check Backend Health

If the gateway is reachable but requests fail, check backend health.

Step 6: Check Backend Connectivity

Confirm that the gateway can reach the backend on the configured port.

Step 7: Check Application Logs

Only after the network and gateway layers are verified should you move deeper into application debugging.

This avoids wasting time investigating application code when the actual failure is a route or listener configuration.

Common Mistakes

Removing the Public IP but Forgetting DNS

Clients may still attempt to use the old public address.

Treating Private as Automatically Secure

A private IP reduces exposure but does not replace authorization or network controls.

Ignoring Backend Health

A healthy gateway does not mean the application behind it is healthy.

Incorrect Hostname Configuration

A listener, certificate, routing rule, or backend may expect a different hostname.

Incorrect TLS Configuration

The certificate may not match the hostname requested by the client.

Forgetting Return Routing

The client may reach the gateway while the response path fails.

Making the Gateway Subnet Too Open

Private infrastructure should still have controlled access.

Testing Only From One Network

An application that works from the same VNet may fail from an on-premises network or another peered VNet.

Production Checklist

Before keeping an Azure Application Gateway private, verify:

• Private frontend architecture is defined.

• Gateway subnet is correctly configured.

• Private IP address is assigned as expected.

• Private DNS is configured.

• Required clients resolve the correct private hostname.

• VNet routing is configured.

• VNet peering is validated where required.

• VPN or ExpressRoute routing is validated where required.

• Network security rules are reviewed.

• HTTPS listeners are configured.

• Certificates match the application hostnames.

• Backend pools are configured correctly.

• Backend health probes are working.

• Host-based routing is tested.

• Path-based routing is tested where applicable.

• Backend Host header behavior is verified.

• TLS termination is documented.

• Backend encryption requirements are documented.

• WAF rules are tested if WAF is enabled.

• Application authentication remains enabled.

• Gateway logs are available.

• Backend application logs are available.

• Failure scenarios are tested.

• No unnecessary public endpoint remains.

Advantages and Disadvantages

Advantages

A private Application Gateway provides:

• Private application entry points

• Layer 7 routing

• Host-based routing

• Path-based routing

• HTTPS termination

• Backend health monitoring

• Centralized application traffic management

• Integration with private Azure networking

• Optional WAF protection

Disadvantages

The architecture also introduces additional operational requirements:

• Private DNS must be maintained.

• Routing becomes more complex.

• Gateway and backend health must be monitored separately.

• TLS certificates require management.

• Cross-VNet and on-premises connectivity needs explicit configuration.

• Troubleshooting spans multiple network layers.

The additional complexity is reasonable when the application needs Layer 7 routing but should not be publicly exposed.

Summary

Keeping Azure Application Gateway private does not mean giving up Layer 7 routing.

The gateway can continue to make decisions based on hostnames, URL paths, HTTPS configuration, backend health, and other application-level information while clients reach it through private network connectivity.

The key is to design the complete path:

Client
   ↓
Private DNS
   ↓
Private IP
   ↓
Application Gateway
   ↓
Backend routing
   ↓
Application

DNS determines where the client connects. Azure networking determines whether that private address is reachable. Application Gateway handles Layer 7 routing and backend selection. Network security controls determine which clients are permitted to connect.

When these layers are configured together, internal applications can retain the benefits of Application Gateway without requiring a public frontend.

The most important operational practice is to troubleshoot the architecture from the outside in. Check DNS first, then routing, then the gateway listener and routing rules, then backend health, and finally the application. This makes private Application Gateway deployments much easier to operate and diagnose in production.