Logic App Standard Unable to Connect to Azure Service Bus (Standard SKU) with Azure Firewall Egress and IP Restrictions

Question

Logic App Standard Unable to Connect to Azure Service Bus (Standard SKU) with Azure Firewall Egress and IP Restrictions

Sumit Gaur 475

Hi,

We have an Azure Service Bus Namespace (Standard SKU) configured with IP filtering, allowing traffic only from our Azure Firewall public IP address.

Our network configuration is as follows:

A UDR is associated with the Logic App Standard subnet, routing all outbound internet traffic through Azure Firewall.

WEBSITE_VNET_ROUTE_ALL is enabled on the Logic App Standard to ensure all outbound traffic is forced through the virtual network.

Despite this configuration, our Logic App fails to connect to Service Bus and returns the following error:

{
  "statusCode": "InternalServerError",
  "body": {
    "code": "ServiceProviderActionFailed",
    "message": "The service provider action failed with error code 'ServiceOperationFailed' and error message 'Put token failed. status-code: 401, status-description: Ip has been prevented to connect to the endpoint.'"
  }
}

Troubleshooting performed

Verified from the Kudu Console by calling a public IP discovery service (e.g. https://ipconfig.me).

The returned IP address matches the Azure Firewall Public IP, confirming that outbound internet traffic from the Logic App is being SNAT-ed through the firewall.

Confirmed that WEBSITE_VNET_ROUTE_ALL is enabled.

Reviewed the Service Bus diagnostic logs in Log Analytics, but they do not provide enough information to identify why the connection is being rejected or which source IP the traffic is coming from.

Given the above, I would have expected Service Bus to see the Azure Firewall public IP, which is already included in the namespace IP allow list.

Has anyone encountered this scenario before, or are there additional logs or diagnostics that can be used to determine which IP address Service Bus is actually evaluating for the connection request?

Any guidance would be appreciated.

0 comments

Answer recommended by moderator

Sumit Gaur 475

Hi All,

We have identified and resolved the issue.

The problem was with the IP address format configured in the IP Filtering settings of the Service Bus namespace. The IP was specified using CIDR notation (e.g., 20.x.x.x/32), which was causing the traffic to be blocked. After updating the rule to use the standalone IP address (without the /32 suffix), the traffic was allowed successfully, and the Logic App is now working as expected.

we also identified that few VNETs has service bus endpoint which we also remove to ensure there is no issue there.

0 comments

4 additional answers

Your answer

Answer 1

Hi @Sumit Gaur

Thank you for reaching out to Microsoft Q&A.

I'm glad to hear that the issue has been resolved.

After you investigated the problem, it was determined that the root cause was related to the IP Filtering configuration on the Azure Service Bus namespace. The allowed IP address was configured using CIDR notation (for example, 20.x.x.x/32), which resulted in the traffic being blocked. Once the rule was updated to use the standalone IP address without the /32 suffix, traffic was successfully allowed and the Logic App was able to connect to the Service Bus as expected.

Additionally, during the troubleshooting process, you identified that a few V-Nets had Service Bus Service Endpoints enabled. These configurations were also removed to eliminate any potential networking conflicts and ensure that traffic was routed as intended.

Resolution Summary:

Updated the Service Bus IP Filter rule to use the standalone IP address instead of CIDR notation (/32).
Removed unnecessary Service Bus Service Endpoints from the associated V-Nets.
Verified connectivity after the changes and confirmed that the Logic App is now functioning correctly.

Many thanks you for sharing the resolution. Hopefully, this information helps other community members who encounter a similar issue.

Answer 2

Hi @Sumit Gaur ,

Based on what others have pointed out, there are two main possibilities: the first is that the Logic App is using the Shared (managed) Service Bus connector, which runs outside your VNet and therefore won’t use your Azure Firewall public IP; the second is that even with VNet integration, the actual SNAT/egress IP seen by Service Bus may differ from what Kudu reports due to platform-level routing.

A third point to consider is that Service Bus Standard relies only on IP filtering, so any slight mismatch or additional outbound path (connector runtime, platform SNAT, or secondary egress) will result in a 401 deny unless all possible source IPs are explicitly allowed or you move to Private Endpoint with Premium.

Please upvote and accept the answer if it helps!!

Answer 3

Hi @Sumit Gaur

Thanks for sharing the detailed troubleshooting, this is a very good write-up, and we appreciate you reaching out to Microsoft Q&A.

What you are seeing is possible even when a public IP check from Kudu shows the Azure Firewall PIP.

In Service Bus Standard, network controls are IP filtering only; Trusted Services bypass is not available in Standard.
Service endpoints/private endpoints for Service Bus are Premium-tier capabilities.
The Service Bus firewall evaluates the client IP for each connection and rejects non-allowed IPs as unauthorized (the 401 text you shared matches this behavior).

To identify the exact IP being evaluated by Service Bus, enable and query the Service Bus VNet/IP filtering logs:

Category: VNetAndIPFilteringLogs (or resource-specific AZMSVNetConnectionEvents)
Fields include: IPAddress/AddressIP, Action (Accept/Deny), and Reason

If this log shows a source IP different from your expected firewall PIP, add that egress IP path to the allow list (or make egress deterministic through your firewall design).

Given your architecture, two supported patterns are:

Stay on Standard and maintain complete/accurate IP allow-list coverage for all possible egress source IPs.
Move Service Bus to Premium and use private networking (service endpoints/private endpoints) for deterministic network isolation.

Also validate that route-all is applied as intended (App Service/Logic App Standard docs note route-all behavior and that routed traffic is then subject to NSG/UDR).Thanks for sharing the detailed troubleshooting, this is a very good write-up.

What you are seeing is possible even when a public IP check from Kudu shows the Azure Firewall PIP.

In Service Bus Standard, network controls are IP filtering only; Trusted Services bypass is not available in Standard.
Service endpoints/private endpoints for Service Bus are Premium-tier capabilities.
The Service Bus firewall evaluates the client IP for each connection and rejects non-allowed IPs as unauthorized (the 401 text you shared matches this behavior).

To identify the exact IP being evaluated by Service Bus, enable and query the Service Bus VNet/IP filtering logs:

Category: VNetAndIPFilteringLogs (or resource-specific AZMSVNetConnectionEvents)
Fields include: IPAddress/AddressIP, Action (Accept/Deny), and Reason

If this log shows a source IP different from your expected firewall PIP, add that egress IP path to the allow list (or make egress deterministic through your firewall design).

Given your architecture, two supported patterns are:

Stay on Standard and maintain complete/accurate IP allow-list coverage for all possible egress source IPs.
Move Service Bus to Premium and use private networking (service endpoints/private endpoints) for deterministic network isolation.

Also validate that route-all is applied as intended (App Service/Logic App Standard docs note route-all behavior and that routed traffic is then subject to NSG/UDR).

To confirm root cause, please correlate the failed workflow timestamp with Service Bus VNet/IP filtering deny logs and verify the exact evaluated source IP, because environments with multiple egress paths or multiple firewall public IPs can produce an IP different from the one seen in a generic outbound IP check.

Evidence

Configure IP firewall rules for Azure Service Bus (Standard supports IP filtering; Standard does not include Trusted Services; IP filter deny behavior): https://learn.microsoft.com/azure/service-bus-messaging/service-bus-ip-filtering
Configure network service endpoints for Azure Service Bus (VNet service endpoints are Premium-only): https://learn.microsoft.com/azure/service-bus-messaging/service-bus-service-endpoints
Integrate your app with an Azure virtual network (all-traffic routing behavior and routing notes for App Service/Logic App Standard platform): https://learn.microsoft.com/azure/app-service/overview-vnet-integration
App Service environment variables reference (WEBSITE_VNET_ROUTE_ALL behavior): https://learn.microsoft.com/azure/app-service/reference-app-settings#networking
Azure Service Bus monitoring data reference (VNet/IP filtering logs include client IP, Action, Reason): https://learn.microsoft.com/azure/service-bus-messaging/monitor-service-bus-reference#resource-logs
Monitor Azure Service Bus (example KQL for deny connection events in AZMSVNetConnectionEvents): https://learn.microsoft.com/azure/service-bus-messaging/monitor-service-bus#kusto-queries

Please upvote and accept as "answer" as this helps others in the community with similar issues.

Best regards,

Andrew Taylor

Answer 4

Hello Sumit Gaur,

Welcome to Microsoft Q&A,

This is very likely a connector type mismatch rather than a firewall or routing problem.

Logic Apps Standard has two separate Service Bus connectors:

Built-in (In app): runs inside your Logic App's own process and respects VNet integration, your UDR, and WEBSITE_VNET_ROUTE_ALL. Its traffic genuinely flows through your Azure Firewall.
Shared (managed): runs in Microsoft's separate multitenant connector infrastructure. Even with VNet integration enabled on your Logic App, this connector's calls to Service Bus originate from Microsoft's shared connector IPs, not from your Firewall's public IP. It never touches your VNet integration at all.

Check which one your workflow action is using. In the designer, built-in connectors appear under the In app group, and managed connectors appear under Shared. If you're using the Shared Service Bus connector, that's the mismatch: your Firewall public IP check from Kudu is correct, but irrelevant to this specific connector's traffic path, since it never goes through your network.

Switch the action to the built-in Service Bus connector. Remove the existing Shared connector action and re-add the same operation from the In app group instead. This will route through your VNet integration and Firewall as you originally expected.

If you need to keep the managed connector, add the documented outbound IP addresses for managed connectors in your Logic App's region to the Service Bus IP allow list, alongside your Firewall IP. These are published at the managed connectors outbound IP addresses page and are region-specific service tags (AzureConnectors.<Region>).

Please Upvote and accept the answer if it helps!!