I have a logic app sitting in an internal ase which is also sitting behind an azure app gateway. The logic app does not automatically "fetch" via the run trigger I assume due to some traffic constraints utilizing the office365 api connection on an internal ase. The Logic App has a "when a new email arrives" trigger based on a specific subject line but this never triggers. Is the best way to accomplish this is to utilize a NSG to allow inbound/outbound traffic to the various list of ip address etc for Office365? Are there any pre-existing service tags I can use on the NSG?
As per document, you can use services tags in network security group. As you are using logic app which is on internal ASE, need to add inbound and output security rules as mentioned in the above document.
Add outbound rule as shown in below image,
Add inbound rule also as shown in below pic,
Reference link
Related
I'm trying to secure my containerized web app with a Premium V2 App Service Plan. I've enabled Service Endpoints for an integration subnet for the different App Services to restrict incoming traffic from each other except for the frontend (so all of them are integrated with the VNet and all have incoming traffic restricted to that VNet except for the frontend).
I have also other Azure services like Azure Functions or a Storage Account that can have inbound traffic restricted by using those Service Endpoints. However, One of the App Services calls an external 3rd party API that lies on Azure too. That API may or not be behind a static IP. However, it has a Custom Domain associated.
The problem arises when I try to connect to that API from one of the VNet integrated App Services. As the destination IP is inside one of the IP ranges that are added to the routing with the use of a Service Endpoint, traffic is sent via that Service Endpoint instead of simple Azure routing. I've tried overriding the route with a Route Table associated to that subnet but that seems not to be possible, with or without a NAT Gateway attached to the subnet. I guess Azure routing is prioritized here. I'm sure the route is not effective as I used it on a different subnet where I deployed a VM.
Is there any way I can use that Service Endpoint for my internal traffic only so it's not used when it goes to an Azure hosted API or I need to switch to a different approach like Private Endpoints or an ASE?
I am unsure what you're looking for but if you want to explicitly define routes you should try using app services setting "WEBSITE_VNET_ROUTE_ALL" = 1 which overrides the default precedence of routing and makes sure that every outbound call follows the route defined inside route table of subnet.
Use the following steps to add the WEBSITE_VNET_ROUTE_ALL setting in your app:
Go to the Configuration UI in your app portal. Select New application setting.
Enter WEBSITE_VNET_ROUTE_ALL in the Name box, and enter 1 in the Value box.
When WEBSITE_VNET_ROUTE_ALL is set to 1, outbound traffic is still sent from the addresses that are listed in your app properties, unless you provide routes that direct the traffic elsewhere.
We've been able to ask the 3rd party to disable blocking rules. It turns out they had a rule that blocked this specific traffic.
I already tried changing that setting, but didn't try putting a route table on it. However, it'd make no difference as I can't define a list of allowed outbound IPs belonging to Azure since we have no static IP to call.
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.
My application is making HTTP requests to a 3rd party API which has an IP whitelist.
Of course, I could add the IP addresses assigned when the Web App is created but test environments are created and destroyed on demand, meaning we need to request an update the whitelist.
My thoughts are to attached the Web App to an existing VNet and assign a NAT to specify the outbound IP. Will that work?
According to the official document, the example operation can be completed, WEBSITE_VNET_ROUTE_ALL needs to be configured, and you need to pay attention to WEBSITE_VNET_ROUTE_ALL is currently not supported in Windows containers.
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 received in hands a project where an Azure Application Gateway (AGW) uses as backend pool an Internal Load Balancer (ILB) App Service Environment (ASE) containing multiple apps.
The AGW is setup up using several multi-site listeners, where the host of the each multi-site listener matches a custom domain in an App Service instance running in the ILB ASE. Like this:
I need to add a new app to the ASE and corresponding configuration to the AGW.
The problem is that the AGW can have at maximum of 20 listeners, which has been reached in the project I received in hands. So I can't add more apps to the AGW with this setup.
To work around the listener limitation, with minimal changes, I would like to make use of multi-site path-based routing with the ILB ASE as backend pool.
I would like something that looks like the following:
I have spent some time going over the docs as well as other StackOverflow questions. I also have gone over the multi-site app service docs https://learn.microsoft.com/en-us/azure/application-gateway/create-web-app, including playing around with the -PickHostNameFromBackend switches.
I have made a few experiments without success so far.
I believe that what I want to do is currently not supported by the AGW. I think I understand why. The hostname passed from the AGW to the ILB ASE (api.example.com) is not present as custom domain in any of the App Service instances in the ASE, so the request will not be fulfilled. Correct me if I am wrong please.
Is my desired setup (Figure 2) possible ?
If not possible, what would be alternative solutions, with only one AGW as I have today?
Firstly you can open a support ticket to increase the listener/backend pool count from 20 to 40. That should offer you some expansion room immediately.
The second scenario should be possible as well. You should use api-aaa.example.com and api-bbb.example.com as backend pool members. And use the switch PickHostNameFromBackendAddress on HTTPSettings and also create a custom probe with PickHostNameFromBackendHttpSettings flag set and associate probe to the HTTPSetting. The you would use this setting in each path based rule while associate paths to backend pools. Please ensure that your internal DNS within VNet, can resolve api-aaa.example.com and api-bbb.example.com to the ILB IP 222.222.222.222.