API Management] Internal VNet mode + custom domain + F5 front end — still need a jump VM to access Developer Portal/management endpoint

Ankit Pathak 0 Reputation points

Environment: Same APIM instance as above — Developer tier, Internal VNet mode, custom domain apidp-test.api.xxxx.xxxx for the Developer Portal. F5 BIG-IP is configured with a virtual server to accept internet traffic and forward it to the APIM private IP.

Issue: Even with F5 routing external traffic to the private endpoint, we still can't access or publish the Developer Portal from outside the VNet. The only working method so far is spinning up a jump VM inside the VNet and browsing to the endpoint locally.

What's been tried: DNS resolves correctly (private zone linked to the VNet). The private IP is reachable from inside the VNet via the jumpbox. F5 virtual server/pool points at the APIM private IP on 443.

Question: For an Internal VNet-mode APIM, is there a supported way to expose the Developer Portal — and the management endpoint required to provision/publish it — externally through a third-party reverse proxy like F5, comparable to Microsoft's documented Application Gateway pattern? Are there specific SNI, host-header, or backend TLS settings we might be missing on F5, or is a jump VM genuinely required for the initial portal publish step regardless of front-end routing?

  1. Rakesh Mishra 9,700 Reputation points • Microsoft External Staff • Moderator

    Hello Ankit,

    Thank you for reaching out to the Microsoft Q&A community.

    Based on the scenario described the difficulty you are experiencing in exposing the APIM Developer Portal and Management endpoint via your F5 load balancer stems from how APIM handles incoming traffic when injected into an internal Virtual Network.

    When APIM is deployed in internal VNet mode, it receives a Private Virtual IP (VIP). However, it relies strictly on hostname resolution rather than direct IP-based routing. As stated in the official Deploy Azure API Management instance to internal VNet documentation:

    "The API Management service does not listen to requests on its IP addresses. It only responds to requests to the hostname configured on its endpoints."

    If your F5 load balancer is terminating the TLS connection and forwarding traffic to the APIM’s private IP address without passing the exact custom domain (or default) Host header and SNI, APIM will drop or reject the request because the target destination IP does not match its configured endpoint hostnames.

    Resolution Steps:

    To resolve this issue and securely expose the portal without relying on a local Jump VM, ensure your F5 is configured with the following parameters:

    • Preserve Host Header & SNI: Configure your F5 Server SSL and HTTP profiles to preserve the original Host header and append the SNI extension matching the APIM custom domain (e.g., developer.yourdomain.com).
    • Backend Routing: The F5 must forward this preserved traffic over port 443 directly to the APIM's private VIP.
    • External DNS: Your public/client DNS records for the Developer Portal and Management FQDNs must resolve to the public VIP of the F5, while the F5 itself forwards internally to the APIM Private VIP.

    Once the front-end proxy correctly preserves the headers, APIM will recognize the incoming requests, and you will be able to access and publish the Developer Portal directly via the F5.

    Please let me know how it goes.

Sign in to comment

1 answer

  1. AI answer

    For an Azure API Management instance in internal VNet mode, all API Management endpoints (gateway, developer portal, management, Git) are only accessible inside VNets and networks that can resolve the configured hostnames to the private virtual IP.

    Key points from the internal-mode behavior:

    • None of the API Management endpoints are registered in public DNS; they remain inaccessible until DNS is configured for the VNet.
    • The service does not listen on its IP address directly; it only responds to requests sent to the configured hostnames (for example, contosointernalvnet.developer.azure-api.net, custom domains, etc.).
    • In internal mode, inbound access depends entirely on customer‑managed DNS and network routing.

    From the documented pattern, a supported way to expose the developer portal and management endpoint externally is:

    1. Ensure external clients resolve the same hostnames (default or custom) that APIM is configured with.
    2. Those hostnames must resolve (via public or corporate DNS) to a front end (for example, Application Gateway, or in this case F5) that then forwards traffic to the APIM private VIP.
    3. The front end must preserve the original Host header/SNI so that APIM sees the request as addressed to its configured hostname. APIM will not respond correctly if the host header does not match its endpoint configuration.

    The documentation explicitly notes for internal mode:

    • “The API Management service does not listen to requests on its IP addresses. It only responds to requests to the hostname configured on its endpoints.”
    • Default internal-mode endpoints are host-based, for example:
      • contosointernalvnet.azure-api.net (gateway)
      • contosointernalvnet.portal.azure-api.net (legacy portal)
      • contosointernalvnet.developer.azure-api.net (new portal)
      • contosointernalvnet.management.azure-api.net (management)
      • contosointernalvnet.scm.azure-api.net (Git)

    For DNS in internal mode, the recommended approach is:

    • Create DNS records for the full FQDNs only, pointing to the APIM private virtual IP.
    • If using Azure Private DNS, scope the zone to the specific FQDNs (for example, contosointernalvnet.developer.azure-api.net), not the apex azure-api.net.
    • These records must be resolvable from all VNets and on‑premises networks that require access to APIM.

    Applied to an F5 front end:

    • F5 must accept TLS for the same hostnames that APIM is configured with (or custom domains configured on APIM).
    • F5 must forward traffic to the APIM private VIP on 443.
    • F5 must preserve the Host header and SNI so APIM sees the original hostname.
    • Client DNS must resolve the portal/management FQDNs to the F5 virtual server IP, not directly to the APIM private IP.

    If these conditions are met, a jump VM is not inherently required by the platform for publishing or accessing the developer portal; the requirement to use a jump VM usually indicates that either DNS resolution, host header/SNI preservation, or routing from the external network through the front end to the APIM private VIP is not aligned with the documented internal‑mode behavior.

    There is no separate, special “initial publish” path documented that must bypass a reverse proxy; the same hostname-based access model applies to the developer portal and management endpoint in internal mode.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer