virtualNetworkGateways/getEffectiveRoutes never completes — stuck at 202 Accepted indefinitely

Question

I'm calling the Get Effective Routes operation on a classic VNet gateway (Microsoft.Network/virtualNetworkGateways/{name}/getEffectiveRoutes) and the long-running operation never progresses past 202 Accepted.

Request:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/virtualNetworkGateways/{virtualNetworkGatewayName}/getEffectiveRoutes?api-version=2026-01-01

Response: 202 Accepted with a Location header (and Retry-After: 10) pointing to:

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/operationResults/{operationId}?api-version=2026-01-01&...

Polling that Location URL repeatedly (20+ attempts, spaced 10–15s apart, over several minutes) keeps returning 202 Accepted with an empty body — it never resolves to either a 200 OK with the route table or an error.

What I've already ruled out:

• Permissions are not the issue. The calling service principal's custom role explicitly includes the Microsoft.Network/virtualNetworkGateways/effectiveRouteTable/action permission
• Confirmed the request itself is well-formed and reaches the service (not a 404/wrong-path issue — I initially had the wrong path segment, effectiveRouteTable instead of getEffectiveRoutes, which correctly returned a distinct 404; this is a separate, later problem once the path was corrected).
• Polling the exact Location URL as returned (not reconstructed/modified), so this isn't the "wrong caller polling the async operation" AuthorizationFailed case either.

Question: Is there a known issue with getEffectiveRoutes hanging indefinitely on gateways with a particular shape — e.g., active-active, mixed BGP/non-BGP connections, or a connection to a Virtual WAN hub VPN gateway alongside classic VNet-to-VNet/IPsec connections on the same gateway?

Answer 1

Hello Peter Stieber,

Greetings! Thanks for raising this question in the Q&A forum.

Your request is well-formed and your polling is correct, so this is not a permissions or path problem. For gateway route operations (learned routes, advertised routes and effective routes), Azure Resource Manager returns 202 with a Location URL and expects you to poll until it returns 200 with the result, so an operation that stays at 202 with an empty body well past the normal time points to the gateway control plane not completing the work. I could not find a documented limitation that ties this behavior to a particular gateway shape such as active-active, mixed BGP and non-BGP connections, or a connection to a Virtual WAN hub gateway, and I can't confirm a known issue from here. Please try the following to narrow it down.

1. Check the gateway health first. The route operations need the gateway to be in a healthy state. Run:

az network vnet-gateway show --name <gateway-name> --resource-group <rg-name> --query "{state:provisioningState, sku:sku.name, activeActive:activeActive, bgp:enableBgp}" -o json

Provisioning state should be Succeeded. Also check Resource Health and the Activity log of the gateway for failed or running operations, since a stuck update or reset can block later operations on the same gateway.

1. Compare with the related route operations. These use the same asynchronous pattern, so they show whether only the effective routes call is affected. Run:

az network vnet-gateway list-learned-routes --name <gateway-name> --resource-group <rg-name>

az network vnet-gateway list-advertised-routes --name <gateway-name> --resource-group <rg-name> --peer <bgp-peer-ip>

In PowerShell, Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName <rg-name> -VirtualNetworkGatewayName <gateway-name>. If these complete normally and only getEffectiveRoutes hangs, the problem is specific to that operation or API version. If all of them hang, the problem is with the gateway itself.

1. Try another API version. Your call uses api-version=2026-01-01, which is very recent. Repeat the same POST with an earlier stable version such as 2025-05-01 or 2024-05-01 and compare:

az rest --method post --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Network/virtualNetworkGateways/<gateway-name>/getEffectiveRoutes?api-version=2025-05-01" --verbose

With --verbose you can see the Location header and poll it yourself. If the older version completes, that is useful evidence for the support team.

Poll with a longer window and read the headers. Keep polling the Location URL for at least 10 to 15 minutes, and log every response status, the x-ms-request-id, and the x-ms-correlation-request-id. Also test with the SDK or CLI poller instead of a hand-written loop, because they follow the Azure-AsyncOperation or Location header rules exactly.

Use a gateway reset only as a last resort. If other gateway operations also fail, a reset restarts the gateway instances and often clears a stuck control-plane state:

az network vnet-gateway reset --name <gateway-name> --resource-group <rg-name>

This interrupts VPN connectivity for a short time, and on an active-active gateway you should reset in a maintenance window. I would only do this after the earlier checks, and not on a production gateway without planning.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,
Jerald Felix