Firewall egress acls needed for a self-hosted gateway connecting to APIM's management plane

Question

Firewall egress acls needed for a self-hosted gateway connecting to APIM's management plane

Abhishek Bose 0

Hello Team,

We are deploying an APIM self-hosted gateway (v2.11.0) into an air-gapped L3.5 OpenShift cluster in a manufacturing environment. Our cloud APIM instance is deployed in internal mode within a VNet, so all endpoints resolve to private IPs. We have strict outbound firewall controls on the OpenShift nodes and need to define the minimum set of rules to allow the self-hosted gateway to function correctly.

Based on the documentation at https://learn.microsoft.com/en-us/azure/api-management/self-hosted-gateway-overview#connectivity-to-azure, we understand the gateway needs outbound connectivity to the configuration endpoint for config sync, status reporting, and metrics. We have a few specific questions:

Minimum required destinations — is it sufficient to open outbound TCP 443 only to the private IP of the configuration endpoint (e.g. <instance>.configuration.azure-api.net resolving to its private IP), or does the gateway also need connectivity to other IPs within the APIM private subnet to function correctly?
Stability of the configuration endpoint IP — assuming we do not redeploy the APIM service or resize its subnet, can we treat the private IP of the configuration endpoint as stable for firewall rule purposes? Or is there any scenario where it could change without a redeployment?
Any additional endpoints — beyond the configuration endpoint, are there other outbound destinations the self-hosted gateway requires that we should account for in our firewall rules? Note that egress to Microsoft Entra endpoints (login.microsoftonline.com) is already permitted by default in our environment, so we are specifically looking to understand any remaining destinations such as Azure Monitor or other Azure service endpoints that may also be required.

Any guidance on scoping these rules as tightly as possible would be greatly appreciated.

Thanks,

Abhishek Bose

Abhishek Bose 0 Reputation points

2026-04-06T02:53:04.4233333+00:00
Thanks Pravallika for your response.

A follow up question would be, is the private ip of the below endpoints same when APIM is deployed in internal mode. Because I can see only one private Vip address and I have locally mapped that ip to the configuration endpoint in my helm values because the private configuration endpoint host isn't DNS resolvable from outside APIM. But I can't seem to find the other two, unless those two can also be pointing to the same private vip address.

<your-apim>.configuration.azure-api.net (config sync)

<your-apim>.management.azure-api.net (status reporting & metrics)

<your-apim>.gateway.azure-api.net (runtime metadata and token validation)

Thanks

Abhishek Bose
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-06T10:19:45.41+00:00
@Abhishek Bose In internal mode, your APIM instance front-ends (configuration.azure-api.net, management.azure-api.net and gateway.azure-api.net) all live behind the same private VIP in your VNet. They’re simply different hostnames routed via that one IP. So for firewall purposes you only need to allow outbound TCP 443 to that single private VIP to cover:

Configuration sync ( *.configuration.azure-api.net )

Status reporting & metrics ( *.management.azure-api.net )

Runtime metadata & token validation ( *.gateway.azure-api.net )

That VIP remains stable unless you delete/recreate the APIM instance, resize or move the subnet/VNet. Normal service updates or scaling won’t change it.
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-07T01:09:21.2933333+00:00

@Abhishek Bose ,following up to see if the above provided information was helpful. Please let me know if you have any questions.
Abhishek Bose 0 Reputation points

2026-04-07T01:12:27.1533333+00:00

I'm good, thanks for your quick responses .We are going to test by pointing to the private ip only, instead of the entire subnet. But you can mark this question as closed, if needed I'll open a case #.
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-07T01:15:33.3533333+00:00

@Abhishek Bose , Thanks for the confirmation. I have posted the answer, please review and if this answers your query, do click Accept Answer =>Yes, and upvote it. If you have any further queries do let us know.

Answer accepted by question author

1 additional answer

Your answer

Abhishek Bose 0 Reputation points

2026-04-06T02:53:04.4233333+00:00

Thanks Pravallika for your response.

A follow up question would be, is the private ip of the below endpoints same when APIM is deployed in internal mode. Because I can see only one private Vip address and I have locally mapped that ip to the configuration endpoint in my helm values because the private configuration endpoint host isn't DNS resolvable from outside APIM. But I can't seem to find the other two, unless those two can also be pointing to the same private vip address.

<your-apim>.configuration.azure-api.net (config sync)

<your-apim>.management.azure-api.net (status reporting & metrics)

<your-apim>.gateway.azure-api.net (runtime metadata and token validation)

Thanks

Abhishek Bose
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-06T10:19:45.41+00:00

@Abhishek Bose In internal mode, your APIM instance front-ends (configuration.azure-api.net, management.azure-api.net and gateway.azure-api.net) all live behind the same private VIP in your VNet. They’re simply different hostnames routed via that one IP. So for firewall purposes you only need to allow outbound TCP 443 to that single private VIP to cover:

Configuration sync ( *.configuration.azure-api.net )

Status reporting & metrics ( *.management.azure-api.net )

Runtime metadata & token validation ( *.gateway.azure-api.net )

That VIP remains stable unless you delete/recreate the APIM instance, resize or move the subnet/VNet. Normal service updates or scaling won’t change it.
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-07T01:09:21.2933333+00:00

@Abhishek Bose ,following up to see if the above provided information was helpful. Please let me know if you have any questions.
Abhishek Bose 0 Reputation points

2026-04-07T01:12:27.1533333+00:00

I'm good, thanks for your quick responses .We are going to test by pointing to the private ip only, instead of the entire subnet. But you can mark this question as closed, if needed I'll open a case #.
Pravallika KV 12,730 Reputation points Microsoft External Staff Moderator

2026-04-07T01:15:33.3533333+00:00

@Abhishek Bose , Thanks for the confirmation. I have posted the answer, please review and if this answers your query, do click Accept Answer =>Yes, and upvote it. If you have any further queries do let us know.

Answer 1

Hi @Abhishek Bose ,

Thanks for reaching out to MicrosoftQ&A.

Your self-hosted gateway primarily needs outbound HTTPS (TCP 443) only to your APIM instance’s private endpoints plus a handful of Azure service endpoints for auth/telemetry.

Here’s how you can scope it down:

Minimum required destinations
- <your-apim>.configuration.azure-api.net (config sync)
- <your-apim>.management.azure-api.net (status reporting & metrics)
- <your-apim>.gateway.azure-api.net (runtime metadata and token validation) Each of these will resolve to a private IP in your APIM VNet/subnet. You can lock your firewall to TCP 443 solely to those three IPs rather than opening the entire subnet.
IP stability
- Those private IPs are “sticky” as long as you don’t delete/recreate the APIM instance, resize the subnet, or move the service to a different VNet. Normal updates or scaling operations won’t change them. If you need absolute certainty, you can periodically verify DNS→IP mapping or leverage Azure Resource Manager templates to pin the subnet.
Other outbound endpoints to consider
- login.microsoftonline.com / login.windows.net (Azure AD token issuance)
- management.azure.com (if your gateway uses the ARM API for any management-plane calls)
- Azure Monitor/Application Insights ingestion (if you’ve hooked up App Insights – e.g. *.monitoring.azure.com or dc.applicationinsights.azure.com)
- Azure Key Vault (vault-name.vault.azure.net) if you’re fetching secrets/certs
- Azure Storage/*.core.windows.net if you’re writing any diagnostic blobs or using the cache store

Hope that helps!

References:

Hope this helps!

If the resolution was helpful, kindly take a moment to click on User's image and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

Minimum required destinations For a basic self-hosted gateway deployment, the only mandatory outbound destination is the configuration endpoint of the API Management instance:

<api-management-service-name>.configuration.azure-api.net (or the custom hostname if used)
TCP port 443

The documentation explicitly lists this as the required endpoint for configuration sync, status reporting, and metrics. No requirement is stated for connectivity to other IPs in the APIM subnet for core gateway functionality.

When the APIM instance is in internal mode, this hostname resolves to a private IP. Firewall rules can therefore be scoped to:

Source: self-hosted gateway nodes/pods
Destination: private IP corresponding to <instance>.configuration.azure-api.net (or its private FQDN)
Port: 443/TCP

Other endpoints in the APIM VNet/subnet are not listed as required for the self-hosted gateway to operate.

Stability of the configuration endpoint IP The documentation does not describe any additional IPs or dynamic IP behavior for the configuration endpoint beyond the hostname itself. It treats the configuration endpoint as a single hostname per APIM instance (<api-management-service-name>.configuration.azure-api.net or a custom hostname).

Because the guidance is hostname-based, firewall design should ideally allow outbound by FQDN (or via a proxy) rather than relying on a fixed IP. The documentation does not guarantee that the private IP behind the configuration endpoint will never change, so firewall rules should not assume IP immutability; they should be prepared for potential IP changes even if the APIM service and subnet are not redeployed.

Additional endpoints The following outbound destinations are optional and only required if the corresponding features are used:

Azure Storage (for some logging/backup scenarios):
- Public IP addresses of the Azure Storage service tag (primary location)
- Hostname of the Azure Blob Storage account: <blob-storage-account-name>.blob.core.windows.net
- Hostname of the Azure Table Storage account: <table-storage-account-name>.table.core.windows.net
Azure Resource Manager (management APIs):
- management.azure.com
Microsoft Entra integration:
- <region>.login.microsoft.com
- login.microsoftonline.com (already allowed in the described environment)
Azure Application Insights / Azure Monitor integration:
- rt.services.visualstudio.com:443
- dc.services.visualstudio.com:443
- {region}.livediagnostics.monitor.azure.com:443
Event Hubs integration (if used): endpoints as documented in Azure Event Hubs network security guidance
External cache integration (if used): depends on the external cache endpoint(s)

If the goal is to scope egress as tightly as possible:

Mandatory: allow TCP 443 from the self-hosted gateway to the configuration endpoint hostname (or its private IP if using IP-based rules).
Optional: only add the Azure Storage, Azure Resource Manager, Application Insights/Azure Monitor, Event Hubs, or external cache endpoints if those specific integrations are enabled and required for the deployment.

References:

Share via

Firewall egress acls needed for a self-hosted gateway connecting to APIM's management plane

1 additional answer

Your answer