Application Gateway Private Link configuration shows Succeeded but privateIpAddress is null, no IP allocated in subnet, no privateLinkServices resource – expected or broken?

Kristian Gravermoen 0 Reputation points
2026-09-15T12:11:48.5366667+00:00

Application Gateway WAF_v2 with a Private Link configuration bound to the public IPv4 frontend, dedicated Private Link subnet (privateLinkServiceNetworkPolicies = Disabled, no delegation, no route table). Created via CLI:

az network application-gateway private-link add -g <rg> --gateway-name <gw> --name frontdoor-pl --frontend-ip <ipv4-frontend-name> --subnet <pl-subnet-id>

Result:

az network application-gateway private-link list -g <rg> --gateway-name <gw> --query "[].ipConfigurations[].{ip:privateIpAddress, primary:primary, state:provisioningState}"

→ ip: null, primary: null, state: Succeeded

az network vnet subnet show --ids <pl-subnet-id> --query "ipConfigurations[].id"

→ [] (nothing allocated in the Private Link subnet) 

az network private-link-service show -g <rg> -n e41f87a2<gw>_frontdoor-pl

→ ResourceNotFound

az resource list -g <rg> --resource-type Microsoft.Network/privateLinkServices

→ empty

az network application-gateway show -g <rg> -n <gw> --query "frontendIPConfigurations[].{name:name, pl:privateLinkConfiguration.id}"

→ the IPv4 frontend correctly references .../privateLinkConfigurations/frontdoor-pl The portal Private link blade also shows no private IP address for the configuration. Activity Log shows no failed operations and no operations on Microsoft.Network/privateLinkServices. No Azure Policy denies, only a CanNotDelete lock. Feature EnableApplicationGatewayNetworkIsolation is not registered. Removing and recreating the configuration gives the identical result. Private endpoint connections against this gateway (both an Azure Front Door Premium managed private endpoint and a manually created private endpoint) can be approved successfully, but no traffic through them ever reaches the gateway.

QUESTIONS

  1. For a healthy Application Gateway Private Link configuration, should privateIpAddress be populated in privateLinkConfigurations[].ipConfigurations[], and should the Private Link subnet show an ipConfiguration reference? In other words: is what we see a provisioning failure, or is the NAT IP simply not exposed to the customer?
  2. Should the hidden e41f87a2<gatewayName>_<plConfigName> privateLinkServices resource be visible via ARM (az resource list / az network private-link-service show), or is it intentionally hidden? The Front Door docs tell you to construct its ID rather than look it up.
  3. If this is a provisioning failure, is there anything customer-side (API version, ordering – e.g. Private Link configuration must exist before the listener, subnet size, dual-stack gateway) known to cause it, or is it strictly a backend issue requiring a support ticket? If anyone with a working AFD → App GW Private Link setup could run the three commands above and post what a healthy result looks like, that alone would tell us whether we are chasing a real fault. Thank you.
Azure Private Link
Azure Private Link

An Azure service that provides private connectivity from a virtual network to Azure platform as a service, customer-owned, or Microsoft partner services.

0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Walker Pollitt 0 Reputation points
    2026-09-17T20:05:33.8733333+00:00

    What you are seeing does not look like a healthy, fully provisioned Application Gateway Private Link configuration.

    For question 1:

    Microsoft's current Application Gateway Private Link documentation says the dedicated Private Link subnet is used specifically for Private Link IP configurations, and that at least one IP address must be configured. Only dynamic allocation is supported.

    The current ARM schema for ApplicationGatewayPrivateLinkIpConfigurationProperties also exposes:

    • privateIPAddress
    • privateIPAllocationMethod
    • primary
    • subnet

    So I would expect a successfully provisioned Private Link configuration to have an IP configuration associated with the dedicated subnet, with a dynamically assigned private IP.

    A configuration showing provisioningState = Succeeded while:

    • privateIPAddress is null
    • primary is null
    • the dedicated subnet has no ipConfiguration reference
    • and Private Endpoint connections can be approved but no traffic reaches the gateway

    is strong evidence that the Private Link data path has not actually been provisioned correctly.

    For question 2:

    I would not use the absence of a normal Microsoft.Network/privateLinkServices resource from a resource list as the primary health test.

    Microsoft's Azure Front Door documentation specifically tells you to construct the Application Gateway Private Link Service resource ID in this form:

    /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/privateLinkServices/e41f87a2{applicationGatewayName}_{privateLinkConfigName}

    The documentation also notes that Application Gateway Private Link does not expose the normal Private Link Service alias and must be referenced through its resource URI.

    That suggests this integration should not necessarily be treated like a customer-created standalone Private Link Service resource.

    The missing IP configuration is the more significant symptom.

    For question 3:

    I would verify the documented prerequisites before treating this as a backend fault:

    1. Confirm an active listener is actually using the frontend IP configuration that the Private Link configuration is attached to.

    Microsoft explicitly says the listener must already be actively configured against the target frontend before creating the Private Link configuration.

    1. Confirm the Private Link subnet:
    • is separate from the Application Gateway subnet
    • has privateLinkServiceNetworkPolicies disabled
    • has sufficient address space
    • has no conflicting delegation/configuration
    1. Confirm dynamic allocation is being used. Static allocation is not supported.
    2. Check the combined Application Gateway name plus Private Link configuration name. Microsoft currently documents a 70-character combined limit to avoid deployment failures.
    3. Use an Application Gateway API version of 2020-03-01 or later.

    After those checks, I would remove and recreate the Private Link configuration and then immediately inspect:

    az network application-gateway private-link list ...

    and:

    az network application-gateway private-link ip-config list ...

    A healthy result should give you an actual Private Link IP configuration tied to the dedicated subnet rather than null IP configuration properties.

    Because you have already recreated the configuration, have approved Private Endpoint connections, and traffic still never reaches the gateway, if the listener and subnet prerequisites above are confirmed I would open an Azure support case.

    I would include:

    • Application Gateway resource ID
    • Private Link configuration resource ID
    • correlation/request IDs from the create/update operation
    • Activity Log entries
    • output of the private-link and ip-config list commands
    • subnet resource JSON
    • Private Endpoint connection JSON
    • exact timestamps

    The contradiction between provisioningState = Succeeded and the absence of an allocated Private Link IP is the key evidence I would give support.

    References:

    https://learn.microsoft.com/azure/application-gateway/private-link-configure

    https://learn.microsoft.com/azure/application-gateway/private-link

    https://learn.microsoft.com/azure/frontdoor/how-to-enable-private-link-application-gateway

    Was this answer helpful?

    0 comments

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.