I'm running an azure function which gets data from an API and stores it in a blob. Everything worked fine and stopped working out of nowhere. We then got in contact with our provider and they told us they made some changes in their API. After we made the necessary changes in our code,started getting an IP denied error from their part. I then searched and found the possible outbound IP addresses for the Azure Function. They whitelisted the whole list and still
They aren't getting any requests from those IP's,
We are not able to access that data for the same reason our IP is denied.
We've been running the code in a local machine and it works completely fine, but this is just a temporary fix and we want to keep everything in the cloud.
I've been stuck with this for about 3 weeks. I've looked into different solutions and I found about Azure Logic Apps and Azure Service Fabric.
Is there something missing in my Azure Function that isn't allowing me to make requests to the API? Am I using the wrong outbound IP? Also, if I use any of the other two services, will I encounter with the same problem? I did some research on them and I think they both also use multiple outbound IP addresses, so I'm worried I'll get the same problem.
Using NAT gateway you can specify a static IP address for outbound traffic, your function app need to be attached on a subnet which is not available for consumption plan.
Here is where you should be getting the Azure IP address ranges from. Azure Functions originate from the App Service Plan ranges. Note that this is updated weekly, things change, but not too often. Your provider will need to open all the relevant ranges and keep up to date with any changes. If your solution is not mission critical with a high SLA, then having your service provider open the relevant ranges and deal with failures, updating the ranges on an ad-hoc basis should be fine.
Secondly, if you have a good relationship with the provider, ask them to check the firewall, they will be able to give you an indication of the IP's getting blocked by checking the firewall logs. This will help you find the right range.
The only guaranteed way to solve this in a mission critical solution is to run your Azure Functions from an dedicated app service plan with a dedicated IP address. This is an expensive option but will be the most robust.
Additional helpful information here on how App Services works with IPs can be found here.
How do I find the following for my azure web app. I am on a premium service. and I am unsure of where to look.
Source FQDN
Source IP
Port
Protocol
Service
Is the flow bi-directional?
Thanks in advance.
I'm not entirely sure what your question is asking, but I'll provide some info based on some assumptions of what you're asking for:
FQDN: When you created your app service, you gave it a name. If you named it "gcase" then your FQDN would be gcase.azurewebsites.net.
IP: It depends on what you mean by this. If you're trying to address your App Service, then go into the Custom Domains tab of the blade and you will see an IP address for mapping custom DNS to. Note that this is only available for certain tiers of App Service Plans. However, if you need to know what IPs this can potentially connect to other services from, then go into the Properties tab of the blade and you will see a field labelled "Outbound IP Addresses".
Port and Protocol and Bi-Directional Flow: This totally depends on the software you install on there. We cannot tell you this.
If you can clear up your question, we can help you more. Otherwise, this is the best answer I can give you to your question as it is currently written.
I have a Azure Traffic Manager over a geo distributed cloud service. I need to lock down my cloud services which are primarily web apis so that they are accessible to only a certain range or IP ADDRESSES. Is there a way to achieve this? Or may be there are ways to restrict IP addresses on cloud services. But with a combination of traffic manager on top of that would that work?Does traffic manager flow the source ip address to the cloud services?
Traffic Manager cannot filter traffic. It just responds to DNS queries from clients.
The source IP address will be the original one because the traffic doesn't go through Traffic Manager, it only tells the caller where to go, and the caller then calls your service directly.
Late to the party but: if you ended up using a whitelist on for example an Azure App Service than you will need to add the addresses of Traffic Manager as well. Otherwise Traffic Manager will not be able to check the health of your App and report it as degraded.
You can find it here: https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-faqs#traffic-manager-endpoint-monitoring
Direct link: https://azuretrafficmanagerdata.blob.core.windows.net/probes/azure/probe-ip-ranges.json
Also late to the party but we were restricting our App Services by IP address and all of a sudden our traffic managers started to display degraded after working fine for years. After lots of investigation we think that Azure added some new traffic managers that were on different IP addresses so they were getting blocked by our IP restrictions. The original restrictions had included a small range of IP addresses for the traffic manager but this list looks like its expanded. The best solution is to allow the traffic manager through, not based on its IP address buts its service tag as below :
I have an Azure Scheduler Job which calls a REST endpoint over https.
The REST API is locked down by IP address so it's currently (and understandably) failing. So I need to add the Scheduler Job IP address to the API firewall.
The problem I have is I can't seem to find the IP address anywhere in the Azure Scheduler web interface.
Am I missing something or is it not possible to get the IP address in same way you can for other Azure resources (web apps, worker roles etc)?
Unfortunately Azure Scheduler does not reserve static IP, so the IP will change from deployment to deployment as we ship new changes. You may consider Logic Apps, which also supports calling REST endpoint over HTTPs, and does have static IP. See this link for more details: https://learn.microsoft.com/en-us/azure/app-service-logic/app-service-logic-limits-and-config?toc=%2fazure%2flogic-apps%2ftoc.json#configuration
Very late to the show but incase anyone else stumbles across this again, the IP addresses from the Azure Resource Explorer should get you what you need. See here for details on getting the IPs. You can also add the IPs for the relevant Azure Data Centers to your allow list if necessary.
I've been trying to find an answer to this for a few days.
I want to host a new azure website in either the Basic tier or Standard tier.
The site will be calling a third party service.
I need to give this service provider an IP address that they will whitelist.
So when the new azure website makes requests to this service the IP address for the request needs to always be the same, as this will be the IP whitelisted.
I read that Azure offers "Reserved IPs" for cloud services and VMs but I wanted to know if something similar can be done with Azure Websites as I really don't want to go with cloud/VM.
My knowledge of networking is limited but as I understand it, if I were to get an IP SSL cert and apply that to my Azure Website then the website would have a static IP address.
If that is the case, would any requests to the third party service be hitting the service providers external firewall with this same static IP?
Thanks for any advice people can give.
An SSL cert with Web Sites will be tied to an inbound IP address. However, Web Sites does not provide a static outbound IP address.
If you need a static IP address to align with 3rd-party services, you'd need to have something residing in Azure (e.g. Application tier) running in a cloud service / VM that your web site accesses, and then have that app tier (with static IP address) communicate with your 3rd-party services.
As David Makogon's answer points out, applying an IP-based SSL certificate only gives the website a static inbound IP address.
However, the outbound IP address a website uses when making outbound network calls can be determined based on where your website is hosted. Microsoft has a list of the these IP addresses here. The third-party service would have to whitelist all of the IP addresses used by the scale unit your website is hosted in (e.g. waws-prod-am2-005).
Correct me if I am wrong, but the information shared by Brant Bobby above shows that, in fact:
All Azure websites (/Web Apps) already have a discoverable and published outgoing IP address.
This outgoing IP address will never be unique to their own site however. So one must keep in mind if they use it for a white-list, it will be allowing in a lot of other Azure visitors hosted on the same scale unit.
Simply get the so-called "scale unit" name for your site, which is the same as what's given in your site's FTP address (and so forth), which is in the format: "waws-prod-[3LetterVar]-[3DigitNum]", e.g. waws-prod-blu-007.
As an example from that article, all the East US region Azure websites can find the four IP addresses their site may rely on as follows (so if white-listing, all 4 should be white-listed):
East US Region
Outbound IP addresses for each scale unit, currently 4 for each. They said they may add more IPs to each scale unit in the future, but these should not change.
waws-prod-blu-001: 168.62.48.13, 168.62.48.19, 168.62.48.33, 168.62.48.122
waws-prod-blu-003: 137.117.81.128, 137.117.81.142, 137.117.81.181, 137.117.81.82
waws-prod-blu-005: 137.117.80.189, 137.117.81.52, 137.117.81.90, 137.117.80.178
waws-prod-blu-007: 23.96.33.205, 23.96.34.196, 23.96.35.20, 23.96.36.229
waws-prod-blu-009: 23.96.97.203, 23.96.97.233, 23.96.97.235, 23.96.97.238
waws-prod-blu-011: 23.96.112.60, 23.96.112.117, 23.96.112.152, 23.96.112.15
waws-prod-blu-013: 191.238.8.154, 191.238.9.80, 191.238.9.94, 191.238.9.170
waws-prod-blu-015: 191.236.19.222, 191.236.19.242, 191.236.21.165, 191.236.18.160
waws-prod-blu-017: 191.238.32.104, 191.238.32.154, 191.238.34.67, 191.238.35.12
waws-prod-blu-019: 104.45.138.197, 104.45.142.87, 104.45.128.144, 104.45.142.131
waws-prod-blu-021: 191.237.24.189, 191.237.30.36, 191.237.26.164, 191.237.28.161
waws-prod-blu-023: 191.236.50.206, 191.237.30.215, 191.237.25.148, 191.237.22.195
waws-prod-blu-025: 191.237.31.86, 191.237.26.176, 191.237.20.70, 191.237.18.239
Azure now supports having static outbound IP address as well.
https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/
If we do not want to go for costlier App Service Environment setup, we can directly use the outbound IP addresses mentioned in the Azure portal in properties section, Azure assures that it remain 99.9% static. Nothing really changes until there is some changes data center wide. Moreover, the reserved Ip what we use in IaaS is also not 100% reserved for us and azure provides SLA of 99.9% here as well. So, In my opinion, instead of going for ASE and hosting IaaS and using reserved IP, we can just use outbound Ip provided by azure, since we get same reliability in both cases.