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.
Related
I have an Elasticsearch cluster that I need to access using an Azure Functions App. The current way to access it is via an IP whitelist. I've created my consumption plan Azure Functions and noticed that the IP address kept changing and after further research found that I'd need to whitelist the whole Azure Cloud which is not a secure option in our case. So I've upgraded Azure Functions to Premium plan and thus the VNet Integration appeared in the app settings allowing me to create a Virtual Network and a static Outbound IP Address.
Now it is working.
But since I'm using the Premium plan and the other mentioned services, the cost went up.
I've experimented with Azure Data Factory in the past and there was an option to install a local Integration Runtime so when ADF was accessing Elasticsearch via the Local Integration Runtime, it worked. Is there something similar I can use with Azure Functions? Like a Data Gateway I can install on a local server that is already whitelisted on Elasticsearch and all I'd need to do is connect from Azure Functions through it?
I guess the ideal scenario I'm looking for is to be able to use a Consumption Plan on Azure Functions.
Kind Regards,
Andrei
Just to close this one, in the end, I've used a Standard AppSevicePlan (S1) (costs $74|£51/month or about $2.5|£1.7/day). I've had to create a static Outbound IP, a NAT Gateway (which costs about another $30|£23/month or $1|£.77/day) and a VNET.
The tutorial can be found here: https://learn.microsoft.com/en-us/azure/azure-functions/functions-how-to-use-nat-gateway
Another option that I've considered to reduce cost was to use a Hybrid Connection which would install a sort of gateway to a local server to which Azure Functions would connect first before reaching the ES endpoint...that would eliminate the need for the Outbound IP, NAT Gateway and VNET (so $30 less per month) but would still require at least an S1...so no option on consumption-based, and I don't know if there is any charge associated with this. However, we didn't go with this option as we want to eliminate any local dependencies (e.g. if the server where the gateway is running would shut down).
To sum up, use an S1, follow the tutorial mentioned above and should cost about $104|£74/month
In my current situation, we have several Azure Function apps that talk to an Azure SQL database (using Entity Framework, should it matter), using functions that trigger on an Azure ServiceBus trigger.
In the last weeks we have been improving security by using a VNET and subnets to only allow access to the Azure Database server by only the Function apps that need to use it. However, I have run into a strange issue. It seems that now the database server is set to disallow traffic apart from the defined subnets in which my fuction apps run, the function apps start giving intermittent SQLExceptions when connecting to the database with the message that some specific IP is not allowed by the database Firewall rules. The weird thing is that this error is not consistent. I would expect either for the function app to be declined at the firewall for it's IP, or be allowed all the time, but not randomly as is currently the case.
Question
Is there something that I am missing with my setup? Or, how do I force my function apps in subnets to use their internal IP that is allowed by the database server firewall rules, and not some other outbound IP address that is not in the database firewall rules?
Alternatively: What can possibly explain that access to the database sometimes succeed (indicating a proper internal IP used by the funcation app), and sometimes fail on the firewall (with an unknown IP address), seemingly at random.
Hopefully somebody can help!
Detailed Description of situation
The Function App has a function that is triggered by a Service Bus trigger. The Function App is running with a P1v2 Premium service plan with Vnet integration on.
The app is running inside a Subnet in our environment with a defined IP adress range with a /26 subnet mask. If I check the environment variables of the funciton app in Kudu I can see the PRIVATE_IP_ADDRESS setting is in the subnet range. The database firewall is set up to disallow all traffic, apart from the subnet of my function app as follows:
Triggering the function app which will write some stuff into the database works sometimes (Indicating that the access to the database is working at least when the IP address of the function is the correct one) however, there are also a lot of SQLExceptions with the following error:
Cannot open server 'database-server-name' requested by the login. Client with IP address 'XXX.XXX.XXX.XXX' is not allowed to access the server. To enable access, use the Windows Azure Management Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range. It may take up to five minutes for this change to take effect.
The IP address mentioned in the error is NOT the internal IP defined on the Vnet or subnet IP range. It is also not even one of the IP's that show up in the Possible Outbound Ip addresses of the function app,
These happen more or less randomly. Sometimes they don't appear for x triggers, sometimes it fails for hundres of calls in a row.
Enabling the Datbaase server setting "Allow Azure services and resources to access this database server" stops the error from occuring, but of course that is counter to configuring the firewall to allow certain subnets
What I have tried
Setting the configuration settings WEBSITE_VNET_ROUTE_ALL and WEBSITE_DNS_SERVER on the function app to force traffic to use the VNET route as metioned here: Unable to connect Azure Function with Azure SQL using private endpoint
Adding Storage as service endpoint to the subnet as mentioned here: Unable to connect to Azure Function App after integrating into VNET
Restarting and stopping/starting the Function app
Changing the Function app Scaling to force a change in outbound IP addresses as mentioned here: https://learn.microsoft.com/en-us/azure/azure-functions/ip-addresses#outbound-ip-address-changes
Your Azure Function will only use a private outbound IP address picked from your VNet when you have VNet integration enabled. The VNet integration option is only available in the Function Premium Plan.
Additionally, the environment variables WEBSITE_VNET_ROUTE_ALL and WEBSITE_DNS_SERVER you already mentioned should be set as well as mentioned here (assuming your SQL server is in the same VNet).
Of course a new day and fresh perspective brings the probable answer.
While I havent changed anything about the setup I mentioned in my question, I was reading this post again: https://learn.microsoft.com/en-us/azure/azure-functions/ip-addresses#outbound-ip-address-changes
It mentioned switching the service plan temporary force an IP change. I initially misinterpreted this as switching between the DEV and premium plans, which cannot happen because the DEV plans don't support VNET integration. So I switched plans between the P1v2 and P1v3 plans. This however did not work.
What was meant here was to switch beween S1 and P1v2 plans. The Standard plans are hidden behind this link:
It also shows this small message net to the Apply button.
After switching between the S1 and P1v2 plans for a moment and resubmitting deadlettered servicebus messages to the function app, everything started working again.
I assume the IP switch was necessary, but switching between P-plans is not what triggers it. It has to be between standard and premium.
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 set up a simple asp.net web forms test site for learning Azure, with a simple DB. Works fine locally. I deployed it to Azure. Then went through learning curve on the need to separately deploy the DB, link the resource, check connection strings and so on.
There's an issue, where the program on the site gets an error. I'm going through many paths to try to diagnose it. This question is about one specific path.
Several articles say that for the website to use the DB, I have to add the IP address of the website to the allowed IP addresses of the DB server.
https://azure.microsoft.com/en-us/documentation/articles/sql-database-create-configure/
However, I can't find the IP address for my FREE Azure website. When I researched this, it looks like there is no available fixed IP address for free websites.
So either:
1) I need to know where to get the IP address for the free website, or
2) there is some way to use Azure SQL in free websites without having to
designate an allowed IP address, or
3) something completely different.
Any help with this would be appreciated.
Thanks!
UPDATE: Below is all I see on the database configuration page, i.e. no firewall rules. However, I became convinced that the "Allowed IP Address" requirement must be finessed automagically in Azure, and so that was likely NOT the problem, which made me look more closely at the connection string, which WAS the problem. Basically one day of newbie learning curve, which I'll have to sleep on and try to understand more tomorrow.
There's an option to allow Azure services when you configure the database firewall. Check if that's checked. Also, posting the actual error message will help.
You don't need to do that for things that are hosted within the Azure platform.
Under the Azure SQL Server Firewall (Preview Portal) settings, ensure that the Allow access to Azure services is turned on:
Alternatively, via the Old Portal, the setting is found via:
Databases -> Servers -> Configure
Does anybody know if it's possible to change the IP address of a site hosting on Windows Azure Cloud Services.
We currently have a site hosted in the 'North Europe' location, however the GEO IP of the IP Address assigned returns USA. This is causing problems with an API we have started using that can only be access within the UK checked via GEO IP Location.
Within the region of 'North Europe' however, there are a couple of IP ranges that have ip addresses that consistently return 'Dublin/UK' which will be ideal for what we need.
So, does anybody know if this is possible? we don't have technical support on the plan we use, which is why I'm asking here.
Thanks in Advance,
Bav
I'm not aware of a way to change the IP address. At least not without deleting the deployment and recreating (which would likely assign a new IP address). That doesn't guarantee you'll get what you're after though.
This does seem to be a known issue though:
http://blogs.msdn.com/b/wats/archive/2014/05/10/microsoft-azure-datacenter-s-ip-location-shows-incorrect-location-when-using-ip-geolocation-services.aspx
http://azure.microsoft.com/blog/2014/06/11/windows-azures-use-of-non-us-ipv4-address-space-in-us-regions/
Azure support may be able to help, but that likely requires a support plan. :(
You normally can't control the public IP address of your cloud service. This is partially controlled by the region you select, but not entirely.
As part of the most recent Azure update, however, you can reserve a public IP address that will never change as long as you keep the reservation. These are not free, but they're probably your only option.
See: http://azure.microsoft.com/blog/2014/05/14/reserved-ip-addresses/
Now, this still won't let you pick your IP - but you could keep requesting reservations until you get one you like.
Lastly, as another answered suggested, there is no way to change the IP of a cloud service post-deployment. You must delete the deployment to get a new IP. (Or change network configuration, or rename the cloud service / get a new DNS name, etc.)