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
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.
- 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)
- 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.
The change above caused the Outgoing IPs to change to the below…
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.
- You can use the outgoing IP of your webapp to supply to firewall information based on IP to 3rd party providers.
- 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.
- Scale Out/In including auto-scale is not subject for causing changes for outgoing IP.
- In case of regional disasters I wouldn’t feel 100% confident of getting the same outgoing IP.
- 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.
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.