Application Gateway V1 frontend unreachable (connection timeout) — backend healthy, NSGs correct, fresh restart with new IP didn't help

Saeed Anwar 0 Reputation points
2026-08-13T10:03:35.8766667+00:00

Our Application Gateway (V1 SKU) "EnFMGateway" is completely unreachable from the public internet on ports 80/443, even after a full stop/start (which assigned a new public IP: 20.74.250.181). Backend health shows Healthy, VM is running normally, and all NSGs (VM subnet and App Gateway subnet) are correctly configured to allow this traffic. We also confirmed the frontend is unreachable even from Azure's own internal network (tested via Cloud Shell curl - connection times out). No VNet peering, no Network Security Perimeter, and no blocking Azure Policy exists. Azure's own built-in support troubleshooter ran 5 diagnostic checks and found no issues. SKU is Standard_Small (V1), which is being retired soon - wondering if this could be related to a platform-side issue with V1 gateways.

Azure Firewall
Azure Firewall

An Azure network security service that is used to protect Azure Virtual Network resources.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-08-13T10:03:56.59+00:00

    The supported checks point to network path or management-plane access issues, not backend health.

    For an Application Gateway v1 that shows Healthy backends but the public frontend times out on 80/443, validate these areas end to end:

    1. Application Gateway subnet NSG
      • On the Application Gateway Overview tab, open Virtual Network/Subnet.
      • Open the subnet where the gateway is deployed.
      • If an NSG is associated, confirm it allows Azure management traffic from GatewayManager.
      • For v1, add an inbound rule with:
        • Source: GatewayManager
        • Destination port range: 65503-65534
      • Save and recheck gateway behavior.
      This rule is required for Azure infrastructure to communicate with Application Gateway instances. If blocked, the gateway can have provisioning, scaling, or management problems.
    2. UDR on the Application Gateway subnet
      • Check whether a route table is associated with the Application Gateway subnet.
      • Look for a default route 0.0.0.0/0 whose next hop is not Internet.
      • If the next hop is Virtual Appliance or Virtual Network Gateway, make sure that path returns traffic correctly and does not modify probe traffic.
      • Otherwise, change the next hop to Internet, save, and verify again.
      The documentation explicitly calls out UDRs that redirect traffic away from the backend or alter routing through ExpressRoute/VPN as a cause of connectivity and health anomalies.
    3. Effective NSG and route checks on the backend side Even with healthy backend status, confirm there is no asymmetric routing or hidden deny rule affecting traffic flow: 
         Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
   Get-AzEffectiveRouteTable -NetworkInterfaceName "nic1" -ResourceGroupName "testrg"
      Also verify the Application Gateway subnet allows outbound public and private traffic.
    4. Listener/backend port validation If the configured backend port is not the intended one, correct it in Application Gateway. If local connectivity to that port also fails, the issue is on the backend path rather than the gateway.
    5. Backend server listening state On the backend VM, verify the application is actually listening on the configured port: 
         netstat
      Expected result is a listening socket on the configured port, for example 0.0.0.0:80 LISTENING.
    6. Custom DNS if backend pool uses FQDNs If backend members are configured by FQDN, check whether the VNet has custom DNS configured and whether it resolves the backend names correctly.

    What is supported by the available guidance:

    • A healthy backend does not rule out NSG/UDR/DNS issues affecting Application Gateway traffic paths.
    • For v1, the GatewayManager inbound rule on ports 65503-65534 is specifically required.
    • The provided material does not state that retirement of v1 SKU causes public frontend timeouts or that there is a known platform-side issue tied to retirement.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.