| author | dlepow |
|---|---|
| ms.service | azure-api-management |
| ms.topic | include |
| ms.date | 11/29/2023 |
| ms.author | danlep |
Forced tunneling lets you redirect or "force" all internet-bound traffic from your subnet back to on-premises for inspection and auditing. Commonly, you configure and define your own default route (0.0.0.0/0), forcing all traffic from the API Management subnet to flow through an on-premises firewall or to a network virtual appliance. This traffic flow breaks connectivity with API Management, since outbound traffic is either blocked on-premises, or NAT'd to an unrecognizable set of addresses that no longer work with various Azure endpoints. You can solve this issue via the following methods:
-
Enable service endpoints on the subnet in which the API Management service is deployed for:
- Azure SQL (required only in the primary region if the API Management service is deployed to multiple regions)
- Azure Storage
- Azure Event Hubs
- Azure Key Vault
By enabling endpoints directly from the API Management subnet to these services, you can use the Microsoft Azure backbone network, providing optimal routing for service traffic. If you use service endpoints with a force tunneled API Management, traffic for the preceding Azure services isn't force tunneled. However, the other API Management service dependency traffic remains force tunneled. Ensure that your firewall or virtual appliance doesn't block this traffic, or the API Management service may not function properly.
[!NOTE] We strongly recommend enabling service endpoints directly from the API Management subnet to dependent services such as Azure SQL and Azure Storage that support them. However, some organizations may have requirements to force tunnel all traffic from the API Management subnet. In this case, ensure that you configure your firewall or virtual appliance to allow this traffic. You will need to allow the complete IP address range of each dependent service, and keep this configuration up to date when the Azure infrastructure changes. Your API Management service may also experience latency or unexpected timeouts because of the force tunneling of this network traffic.
-
All the control plane traffic from the internet to the management endpoint of your API Management service is routed through a specific set of inbound IPs, hosted by API Management, encompassed by the ApiManagement service tag. When the traffic is force tunneled, the responses won't symmetrically map back to these inbound source IPs and connectivity to the management endpoint is lost. To overcome this limitation, configure a user-defined route (UDR) for the ApiManagement service tag with next hop type set to "Internet", to steer traffic back to Azure.
[!NOTE] Allowing API Management management traffic to bypass an on-premises firewall or network virtual appliance isn't considered a significant security risk. The recommended configuration for your API Management subnet allows inbound management traffic on port 3443 only from the set of Azure IP addresses encompassed by the ApiManagement service tag. The recommended UDR configuration is only for the return path of this Azure traffic.
-
(External VNet mode) Data plane traffic for clients attempting to reach the API Management gateway and developer portal from the internet will also be dropped by default because of asymmetric routing introduced by forced tunneling. For each client that requires access, configure an explicit UDR with next hop type "Internet" to bypass the firewall or virtual network appliance.
-
For other force tunneled API Management service dependencies, resolve the hostname and reach out to the endpoint. These include:
- Metrics and Health Monitoring
- Azure portal diagnostics
- SMTP relay
- Developer portal CAPTCHA
- Azure KMS server
For more information, see Virtual network configuration reference.