Azure Web Apps – Outgoing IP Question/Answer

Posted in Azure Web Apps, Infrastructure, IP configuration

A colleague of mine called me the other day and had a conceptual networking issue with an Azure WebApp and their use case. The webapp was going to call an external 3rd party API which was protected by firewall rules based on IP-address. He needed to supply the 3rd party product supplier with the correct IPs of his callers IP address. He was however uncertain on how this could be done. I had no immediate answer to this and we started discussing.

Some ideas discussed and dropped was:

  • Could one set a static IP on the WebApp? – No that would not work as 1) the instances would have different IPs anyway and by setting the internal IP on a specific instance which would not help you at all because you are likely to use more than one instance. I am also not sure that a webapp would be able to use such an internal IP for outgoing calls anyway. 2) You would like to set it for all instances on the webapp but the one thing holding your instances together is the loadbalancer – but outgoing calls will not go through any load balancer. 3) Using static IPs for WebApp instances (or most PaaS services) does not make sense due to the abstraction of servers in the PaaS offering.
  • Could one set up a VM with a reserved IP and make all calls through that VM? Yes that might work for this scenario to produce a known IP for the 3rd party API. But it had some disadvantages with 1) having to pay for an extra VM (or at least two for High Availability) as well as 2) it did not fit very well as the web app was supposed to get SAML tokens from the api and to route that through an extra server seemed unsuitable.

So whats the answer then?

The real answer is that there is no full proof way to do this – the solution presented below is depending on a couple of factors to keep the IP permanently and there are things you can do to get another IP if you are not aware of the inner mechanics. On the other hand as long as you are aware of how it works you can in most cases avoid or mitigate the issue.

The most important part of the solution is that each web app has a set of outbound IP addresses. These are the ones that you should use and supply in the firewall rules of the firewall at the 3rd party supplier. You find these in the WebApp in the portal

WebApp Outgoing IP
How to find the Outgoing IP for a WebApp

Part answer: So copy the IPs and send them to the API provider.

So whats the problem then?

So far everything seems good but there are some catches.

  1. The IPs are not yours alone. These ports are also used by other WebApps (I mention this more below and the references will explain it even better)
  2. While this will affect all your instances of your webapp, it MIGHT! not stick if you scale-up/down the application.It is important to clarify this – so just to repeat: scale out/in will be fine (which you will do most…often with autoscaling rules) – but scale up/down might cause this to change. So if you change the app service plan any change as the below picture shows you will possibly get new outgoing IPs.
Beware if changing scale
Beware if changing scale

The change above caused the Outgoing IPs to change to the below…

Scale Changed = IP Changed
Scale Changed = IP Changed (this time)

So is this a big deal? Not unless you change the scale often. And if and when you do – make sure the api supplier is ready to instantly change the firewall settings again to the new address (should it change).

But I just tried and the IP remained when scaling up/down!

After the test above I tried changing the scale again a number of times and in all these scenarios I ended up with the same outgoing IPs. So I am assuming that I was allocated to another scale unit the first time but subsequent calls put me in the same one.

Final conclusion:

  1. You can use the outgoing IP of your webapp to supply to firewall information based on IP to 3rd party providers.
  2. Be aware that changing the service plan MIGHT change the outgoing IPs. So have any such providers ready to change the configuration on their end if you need to change the service plan.
  3. Scale Out/In including auto-scale is not subject for causing changes for outgoing IP.
  4. In case of regional disasters I wouldn’t feel 100% confident of getting the same outgoing IP.
  5. I would recommend some custom logging to Application Insights and related alerts when you get failures with the 3rs party supplier apis and the first thing you should look at is whether the outgoing IP addresses are still the same.

References

Previously the list of all possible IPs for different was listed on this URL. If you are looking for more details about this topic I suggest you head over there.

Update 2017-07-03

In the comments below an interesting thread started regarding x.x.x.0 IP address that was needed to get the described scenario to work. I have done my own little investigation about this and you can read about the outcome here.

Published by xenomorphpeter

23 thoughts on “Azure Web Apps – Outgoing IP Question/Answer”

    1. Not in this case this would not be sufficient. The problem was that we needed to know the IP that was used from our web app (i.e. when it called) to the external web service which was protected IP address by firewall that needed to be opened for our caller. In other words the external service had to enter the allowed IPs and we had to supply it. Changing the inbound address would not affect the outgoing address from our web app. And as far as I know you still cannot set the OUTGOING ip address on a web app.

      Like

      Reply

    2. NOt possible, but yes you can configure CNAME with DNS provider..and Register it with Azure APP > Custom Domain Section. It works fine

      Like

      Reply

  2. An extra problem to this is it seems that there are also .0 ip numbers that are also used. So if you give the 4 ips in the azure properties to a 3rd party you may also have to give them the x.x.x.0 ones as well or you will get errors connecting returned in your logs. And those .0 ips are definately shared with other azure users.

    Like

    Reply

    1. Interesting comment. I have not noticed this myself or heard anything suggesting that before. It would be very interesting to get some more information about this. Like logs, what type of communication you call etc. But either way (x.x.x.0 IP) or not your 3rd party supplier will open firewall to more than your app service so one should ideally combine the firewall rules with secure communication and authorization/authentication also to increase security.

      Like

      Reply

    2. Jon L, have you found a solution to the connection issues? We’re having similar problems with a x.x.x.0 outbound address in Azure.

      Like

      Reply

  3. Would it make sense to deploy the app service within an App Service Environment and provide the public IP of the ASE?

    Like

    Reply

    1. Ase is definately an option to solve the problem, but its expensive. We are considering the big picture and being able to host alot of sites/apis etc, and move away from our current hosting provider and service fabric will be for us the cheaper option given the number of sites we need to host.

      Like

      Reply

  4. I have a problem with one app service that is calling an external service that filters the incoming IP addresses. I did as you said in this post, but with no luck. We added the five outbound IP’s on the firewall, but we cannot pass through. Looks like there are some “other IP´s” and we have been unable to find the good ones. Any thoughts?

    Like

    Reply

    1. I don’t have a quick answer on this one. Some readers previously reported that they needed to add the x.x.x.0 IP address in addition to the ones in the portal. All documentation still seems to point to that you only need the outbound IP for your scenario. But now the number of reports on this issue makes me curious so I need to verify this again. Unfortunately I am on a tight deadline in a project that keeps me busy day and night for a couple of weeks more so I may not be able to test this immediately.

      Like

      Reply
  6. Pingback: Web Apps: Outgoing IPs – follow-up post – Peter in the Azure sky

  7. Thanks, for that. We did a bit more digging and it would appear that the IP addresses are consistent across a resource group.

    We tried changing the size of service plans that were either singleton in a resource group and one among others in a resource group; but in both cases the IP addresses remained the same.
    Were wondering if the IP addresses would stay the same if there were other service plans in the resource group but change if there was only 1 in the resource Group.

    Powershell script to get the details about the outbound IP addresss per web app.

    get-AzureRmAppServicePlan | % {$sku = $_.Sku.Name; $name = $_.Name; get-AzureRmWebApp -AppServicePlan $_} | % {$_ | select @{Name=”ServicePlan”; Expression={$name}}, @{Name=”Sku”; Expression={$sku}}, SiteName, OutboundIpAddresses} | ogv

    Like

    Reply

    1. You state: The IPs are not yours alone. These ports are also used by other WebApps (I mention this more below and the references will explain it even better)
      I did not find any explanation or references on this, can you provide some insight here ?

      Like

      Reply

      1. I am not an infrastructure expert and I can’t find any docs either stating that a certain technology is used for this – so I will answer this a bit speculative. My beleif is that the outgoing IP addresses are likely the ip address of some kind of gateway (like a router, internet gateway or similar). I came across Source Network Address Translation (SNAT) Gateways when reading about Azure VMs and this may be used also for web apps and allows traffic from a private network to go out to the internet. The web app instances themselves are using private IP ranges and needs to make calls with a public facing IP address (which are these IP Addresses) to be able to run the TCPIP protocol (think handshakes and receive responses). Multiple App services share the same gateway/router and are therefor not yours alone – just like your computer does not have monopoly on your web router and multiple computers are connected through the same network topology and use the same routing.

        If any infrasctrutural/network experts are reading this, then please give your thoughts on this here in the comments.

        Like

  8. Pingback: Deploy Sitecore on Microsoft Azure with MongoDB Atlas - Data Science Tidings
  9. Pingback: Sitecore Tutorial: Deploy Sitecore on Azure & MongoDB Atlas | MySQL Unleashed

    1. Interesting and thanks for the input jonlanceley. Without knowing your exact scenario you might be on to something here. Found the below text at https://blogs.msdn.microsoft.com/azureapimgmt-changelog/2014/09/10/sep-10-2014/

      “Static IP address. You can now see your API Management service’s static IP address on the service dashboard page in the Azure management portal. The address could be used, for example, in configuring firewall rules allowing API Management proxy to access an on-premises backend service. It is guaranteed to be constant for the duration of the service lifetime.”

      Relection: I haven’t yet personally verified that this works for all scenarios and note that in many scenarios you could probably live with the semi-fixed outgoing ip of your web app but it is good to know that there are some workarounds available for the scenario where you absolutely need “fixed” IP address for outgoing calls. What bothers me a bit with the solution is that it seems a bit wasteful to use API management only as a pure reverse proxy to call external services as (in this scenario). It will also add an additional cost on the bill without adding any more features to the solution (except for the more static IPs then).

      Like

      Reply

Leave a comment