I have an App Service Environment (ASE) that is all working as expected. Unfortunately I now need to change to IP address range of the ASE, currently it is set as 10.0.0.0/26 and I'd like it to be 10.0.6.0/26. When I try to configure the Subnet associated with the ASE, I get an error saying I can't change it because it is in use.
Is there any way to change the IP Address range of the ASE?
I guess i'll be the bearer of bad news here. The answer is no. You have to delete the ASE and redeploy it to the new subnet.
From the docs:
Before you create your ASE
It is important to be aware of the things you cannot change. Those aspects you cannot change about your ASE after it is created are:
Location
Subscription
Resource Group
VNet used
Subnet used
Subnet size
While at it, you probably want to deploy an ASEv2 instead.
Related
I have whitelisted all the IPs under my functionapp to access a KeyVault with Managed Identity. I know that the MI works, because when I turn off the IP filtering, I can access the secrets. Using the IP filtering has worked in my other environments. I checked the logs of the KV to check the last IP addresses that had tried to access my KV, and saw a new IP address I hadn't seen before. Adding that IP address fixed the problem. However, this IP doesn't show up under my Functionapp properties. So is filtering IPs based on the function app properties not a viable solution anymore?
Azure Functions are subject to Outbound IP changes depending on the consumption plan you use - see official documentation - for scaling purposes.
You might have to whitelist the whole Outbound IP range (which is not the most secure way of doing of course.., attackers can come from Azure as well!) or use VNet NAT gateway mechanism or App Service Environments.
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 been using the New-AzureReservedIP cmdlet to create a new reserved IP address in Azure and associate it with an Azure cloud service staging slot. Basically what is described in this question. This cmdlet was part of the Azure module. However, as we know the Azure and AzureRM modules are not available in PS7 anymore. And this workstep is not even available in the Azure GUI.
As Microsoft recommends switching to PS7 and the Az module I assume that there is another way there to achieve the same thing. However, so far I was unable to find a solution.
The problem is that the staging slot requires a reserved IP if the production slot has one. To limit expenses we delete our staging slots after deployment. If we'd just keep and update it, that would not be a problem. Also, I was unable to find a way to re-use an existing reserved IP (that was created with New-AzureReservedIPpreviously) for the next staging deployment, so far I always needed to create a new one using New-AzureReservedIP. I ended up having quite a few reserved IP addresses which I don't use anymore so I wonder if they can be recycled somehow?
What would be best practice to solve this in PS7?
Reserved IP belongs to ASM API (Classic) and will be deprecated by 2023. Hence it doesn't exist in ARM. The new ARM API doesn't support this functionality. In ARM you have the option to use static Public IP (IP owned by Microsoft) or Public IP Prefix which is when you buy the IP address/IP range.
New-AzPublicIpAddress
https://learn.microsoft.com/en-us/powershell/module/az.network/new-azpublicipprefix?view=azps-4.5.0
New-AzPublicIpPrefix
https://learn.microsoft.com/en-us/powershell/module/az.network/new-azpublicipaddress?view=azps-4.5.0
But one thing to note is that if you are using App Service you actually get a Static Public IP for your App Service but that one is shared with many other customers hence you need to use your App Service URL eg. https://[AppServiceName].azurewebsites.net or add a Custom Domain to your App Service.
So if you really need a Public IP that is not shared you have to move over to IaaS eg. Virtual Machines
I want to enable traffic from my webapp (that sits inside the VNET and has its private IP) to Application Gateway (that is deployed to the same VNET and has NSG attached to its subnet).
How can I do it?
If I add webapp outbound ip to NSG as allowed - traffic works fine, but I do not want to hardcode this ip.
If I add "Internet" service tag it works as well, but it is too broad for my taste.
I could not find any other relevant service tags for me (tried "AppServiceManager", "AppService" and "AppService.AustraliaEast").
Also checked this document (and had to update the filename to last Monday! :) ) but could not find the IP that worked for me (52.187.231.76).
Ideal solution would be to allow only VNET traffic, but this did not do the trick as well... All ServiceEndpoints are there.
Checked with Azure support. Unfortunately there is no service tags available to do this yet.
Workaround - to manually add security rules for each application that supposed to access Application Gateway to allow Outbound IPs.
To do so - go to azure portal, to the application that needs to be able to access App GW. Go to properties blade and copy Outbound IP addresses. Then go to NSG and create a new inbound security rule to allow access from all of those IPs (at least it can be 1 rule).
According to Azure support those IPs should not change unless you recreate the whole webapp and the app can only cycle through those IPs.
I'm getting started using docker-machine on my Windows 2016 box. I'm trying to create some VMs in Azure but I have a particular network security group that I want for it to use and which already exists in Azure. I ran docker-machine create --driver azure and looked over the small help text which tells me how to set the resource group, subnet, etc but I don't see an option for network security group. Is there a way to specify an existing network security group for docker-machine to use when creating VMs in Azure?
Ok, so according to the documentation, you should use Subnet\VNet or Availability Set. The reason you are asking this is because you don't understand how NSG's work in Azure. NSG's are attached to a VNet or Subnet, so deploying a VM\Container into that Subnet\VNet will effectively attach that NSG to the entity you are deploying. But as the documentation states - "Once the machine is created, you can modify Network Security Group rules and open ports of the machine from the Azure Portal.".
So I suppose it creates a new NSG each time you deploy something, so there's no way to achieve that what you are trying (at least for now).
What you could try is deploy to an existing VNet and check if no new NSG are being created specifically for that container host which you are deploying. If that holds and you have an NSG in place, you've achieved what you want exactly.