New IP firewall rules for Azure DevOps Services

Whitney

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.  

16 comments

Comments are closed. Login to edit/delete your existing comments

        • Ryan Adler

          I hope that likewise, use of the AzureCloud tag in Azure NSGs will be automatically updated?

        • Ryan Adler

          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?

      • Dennis Hsu

        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 IP ranges. These IP address changes go into full effect Monday, 1 July 2019.
         
        Looks like there’s a problem with your IP firewall restrictions. Please ensure you’ve whitelisted the IP ranges below. For domain-based firewalls, please ensure that dev.azure.com and *.dev.azure.com are allowed. Learn more about our IP firewall rules here.
         
        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 “Better run the AzDO IP check page again.
        Thanks,
        Dennis

        • Whitney JenkinsMicrosoft employee

          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

  • Grant HollidayMicrosoft employee

    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

  • Islibadm Islibadm

    Hi Whitney,
    Are the following new IP addresses hosting new AZDO service, or are they superseding some existing services?
    IPv4 ranges13.107.6.0/2413.107.9.0/2413.107.42.0/2413.107.43.0/24
    IPv6 ranges2620:1ec:4::/482620:1ec:a92::/482620:1ec:21::/482620:1ec:22::/48
    Regards,
    David

  • Dipak Mistry

    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?

  • Wong, Richard

    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?

  • Pekor, Marc

    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 region where our Azure DevOps org resides.  It’s working now, and I sincerely hope that this isn’t an IP that changes from time to time….but at least I will now know what to do if it does.  

    • Raul Sampedro

      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.

  • Simon Day

    Hi Whitney is a there command line equivalent of the DevOps IP check page which we could run on Linux VMs?

  • Sourav Kar

    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?