[Updated] New IP address ranges with Service Tags for Azure DevOps Services

Justin Chung

Justin

Please see the Rollout Update section below for important information about brownout status and schedule change for East US 2 region.

Azure DevOps Services will support Service Tags by the end of CY2020. Azure Service Tags are a convenient way for customers to manage their networking configuration to allow traffic from specific Azure services. Once a Service Tag has been set up for Azure DevOps Services, customers can easily allow access by adding the tag name azuredevops to their NSGs or firewalls either through the portal or programmatically. 

In preparation for this enhancement, our IP address space will be changing for outbound traffic from Azure DevOps Services to customers’ on-prem systems, effective October 5 2020. If you’re currently using firewall rules to allow traffic from Azure DevOps Services, please be sure to update these rules to account for our new IP ranges by that deadline. We will be conducting a brownout test from September 9, 2020 to September 15, 2020 as indicated below. Please note the change from originally announced date of September 8, 2020 to September 9, 2020. While most of the features will work, the below four scenarios will be impacted by the brownout test due to IP address range change. If you do not want any impact for these four scenarios during this period, please add the additional IP address ranges below for your region to your firewall rules as soon as possible.

  • Azure DevOps Services connecting to endpoints for Service Hooks,
  • Azure DevOps Services connecting to SQL server in customer’s on-prem systems for Data Import,
  • Azure Pipelines connecting to on-prem source code repositories such as GitHub Enterprise or BitBucket Server,
  • Azure DevOps Services Audit Streaming connecting to on-prem or cloud-based Splunk.
  • The Service Tag does not apply to Microsoft Hosted Agents. Customers are still required to allow the entire geography for the Microsoft Hosted Agents.  For inbound traffic from customers’ on-prem systems to Azure DevOps Services, customers can continue to follow the guidelines here.

    Determining impact

    To help you determine whether this change impacts your organization, we are building an Azure DevOps IP Check Tool. The IP Check Tool is used to validate inbound and outbound connectivity between Azure DevOps Services and customers’ on-prem systems. Please use this tool prior to the brownout and after to validate your connectivity.

    For inbound testing from your on-prem system to Azure DevOps Services, please make sure that the browser running the test is connected to your target network. We will attempt to contact Azure DevOps Services and report any errors we see.

    For outbound testing from Azure DevOps Services to your on-prem systems, please provide us with a REST URL you expect our services to call. We will attempt to call the URL from each of our service regions. Any HTTP status code between 200 and 499 will be considered a successful connection. All 5xx status codes will be reported as an error.

    If you are having issues, please post an update on this open developer community item.

    IP Address Changes

    To react to the changes in our IPv4 address range, users should ensure dev.azure.com is open and update their allowed IPs to include the following IPv4 addresses (based on your region). You will also be able to use the service tag name azuredevops to allow all IP ranges below but the tag will not  be available until November 2020. IPv6 is not supported at this time.

    IP Address Ranges

    RegionIP address ranges
    brazilsouth191.235.226.0/24
    asiaeast20.189.107.0/24
    uscentral20.37.158.0/23
    australiaeast20.37.194.0/24
    indiasouth20.41.194.0/24
    useast220.41.6.0/23
    uswest220.42.134.0/23
    australiasoutheast20.42.226.0/24
    useast20.42.5.0/24
    ussouth40.119.10.0/24
    europewest40.74.28.0/23
    usnorth40.80.187.0/24
    uswest40.82.252.0/24
    uksouth51.104.26.0/24
    uswestcentral52.150.138.0/24
    canadacentral52.228.82.0/24

    Azure DevOps documentation will be updated with the new IP address ranges here. 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 brownout tests to identify organizations that may be impacted by these routing changes. We will conduct our first test on September 9, 2020 and complete by September 15, 2020. Please note the change from originally announced date of September 8, 2020 to September 9, 2020 and also note the change for East US 2 region to September 16,2020 at 07:00 EDT (11:00 UTC). See below for the brownout schedule. The brownout test will take 2 hours.

    Rollout update

    Azure DevOps Services started the network configuration change for the East US 2 region on September 9, 2020 at 10:00 EDT (14:00 UTC) and noticed a spike of customer impacting failures during one of the deployments. The spike lasted for 1 to 3 minutes for web traffic and customers may have noticed a message with “TF400898: An Internal Error Occurred” in their browser. The brownout in the East US 2 region was halted but we completed the brownout in the Central Canada region with success. We will continue with the brownout in the South India and West US 2 regions on September 10, 2020. We have updated the brownout schedule for the East US 2 region to September 16, 2020 at 07:00 EDT (11:00 UTC).

    Brownouts in chronological order

    UTC Date TimeRegionLocal Date Time
    2020-09-09 19:00canadacentral2020-09-09 15:00 EDT
    2020-09-10 11:00indiasouth2020-09-10 16:30 IST
    2020-09-10 17:00uswest22020-09-10 10:00 PDT
    2020-09-11 12:00uksouth2020-09-11 13:00 BST
    2020-09-11 18:00brazilsouth2020-09-11 15:00 BRT
    2020-09-14 13:00europewest2020-09-14 15:00 CEST
    2020-09-15 00:00asiaeast2020-09-15 08:00 HKT
    2020-09-15 14:00uscentral2020-09-15 09:00 CDT
    2020-09-15 22:00australiaeast2020-09-16 08:00 AEST
    2020-09-16 11:00useast22020-09-16 07:00 EDT

    In the event we are running these tests and use cases such as service hooks, data import, and pipelines are not working during this period of time, please navigate to the status page and check that there aren’t any ongoing incidents and update your IP address allow list. We are targeting November, 2020 to make Service Tags generally available for Azure DevOps.

    Reporting Issues

    If you experience any issues with accessing your Azure DevOps organization after updating your IP allow list, please post an update on this open developer community item.

    59 comments

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

    • Padmanaban Anandan
      Padmanaban Anandan

      Could we stop promoting new racially insensitive terms?
      For starters, here are well understood alternatives.

      1. Blacklist => Deny list
      2. Whitelist => Allow list

      So, Brownout => ?

      • Avatar
        Mateusz Fanslau

        From Wikipedia: ‘Brownout in software engineering is a technique to increase the robustness of an application to computing capacity shortage.’

        Now you know, you’re welcome 😀

      • Avatar
        McGrady, Ian

        I see your point, and I agree. Service Pause is a bit sterile, hopefully someone has something better. I think industry can understand that there are service downages at some point. I kind of like “Downage” now that I’ve written it: “Down” meaning lowered, “-age” meaning process. It’s less clunky than “lowerage”. I would offer those two, Service Pause and Downage, hoping for something better.

      • Avatar
        Nat Ringham

        Hi Padmanaban,

        I can not comment on the racial sensitivity aspect, but “brownout” is a concept familiar at least in Australia for when there are issues with the electricity; think about old fashion yellow-ish light globes dimming but not going out such that the room appears brown for a moment, that’s an electricity “brown out” (compare to “blackout”, where the room goes black because the lights go completely out).

        I believe the point is to convey that the service will be available during this time, but will be diminished in performance / service

      • alain pilon
        alain pilon

        There are no references to white/black list in this article. Brownout has nothing to do with skin color and it is a perfect term to describe the situation.

        • Padmanaban Anandan
          Padmanaban Anandan

          Exactly, we’re not talking this article specifically for other terms. But, I have concerns when a two line summary of this article with ‘Brownout’ makes into a hyperlink headline in every organization that uses azure private cloud and ignorantly promotes terms. I wouldn’t buy your perfectly used terminology, when again the point made here is, use simpler alternatives that doesn’t make one to lookup Wikipedia, for instance.

          • Bryan Marks
            Bryan Marks

            Are you suggesting that we should not use colors for anything other than denoting skin color any longer? That would be terribly limiting on use of colors, wouldn’t it? Instead of changing the world and how it uses colors to denote technology conditions, it’s easier to change your heart and see that intentions and use are not denoting politics, skin colors etc. and we are all just engineers, technicians coming together because Microsoft is changing things again ensuring job security for all of us.

            • Padmanaban Anandan
              Padmanaban Anandan

              I’m only suggesting use of simpler alternatives, that are easy to understand without having to lookup. Change starts with acknowledging and being open to feedback and agreeing to disagree. I definitely sense your “agreeing to disagree”, but to me, your quick interpretation of what is not said is scary and is a contributing factor to “Tech lacking desired diversity” in all levels.

          • Avatar
            Fábio Milheiro

            You are the one seeing any negative connotation in blacklisting and whitelisting. There’s no racism there.

            Would you like to change the religion of other people? Tell brides not to use white and widows not to use black anymore because it offends you.

            I am offended with your remarks as they restrict people’s freedoms to use colour codes that actually precede the moment in history in which some religions actually became aware of people with different colours.

            And when something burns, it changes its colour to black. Are you going to have a word with God too? Do good for the people around you. That will be remarkable. Not this!

            You are not helping to solve any problems. Just creating more! And further advancing the marxista agenda of the black lives matter movement which seeks to further create division based on colour. We’re all people. The black lives matter and so do the yellow, the white, the caramels and the reds.

        • Avatar
          Louis Lecailliez

          Brownout has nothing to do with skin color

          Yep, exactly like white and black lists have nothing to do with skin color either. The tech industry opened that madness Pandora’s box, so it’s fair to push the logic further.

          • Padmanaban Anandan
            Padmanaban Anandan

            The basic premise is use simpler alternatives . Think about an African American in technology in his first day of training under you as a technical supervisor and wants to know what blacklisting means? Now if I were you, I would rather promote Deny list and I guarantee you that the question wouldn’t have been asked.

      • Avatar
        Norm Higgs

        Padmanaban Anandan, Gosh, you must be right. I believe that we should eliminate “Any” color description from “All” technical terminology. We could just simply alter every know software package, Book Series, Hardware component, etc., then the world would be a safer place . . . Oh, I almost forgot, that should also include anything that is color coded, so telecommunications, electronic patch-boards, PCB’s, cable systems, etc. could also just simply make that shift, then the world would be a safer place.

        Truely, the world would be a better place if cultural stereo-type perspectives could be replaced with an ‘Open Perspective’ and if we also allow all perspectives to blend, including those differences (outside of just words) that give each of us the brevity to be ourselves . . . without judging others (using words).

        Having said that, I find both ‘Blacklist’ & ‘Whitelist’, as well as ‘Deny List’ & ‘Allow List’ acceptable either way. ‘Brownout’, as stated in the comments, is also an acceptable term.

      • Avatar
        Anne Speck

        Thanks for raising this. I don’t think we have a good one word replacement in the language yet but we’ll get there. I went with “intermittent availability” on our team calendar.

    • Avatar
      Ojas Panwar

      I tried to use the Azure DevOps IP check tool, but I get the following error after entering any IP address: “This operation is not supported for a relative URI.”. Can you please verify that the tool is working as expected?

    • Avatar
      Vladik Marinovski
      1. I don’t understand why it needs configuration and why not any Azure DevOps server can access any app service for instance. Who would want to block this traffic?
      2. Why didn’t you just do what you did on the SQL Server firewall access rules with the “Allow access for all Azure services” or whatever you have there?
      3. Why didn’t you allow a config on the Azure DevOps release that opens whatever needed to deploy on an app service for instance?
      4. It’s not clear from the post if my already configured Azure DevOps pipeline and release can benefit from this change so maybe you can email DevOps people that can benefit from the change.
      5. Maybe you can also add a security checkup that lets me know I can restrict IP access to my Azure app service to a list of addresses that accessed to the service in the past month or something…
      • Avatar
        Vladik Marinovski
        1. If I configured a whole pipeline abd release for an app service, there is no way I WANT to restrict IP access from Microsoft hosted Azure DevOps project or organization (that BTW works with the same subscription and AAD) to my app service.
          You could’ve solve this issue long time ago.
          Having said that, you keep making progress and the tools are reliable.
          Please make our lives easier and help making the flow simpler.
      • Justin Chung
        Justin ChungMicrosoft employee

        Kelsey Barrett,

        We are not shutting down the entire region. We are only shutting down part of the Azure DevOps Services that will impact the following scenarios:

        -Azure DevOps Services connecting to endpoints for Service Hooks,
        -Azure DevOps Services connecting to SQL server in customer’s on-prem systems for Data Import,
        -Azure Pipelines connecting to on-prem source code repositories such as GitHub Enterprise or BitBucket Server.

        • Avatar
          Matt

          Are you actually shutting anything off during the test windows?

          From the article, it sounded like you were browning out access to certain things from the old ip block.

          If someone isn’t using Azure DevOps ipv4 block to open up access inbound or outbound, will anything actually be off during these tests? (i.e. will service still be available inbound/outbound during the test window, just from the new range, temporarily?)

          Also, the test page you link… Would be nice to support just inbound (to devops) testing, I’m sure there are customers that don’t have rules opening up their network, but test page still requires a URL to be filled in.

    • Avatar
      Justin Holbrook

      Would this affect deployment groups? They utilize an AzDO agent installed on on-prem infrastructure. AzDO must reach out to the agent to initiate a deployment correct?

        • Avatar
          S, Dhanalakshmi

          We are using self hosted agents for build and release pipelines where we have configured build agents using PAT. We have not configured any Firewall or Azure IP Address for inbound or outbound manually in build and release servers. Through Internet access the builds artifacts are deploying in release servers.

          Please let us know whether any impact for such build and deployments.

          • Avatar
            Gabor Bernics

            You will be not affected in this use case, the on-prem Agents are using the DNS name of the ADO endpoint.

            This is NOT official answer from Microsoft. 🙂

    • Avatar
      Dan Jerghiuta

      The article only mentions “outbound connections”. How about self-hosted agents that need to access Azure DevOps Services to pull pending jobs, code and artifacts? Do we need to whitelist the same new IP blocks listed in this article? Do we keep the current 4 CIDR blocks?

    • Avatar
      Ankit Gupta

      Hi Team,

      Date for AutraliaEast has been changed again?

      It was 2020-09-09 08:00AM AEST but now its 2020-09-16 08:00 AEST

      Can you please confirm is there any further changes that need to be made to plan ? We use Azure DevOps across the organization.

      And just to confirm there will be no impact on ADO Boards and ADO Test Plans?

      Thanks

        • Avatar
          Ankit Gupta

          Thanks for response, and apologies in advance to ask this again. Just to confirm there will be no impact on Code Reposteries as well, Our developers can continue using Azure DevOps Repos as it is and we do expect some impact for Azure Pipelines

          Once again thanks in advance for all support.

    • Avatar
      Siripalli, Gangadhara TPC

      We are using Deployment Groups and we installed self hosted agents are installed on premises server, as mentioned in the article brownout test for UK south is from September 9, 2020 to September 15, 2020 (12:00 to 13:00 BST), will this effect our release pipelines to move/install the artifacts?

      My scenario is self hosted agent installed on premises server will pull the code from azure build artifact store and install the components, could you please let me know this service having any downtime on the brownout test.