Problem statement:
I have a logic app which I have exposed via APIM[I want this way as this is my design approach] and I want to allow only specific inbound IP address(in my case APIM IP) to access my logic app.
I have restricted the IPs in apim as follows, and which is working as expected.
<ip-filter action="allow">
<address-range from="xx.xx.xx.x1" to="xx.xx.xx.x5" /> //currently this is of no use.
<address>xx.xx.xx.xx</address> //my local machine ip.
</ip-filter>
Now, I have allowed the specific ip(apim ip) in my logic app and hit the request from my local machine, logic app prompt me an error.
When I added my local machine's Ip in logic app then it works as expected.
So,I think What is the point of restricting the ips in APIM because I need to allow all the IPs in logic app as well?
could anyone please assist/elaborate me what i am doing wrong.
In the Azure portal, access to your Logic App. Under Settings, select Workflow settings.
Under Access control configuration > Allowed inbound IP addresses, select Specific IP ranges.
Then you will receive a 401 Unauthorized status with postman and if we try from our APIM, we should get a 202 Accepted status.
For more details, you could refer to this article about How to restrict incoming IP ranges for a Logic App to accept only APIM calls.
I have analyzed the issue and below is the finding.
Getting Unauthorized is because of not whitelisting the local machine IP from which I was exploring the logic app to see the requested content.
Everything else is working as expected.
hope this will help!
Related
Our website is hosted on the Azure Linux web app, the site pulls data from third-party vendors. So we need to whitelist our website IP address to their server but after adding the IP for whitelisting still getting 401 unauthorized errors.
We checked the vendor and the IP has been configured properly but why we are getting 401 errors while pulling data via API call.
The IP address we found from Azure Portal --> web app --> select properties and the virtual IP address.
Any help or recommendation will be helpful.
If I understand you correctly, you are trying to whitelist the web app against the firewall for the third-party vendors app?
If so, then the virtual IP address that you have added is the ingress IP address for the web app. You need to add the outbound IP addresses from the Properties blade for the web app to the vendor's firewall.
You should note that there can be up to 11 of these IP addresses. Also, if you scale the web app up or down to a different service plan, or perform any change that will result in a new scale plan, the IP addresses will change. This does not apply to scaling out to multiple instances.
Using a static IP address solved the problem.
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.
I have an .Net Core app published on Azure, the webapp has an endpoint that is publicly accesible.
When creating an HTTP POST request using the full url {azure-url}/results it works as expected. However a client needs to use this endpoint but his system transforms urls into IP addresses before creating a request (not sure why to be honest).
I've checked through Azure properties which is the IP address of the webapp which also matches when doing a nslookup. Problem is that when I replace the url with the IP address and make a request it returns 404.
Has anyone experienced something like this? I wonder if it's related to some Azure configuration I'm not aware of.
Azure App Service is a multi-tenant service. Meaning that other apps may share the same servers and thus the same inbound IPs. In order for your request to be routed properly to your app, it needs the domain name, not just the IP.
There is a way to get a static inbound IP by using a custom domain. I haven't tried that but I would assume even then you will not be able to call the service on that IP.
I'm trying to serve multiple Azure App Services behind an Application Gateway. These services should only be reachable through the application gateway endpoint. To achieve this, I've done the following:
Added a VNet
Added a subnet, and added all app services to it
Added an application gateway with appropriate rules for pointing to the app service
Added access restrictions to the app service to only allow the subnet of the application gateway, and the public IP of the application gateway
The health probe of the application gateway indicates the service is healthy (and thus reachable), but when I try to make a request to the service trough the gateway using Postman, I get a 403 IP forbidden error. However, when I add my local IP as an allowed IP address to the app service, the request comes through just fine
From what I've read online, adding the public IP of the gateway should be sufficient for allowing access through the gateway, but it seems that requests from my local machine are blocked. Am I getting something fundamentally wrong here?
Edit: I also tried assigning a front-end private IP address to the gateway and adding access for that in the app service, but that also did not work
Edit 2: My configuration
Access restrictions for app service:
access restrictions
Backend pool:
Backend pool
HTTP settings:
HTTP settings
Listener:
Listener
Rule:
Rule
From your description "Added a subnet, and added all app services to it", I assume that you are meaning integrating app with Azure VNet or enable the service endpoint with Microsoft.Web for the subnet. If so, you could remove them. Both are useless in this scenario.
To restrict the access through the gateway, you only need to add the frontend IP address to the Azure App Service access restrictions. For more details, you could refer to this blog https://www.cloudmanav.com/azure/restricting-appservice-accessible-via-appgateway/#
If you have NSG associated with the subnets, you could follow the prerequisites here
https://learn.microsoft.com/en-us/azure/application-gateway/configuration-overview#network-security-groups-on-the-application-gateway-subnet
Edit
You may have redirection configured on your app service or have Azure Active Directory authentication, which causes the redirection. So when redirection happens, the client makes the request directly to app service URL Path contoso.azurewebsites.net/xxx instead of going through the application gateway URL path contoso.com/xxx.
To fix it, you could use a custom domain name to pass the same host name that the application gateway receives to the app service as well, instead of doing a host override. Get more details about this solution here.
I have a WebJob on an Azure Website that needs to connect to a VM Endpoint to make REST calls.
My Endpoint is configured to deny all except my company's IP range. Now what rule would I need to add or url should I use so my webjob can connect to the endpoint?
I have tried the following without success:
Allow my website virtual IP address in the ACL
Connect to the endpoint using the internal IP instead of the DNS without changing
the ACL
Connect to the endpoint using the public virtual IP instead
of the DNS without changing the ACL
This works but is not what I am looking for:
Remove the current ACL and allow all
Keep the ACL but add a /16 rule with my website IP
Thank you for your help, and let me know if you need precision!
I need the same thing but it seems as though is not possible right now. Looking at this answer on a related question:
Azure Web Sites do not have dedicated outbound IP addresses for each
deployment. This precludes you from using ACLs or Virtual Networks to
connect to your Redis / Solr virtual machines.
So even though you can have a (reasonably) fixed incoming IP address on Azure Websites, the outgoing address is highly unpredictable and as far as I can see, the only exclusion that you could make was to restrict it to the entire range of IP addresses for that data centre which is far from ideal.
A solution moving forward will be to connect your Azure Website and the VM on the same Virtual Network. As of my writing this it is still in Preview so it still is not ready for production use just yet.
Here is more information on it: http://azure.microsoft.com/blog/2014/09/15/azure-websites-virtual-network-integration/