I am trying to create an API Management service that's within an external virtual network and using an Azure Function App as the backend. The virtual network is set up to allow only a specific range of IP addresses in, and I've set up the outbound rules as per this document.
Unfortunately when I try to hit the endpoint surfaced by API Management through the portal, I receive the following HTTP response:
HTTP/1.1 400 Bad Request
content-length: 53
vary: Origin
content-type: application/json
{
"error": "Unable to connect to the remote server"
}
If I hit the API Management request URL with curl I get a 404 response but no body. If I hit a URL that's not actually part of the API Management service, I get a 404 response with a proper body.
If I hit the endpoint surfaced by the Function App I get the response I expect, so that at least is working well.
I've even gone so far as to completely open up the Network Security Group on the virtual network to allow all traffic inbound and outbound and that has no effect.
Is it even possible to use a virtual network to restrict access to an API Management service backed by a Function App in this way? If so, how?
Related
I want my web app to be able to send requests to another web app,
I have added the (Outbound) Public IP of the web apps to the mutual access restriction.
In Kudu Console, I use "tcpping" to test that the hostname of his web app is connected (443port).
But I execute my web app with postman and my web app is getting "Forbidden".
Later, when I executed curl in the Kudu Console of my web app, I also received 403 Forbidden.
And the Kudu Console of the other party's web app executes curl and displays 401,
In addition to Access Restriction, do I need to confirm any settings?
As HarshithaVeeramalla-MT said, it was later found that the outbound IP addresses of both parties were not complete, and all IP addresses of Additional Outbound IP Addresses need to be added to the Netowrking/Access Restriction before they can access each other.
Thank you.
I am using a V1 WAF application gateway (dynamic IP) in front of a web app.
When i configure the web app access restrictions to Allow the application gateway i received a when i tryu to access the web app url (expected behavior). However, i also received a 403 when accessing throught the app gateway url (not expected !). i have try a rule to allow the app gateway ip and also a rule allowing the app gateway vnet (service endpoint) with both same result. Any idea why its not working ? Thx!
I suggest you to know about this topic. you are probably getting a VPC error.
https://azure.microsoft.com/en-us/services/virtual-network/#overview
I'm using a custom connector to connect to an on prem SOAP web service via a data gateway. The request is failing due to the large number of x-ms-* HTTP headers being added by the custom connector. The target web service is hosted on Apache Tomcat and has a restriction on HTTP header total size (which I cannot control). Is there any way in either logic app or custom connector configuration to stop these HTTP headers being added?
Unfortunately, there is no way to control this from logic apps itself. Instead, you could front your SOAP service with a proxy that handles this for you.
In the cloud, you could use Azure APIM which can strip headers from being forwarded to your SOAP service.
You can also deploy APIM in a VNET for it to access sources on-premises via a VPN Gateway or an Express Route connection.
I have a backend API that is hosted in Azure app service. I want to use Azure API management as the front end to this backend API and have successfully configured this in Azure. I have configured API management to use OAuth when accessing this backend API which works when clients access the API through the Azure API management endpoints, but how do I prevent people from accessing the backend API endpoints directly so that only calls from the API management endpoints are allowed?
There are a few options of various levels of security:
Shared secret - set a certain header with a certain value in APIM and check that value at your backend.
Managed identity - you can enable managed identity in APIM service and send its token to your backend where you'll be able to validate it.
IP filter - check for APIM IP as a source at backend.
Client certificate auth - upload a client cert auth to APIM and attach it to every request to backend. Check for that cert at backend.
VNET - put APIM and your backend into same VNET and block access from outside to backend.
I've personally used IP restrictions to great success. APIM is given a static IP, so you can setup an IP restriction in the "root API" that allows only the APIM calls. This results in a 403 if you call the root API directly.
If you don't want a 403 coming from the root API, you can use policies to change that, or you can setup authentication at the APIM level and you'll get a 401 before even hitting that 403.
I'm getting 403 Forbidden error when hitting Azure Functions via API Management. Just to be clear, I don't have any Authentication/Authorization in the function but Authorization Level is set to Function Level.
I can hit the function directly using the Function key.
I can also hit the API Management and getting response when mocking was enabled so the error is coming out of the function. I can verify that the function key is being passed by API management to the backend function.
Noticed that this only happens when the function was deployed using ARM.
Our Azure Function was deployed with IP restrictions and APIM IP was not present there. After adding APIM IP address thru Function's Platform Features > Networking Group > Networking > Configure IP Restriction, 403 errors were gone.