Azure DevOps Services is currently investing in enhancing its routing structure. This change is designed to increase service availability and decrease service latency for many users. As a result of this enhancement, our IP address space will be changing. If you’re currently using firewall rules to allow traffic to Azure DevOps Services, please be sure to update these rules to account for our new IP ranges. These IP address changes go into full effect July 22, 2019. Â
Determining impact
To help you determine whether this change impacts your organization, we are building an Azure DevOps IP check page. When you navigate to the page, we’ll run a sample request against our new routing structure. If the request fails you’ll get a red “X” in the response. To resolve, you’ll need to update your IP address whitelist. This feature currently isn’t implemented, however it is expected to be in place within the upcoming week.
IP address whitelist changes
To react to the changes in our IP address space, users should ensure dev.azure.com
is open and update their whitelisted IPs to include the following IP addresses (based on your IP version). If you are currently whitelisting the 13.107.6.183
and 13.107.9.183
IP addresses, please leave these in place. You do not need to remove them. Â
IPv4 ranges
13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
IPv6 ranges
2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
A complete list of Azure DevOps Services guidelines for configuring firewalls and proxy servers can be found in the Allow IP addresses and URLs to the allow list document.
Rollout plan
Over the course of the next few weeks, we will conduct a series of tests to identify organizations that may be impacted by these routing changes. We will conduct our first test June 17th from 1300 – 1400 UTC. We will conduct our second test June 24th from 1300-1700 UTC. Our third test will be conducted on June 26th from 00 – 200 UTC. A final test will be conducted on July 16th from 1300-1700 UTC. During these tests, we will temporarily update DNS to flush out any unknown dependencies on the current IP address. After the test period is over, we will revert DNS to its original state. If you are unable to access your organization during this period of time, please navigate to the status page and check that there aren’t any ongoing incidents. In the event we are running these tests and you’re unable to access your Azure DevOps organization, please update your IP address whitelist. Â
Schedule changes
Our roll out plan has changed a few times since the initial release of this blog post. During our tests, we uncovered some issues related to how our IP readiness checker handles IPv6 connections. Many users reported receiving a successful health message when they visited the IP check page, however they experienced connectivity issues during our test windows. As a result of these findings we’ve enhanced our IP check page to behave in a more sophisticated manner and we encourage all users to revisit the IP check page to ensure their organization is not impacted by the upcoming changes in our routing structure. Thank you to everyone who has reported issues during this test period. This has been a great opportunity to learn from you all along the way. Please continue to reach out and report any issues you encounter. We want to ensure this transition is seamless.
Reporting Issues
If you experience any issues with accessing your Azure DevOps organization after updating your IP whitelist, please post an update on this open developer community item. Â
Why my pipeline is not running in my organizations environment when I try to connect to SPO. Is it because MFA is enabled and the IP address from where DevOps Hosted Agent is running, is being blocked by my organization policy?
Hi Whitney is a there command line equivalent of the DevOps IP check page which we could run on Linux VMs?
To save everyone else the pain of the troubleshooting that I have just gone through, I will say that the list of whitelisted IPs above is not necessarily the only IPs that you will need to whitelist if you are doing integrations with Azure DevOps (in our case, with Bitbucket).
I worked with MS support and we reached an impasse for about 2 days. At somepoint late in day 2, MS support informed me that I should whitelist another single IP (13.86.33.223 in our case). This IP is stated to be the public IP that is linked to the specific...
Hello,
I also added 13.74.59.181 IP. But finally we accepted to add azure cloud Tag and works for us. That means that AzureDevops connect to our own artifact box.
Whitney,
We’ve also whitelisted the ip ranges, however, still having a slight issue with our Deployment Agents.
Our Deployment agents cannot download the artifacts fully. It seems like it gets a few parts, but then gets cancelled as it’s trying to access https://8xbvsblobprodcus382.blob.core.windows.net.
Our network guy says this resolves to 13.67.155.x.
Does this subnet also need to be whitelisted?
Hi- I assume these are the incoming ip’s for DevOps services. Is there any chance of listing your outgoing IP’s for hosted agent pools?
Hi Dipak,
Yes, these IP changes only affect inbound traffic to Azure DevOps. You can find a list of our outgoing IP’s for hosted agent pools in this doc underneath the “Agent IP Ranges” section. – https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops.
Whitney
Hi Whitney,
Are the following new IP addresses hosting new AZDO service, or are they superseding some existing services?
IPv4 ranges
13.107.6.0/24
13.107.9.0/24
13.107.42.0/24
13.107.43.0/24
IPv6 ranges
2620:1ec:4::/48
2620:1ec:a92::/48
2620:1ec:21::/48
2620:1ec:22::/48
Regards,
David
You can use the following links to convert the test/live times to your local timezone & use as a countdown.
Azure DevOps – IP Changes – First test (1 hour)https://aka.ms/azure_devops_ipchange/test1/yourtimezonehttps://aka.ms/azure_devops_ipchange/test1/countdown
Azure DevOps – IP Changes – Second test (4 hours)https://aka.ms/azure_devops_ipchange/test2/yourtimezonehttps://aka.ms/azure_devops_ipchange/test2/countdown
Azure DevOps – IP Changes – Livehttps://aka.ms/azure_devops_ipchange/live/yourtimezonehttps://aka.ms/azure_devops_ipchange/live/countdown
Hi Whitney,
We whitelist the URLs in “How do I configure the agent to bypass a web proxy and connect to Azure Pipelines?” section https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops#im-running-a-firewall-and-my-code-is-in-azure-repos-what-urls-does-the-agent-need-to-communicate-with
Is there any action item for us?
Thanks, Dennis
I have the same question!
Fyi Guys, even though we whitelist the domain URLs, when we run the AzDO IP check page on our on-premise release agents. we got this message:
“There's a problem with your IP firewall restrictions.
We are currently investing in enhancing the network and its routing structure for Azure DevOps in order to increase service availability and decrease service latency for many users. As a result of this enhancement, our IP address space will be changing. If you're currently using firewall rules to allow traffic to Azure DevOps, please be sure to update these rules to account for our new...
Hi Dennis,
Do you have any domain based rules configured on your on-premises release agents? Do you only have a rule setup for dev.azure.com?
Whitney
Hi Steve,
If you whitelisted by domain name, then you don’t have to make any changes.
Whitney,
It looks like my comment/question got removed for some reason. Does this also mean that the Service Tag “AzureCloud” will also be updated automatically with the new ranges?
I hope that likewise, use of the AzureCloud tag in Azure NSGs will be automatically updated?