Deploying Azure API Management in an Internal mode (inside VNet)

Published Dec 10 2021 09:01 PM 2,319 Views

Background:

Recently I helped a customer deploying Azure API Management in an Internal Mode (inside Virtual Network, not accessible from internet). This brings in several challenges, some of it documented and some are not clearly. Intent of this blog is to alleviate some of those pain points.

Challenges: 

  • Testing APIs in APIM through the test console available on the Azure Portal
  • APIM calling backend APIs hosted in on-premises
  • On-premises applications calling APIM gateway (to consume APIs hosted in Azure and fronted with APIM)

Let's take first challenge, when you start testing APIs in APIM through the test console available on the Azure Portal, you will get following message.

 

HTTP/1.1 302 Moved Temporarily
Backend service responded with a redirect.

 

If you provision a VM in the same VNet as your APIM and RDP in to the VM and test API through the test console available on the Azure portal and you still get HTTP 302 message mentioned above. This issue/feature is by design and is documented here: Connect to an internal virtual network using Azure API Management | Microsoft Docs

 

“Since the gateway URL is not registered on the public DNS, the test console available on the Azure portal will not work for an Internal VNET deployed service. Instead, use the test console provided on the Developer portal.”

 

(Note: This happens because when we test APIs via test console available on the Azure portal, the test console is making calls from internet and our APIMs is locked inside VNet, so it's not able to reach or resolve the DNS. Even when you RDP in to the VM, which is in the same VNet as your APIM, the APIM Test feature still goes out to internet and try to reach back APIM which is locked inside VNet and can’t reach.)

 

So as mentioned in the doc, if you use Developer portal (or Postman or SoapUI, etc.) from your laptop (not connected to Vnet where APIMs deployed) or from a VM connected to same VNet as APIM, the Developer portal (for example: https://contosocorp.developer.azure-api.net/) won't come up because DNS can't be resolved. Easiest/temporary solution is setting up host file entries on the VM connected to APIM Vnet as mentioned here. For recommended solution read on.

 

Solution:

In order to test APIs using Developer Portal or Postman and for other Azure services to call APIs via APIM, we need to provision a VM, add necessary Private DNS zones, link them to VNet and restart APIM. Some of these steps are documented in the following doc. Step by step details below:

Connect to an internal virtual network using Azure API Management | Microsoft Docs.

 

Step 1: Provision an Azure VM in to same VNet where you've APIM deployed 

Once you create or move an existing APIM into an Internal mode, you can't access/test your APIs through the test console available on the Azure Portal or Developer Portal, if you are not connected to VNet where you've APIM deployed.  Your Developer Portal won't even load because the DNS can't be resolved publicly, which makes sense as your APIM is locked inside VNet. So, you will have to provision a Windows VM in the same VNet but different subnet (or different VNet then do VNet peering with APIM VNet) where you have APIM deployed. Then once you follow the steps 2-4 below, you can access your APIs through the test console or Developer portal. 

 

Step 2: Configure Azure Private DNS Zones

Create the following five private DNS Zones and then add a Record Set with your APIM name (in this case Contosocorp) and APIM Private IP (in this case: 10.1.0.5)

 

Private DNS zone name

APIM Name

APIM Private IP

azure-api.net

Contosocorp

10.1.0.5

portal.azure-api.net

Contosocorp

10.1.0.5

developer.azure-api.net

Contosocorp

10.1.0.5

management.azure-api.net

Contosocorp

10.1.0.5

scm.azure-api.net

Contosocorp

10.1.0.5

 

 

Step 3: Link the Azure DNS private zone to the VNet into which you've deployed your APIM

Quickstart - Create an Azure private DNS zone using the Azure portal | Microsoft Docs

 

Step 4: Restart the APIM

As mentioned in this doc if you plan to use a custom DNS solution for the VNET, set it up before deploying an API Management service into it. Otherwise, you'll need to update the API Management service each time you change the DNS server(s) by running the Apply Network Configuration Operation.

 

Use the "Try it" option from the doc, it will generate JWT token automatically for your account once you sign in. Supply resource group name, APIM name, etc. then click Run, you will get Response Code: 202. This will take 30-45 to restart APIM, now check your APIM, it will be in "Service is being updated..." state.

 

On-premises applications calling APIM gateway (to consume APIs hosted in Azure and fronted with APIM)

Setting up DNS resolution solution so that an on-premises application can call Azure APIM gateway (or any Azure resource with Private Endpoint) is beyond the scope of this blog. This is more of a Networking/DNS challenge but documenting here for completeness. Following doc walks through how an on-premises VM uses Conditional Forwarder & DNS Forwarder solution to call an Azure SQL Database connected to a private endpoint. We can leverage the same setup so that an on-premises application can call an Azure APIM gateway.

Azure Private Endpoint DNS configuration | Microsoft Docs

  

APIM calling backend APIs hosted in on-premises

If backend APIs are internet exposed APIM can directly call them, this is easy. If backend APIs hosted in on-premises and they are not internet exposed, then Azure needs to be connected to on-premises via Express Route or Site-to-Site VPN so that APIM has line of sight to backend APIs. And if there is a firewall in between, it needs to be updated as well, so APIM can successfully communicate to backend APIs. While this Setup/DNS resolution is beyond the scope of this blog, I'll briefly touch on how DNS resolution needs to be set up.

There are two ways to provide DNS resolution for APIM.

 

Using Azure Private DNS Zone (easy option):

  • Even though this option is easy to setup, you may run in to limitations eventually and you are basically replicating on-prem DNS resolution in Azure. So, every time you need new on-prem address resolution, you may have to either create new Record Set in the existing Private DNS Zone or even create new Private DNS Zone itself depends on the on-prem destination address. 
  • Create Private DNS Zone, for example private.contoso.com
  • Create a Record Set in the Private DNS Zone, for example api.private.contoso.com with A record type pointing to internal IP address
  • Link to the VNet where you have APIM deployed using Virtual network links setting
  • Restart APIM (follow this doc to Apply Network Configuration Operation)

Using DNS Servers (complex but recommended):

  • Setup two Windows Server VMs (or Linux VMs) for high availability, along with Load Balancer to load balance DNS requests
  • Configure DNS Server roles on those Windows Server VMs
  • Create Forward Lookup Zones record(s) as needed for your on-premises DNS names
  • Go to Virtual Network where you have APIM deployed, add DNS server (Custom) with Load Balancer's private IP
  • Restart APIM (follow this doc to Apply Network Configuration Operation)

 

Summary: So to close out when you create APIM in an Internal Mode (inside VNet), there is more work we need to do, such as provisioning a VM (of course if you are connected to on-premises via Site-to-Site VPN or Express Route, you can access from on-premises VM provided you created conditional forwarders in your DNS server or added host file entries), Configure Private DNS zones,  link the Azure DNS private zone to the Vnet, restart the APIM and finally you can test your APIs either using APIM Developer Portal or tools like Postman.

2 Comments
Co-Authors
Version history
Last update:
‎Jan 07 2022 02:55 PM
Updated by: