Hi!
I am looking into opening our firewall so the Octopus build step in VSTS can create a release in our on-premise Octopus server. Does anybody know if it is possible to obtain the ip-range used by VSTS so we can limit the incoming firewall opening to this range?
Thanks!
Marius
VSTS of course meaning Visual Studio Team Service, formerly known as Visual Studio Online and before that Team Foundation Services (I think). But I guess you understood that 
Hi Marius,
From having our chat with Damian, our resident TFS expert, it sounds like the correct answer to your question hasn’t been completely confirmed yet. If you are using an on-premises build agent then the actual connection to Octopus will happen from whatever machine that the build agent is running on. If you are using a hosted service then that will obviously be a little more difficult as it will come from outside your network.
Based on a previous post that referred to using the VSO load testing functionality then this was (at the time of the post in July 2014) from the Azure US East datacenter. The list of IP Addresses for these data centres can be downloaded via a link in that thread. This is likely to have changed since then so we will be posting that question to some of the MS people and will let you know as soon as we hear back from them.
Thanks for dropping us a line and we will keep you updated when we get more information back.
Cheers
Robert
Hi Marius,
To summarise the response from the Microsoft team responsible - the pool of IPs for hosted build agents isn’t consistent. They currently have a number of agent pools servicing each “scale unit” (essentially a VSTS hosting location), but the architecture is likely to change soon so multiple pools can service multiple scale units.
Ultimately, there’s likely to be a very big range and it’s fairly likely to change as the architecture on the Microsoft side changes.
If you can let us know which “scale unit” you’re in (the options are Australia East, South Central US, and West Europe) they can give me the current IP range, but clearly it’s not a long term solution.
A better alternative would be to run your own on-premises build agent. They’re very easy to set up and once credentials have been set up so it can talk to VSTS, all operations happen locally. For example, if your Octopus server was on the same machine, you could even use localhost for your Octopus URL. Of course this may just move the problem - you may want to lock down the IPs that the build agent can contact, and those change as well.
I hope this helps a bit!
Damian
Thank you both for your replies. I appreciate your understanding of the issue.
The solution to have an on-prem build agent could actually work. It seems that the build agents does not require an incoming opening in the firewall which makes everything much easier when dealing with corporate IT infrastructure and security guys 
On a related note; we moved into to cloud to get rid of the dependencies on on-prem it infrastructure because they are not able to deliver new VM’s quite as fast as Azure does it But one local VM for this specific purpose is probably doable.
Marius
Just writing this to let you (and anybody else finding this thread later on) know the conclusion.
After thinking about your answers once more I realized that I had been thinking that the Octopus step was running on the build controller and not on the build agent. Since we are NOT using hosted build, but have our own agents on Azure VM’s we have control over these VM’s and can assign them fixed ip (or setup a VPN connection to our internal network). With fixed ip (or VPN) this will work fine.
Hi Mariwing,
Thanks for the update. Hopefully your results come in handy for anyone else with the same problems.
Cheers,
Robert