0

I have a configuration in Azure with a Virtual Network and 2 subnets. In 1 subnet I have an App Service Environment v3 + App Service Plan + Logic App Standard. I have a workflow with an HTTP Trigger.

In the other subnet, I have an API Management instance, and I need to expose my Http triggered workflow as an API in APIM.

The DNS of the Virtual Network is hosted internally (on-premises) and not managed by Azure. There is no conditional forwarding setup for the moment.

Because of this, the URL of the workflow is something like ..appserviceenvironment.net/.

The DNS name cannot be resolved and I want to know what is the solution I can put in place to make it work? Do I need to create a private DNS zone for the ".appserviceenvironment.net" and add manually the private IP of the app service environment?

David GROSPELIER
  • 772
  • 1
  • 9
  • 35

1 Answers1

0

• I would suggest you to please refer to the github link below for more information and step by step details regarding the connectivity to a virtual network in an internal mode using the Azure API management: -

https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/api-management/api-management-using-with-internal-vnet.md

It states that API gateway, developer portal, direct management and Git are the only endpoints that are accessible from the virtual network that is configured in the internal mode for API Management instance. Also, the service endpoints will remain inaccessible until you configure DNS for your virtual networks.

Also, using API Management in internal mode will expose your cloud-based APIs and on-premises APIs through a common gateway in hybrid cloud scenarios. And to configure the common gateway, you will have to provision a private DNS zone and link it into your virtual network through a hostname which is configured on the service endpoints, one of which when using the private DNS zone is the API gateway with which you want to have a workflow with an HTTP trigger.

Please go through the link below for configuring the routing details related to API Management Instance in the virtual network: -

https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/api-management/api-management-using-with-internal-vnet.md#routing

Kartik Bhiwapurkar
  • 4,550
  • 2
  • 4
  • 9
  • It is not exactly what I'm asking. What I'm trying to do is to address an Azure resource that is inside the same virtual network of my APIM (but in another Subnet). But this resource I want to expose as an API (a Logic App) cannot be addressed from the APIM because of a DNS name resolution issue (I think this is the root cause, I'm not sure). So I want to know how I can check this. I'm not looking for a way to address APIs from within the VNet it self, thus I know how to manage it. – David GROSPELIER Feb 04 '22 at 09:54
  • I understood your query regarding the API exposure through APIM using DNS hosted on premises but for that purpose, you will have to ensure that your on premises DNS records are updated with those of public DNS entries for your domain website and hosted applications. Similarly, then you will have to verify that domain in your Azure tenant and accordingly update the private DNS endpoint with reference from this link: - https://learn.microsoft.com/en-us/azure/app-service/networking/private-endpoint – Kartik Bhiwapurkar Feb 15 '22 at 09:47
  • You are right @kartikbhiwapurkar-mt, this is exactly what I'm looking for. Unfortunately, it is currently not supported to add public DNS entries into my custom DNS server, because it looks like the only way to do this is to do a "conditional forwarding" from this DNS server to the public DNS server. And this is something that is not currently configured. – David GROSPELIER Feb 17 '22 at 15:56
  • You can easily configure conditional forwarding in your on-premises DNS server to the API exposed in APIM by following the steps in this link : - https://www.interfacett.com/blogs/windows-server-how-to-configure-a-conditional-forwarder-in-dns/ However, do ensure that the API exposed has a configured public IP or reachable site name, i.e., FQDN. – Kartik Bhiwapurkar Feb 18 '22 at 15:18