Configuring Azure Firewall Rules for Managed DevOps Pools with VNET Injection
Azure Managed DevOps Pool with VNET Injection
When deploying an Azure Managed DevOps Pool using VNET injection, where the VNET is peered via Azure Virtual WAN (VWAN) with an Azure Firewall, you need to add application rule collections to your firewall to allow the required outbound traffic. Without these rules, the pool agents will either fail to start or fail to communicate with Azure DevOps.
Why Is This Needed?
By default, Managed DevOps Pools use a Microsoft-provided virtual network with unrestricted outbound access. However, when you inject the pool into your own VNET and route traffic through an Azure Firewall (e.g., via VWAN hub), all outbound traffic is subject to your firewall rules. The pool agents need to reach several Microsoft endpoints to:
- Register and communicate with the Managed DevOps Pools service (
*.prod.manageddevops.microsoft.com) - Download agent binaries and startup scripts (
rmprodbuilds.azureedge.net) - Connect to Azure DevOps to receive pipeline jobs and report status (
dev.azure.com,*.dev.azure.com) - Download the Azure DevOps agent software (
download.agent.dev.azure.com) - Authenticate against Microsoft Entra ID (
login.microsoftonline.com) - Access Azure Storage for artifacts, logs, and worker queue communication (
*.blob.core.windows.net,*.queue.core.windows.net) - Download packages and dependencies during pipeline runs (
packages.microsoft.com) - Load Azure DevOps UI assets (
*.vsassets.io,*.visualstudio.com)
If these endpoints are not allowed, the agents will either fail to come online or enter an allocated state without being able to execute pipelines.
Firewall Application Rule Collection
Add the following application rule collection to your Azure Firewall:
| Setting | Value |
|---|---|
| Source | Your subnet address range delegated to Microsoft.DevOpsInfrastructure/pools |
| Protocol | HTTPS (443) |
Target FQDNs
| FQDN | Purpose |
|---|---|
*.prod.manageddevops.microsoft.com | Managed DevOps Pools service communication |
rmprodbuilds.azureedge.net | Worker binaries and startup scripts |
*.queue.core.windows.net | Worker queue communication |
download.agent.dev.azure.com | Azure DevOps agent download |
dev.azure.com | Azure DevOps communication |
*.dev.azure.com | Azure DevOps communication (subdomains) |
*.vsassets.io | Azure DevOps static assets |
*.vstmrblob.vsassets.io | Azure DevOps test management blobs |
*.visualstudio.com | Azure DevOps legacy endpoints |
*.blob.core.windows.net | Azure Blob Storage (artifacts, logs) |
packages.microsoft.com | Microsoft package repository |
login.microsoftonline.com | Microsoft Entra ID authentication |
Note: If you are running Ubuntu-based agents, you also may need to allow
azure.archive.ubuntu.com(HTTP/80) for apt package installation during agent provisioning.
Tip: Consider enabling service endpoints (e.g.,
Microsoft.Storage) on the delegated subnet to route Azure Storage traffic directly over the Azure backbone, reducing the number of FQDNs you need to allow through the firewall.
Additional Considerations
- The subnet must be delegated to
Microsoft.DevOpsInfrastructure/poolsand sized to accommodate the maximum pool size plus the five reserved Azure IP addresses. - The
DevOpsInfrastructureservice principal needs Reader and Network Contributor roles on the virtual network. - If you experience issues beyond the endpoints listed above, consult the full Azure DevOps allowed IP addresses and domain URLs.