I deployed Azure Application Gateway v2 in a hub-and-spoke network. There are two gateways in the hub: one for public traffic and another for internal traffic. Their backend resources are located in peered spoke VNets. The backend is a static website hosted in an Azure Storage account, accessed through the storage account's private endpoint. The Application Gateway backend is configured with the storage hostname, while clients use a custom hostname such as app.example.local. The Application Gateway subnets and the storage spoke have routes through an internal NVA. Requests currently return 502 Bad Gateway errors. Do I need a private endpoint for the Application Gateway itself, or should VNet peering allow it to reach the storage private endpoint? What routing, DNS, host header, or listener settings should I verify?
4 Answers
DNS is one of the first things to validate. The storage hostname configured in the backend should resolve from the Application Gateway subnet to the private endpoint IP, usually through the appropriate private DNS zone linked to the VNet. Also confirm that the custom frontend hostname and the storage backend hostname are not being confused.
You do not normally need a private endpoint for Application Gateway. A v2 gateway can use its ApplicationGatewaySubnet to make outbound connections to a private endpoint across VNet peering. Check that the storage private endpoint’s IP is reachable from the gateway subnet, that network security groups and NVA routing allow the traffic, and that return traffic follows a valid path.
Both gateways have private and public frontends, and the gateway subnets use routes through the internal NVA. I’m checking the complete path in both directions now.
A 502 can result from a host header or TLS mismatch rather than from VNet connectivity. Verify the backend HTTP setting, including the hostname used for the request, the protocol and port, certificate validation, and whether the storage static website endpoint expects a particular host header. Also confirm that the health probe uses the correct hostname, path, and status code.
The gateway subnet must have a working route to the private endpoint address, and the private endpoint subnet must allow the connection back. Test name resolution and TCP connectivity from a suitable resource in the same subnet or network path, then review Application Gateway backend health details. Those diagnostics usually identify whether the failure is DNS, routing, the probe, or the backend response.
The frontend uses app.example.local, while the backend is configured with the storage hostname. I’m not yet sure whether the backend host header is being set correctly.