How to route cross-tenant traffic through Azure Firewall to Azure Event Hub (FQDN required, Private Endpoint ruled out)

Question

How to route cross-tenant traffic through Azure Firewall to Azure Event Hub (FQDN required, Private Endpoint ruled out)

Suki Azure 66

Hi all,

We are currently exploring secure cross-tenant connectivity to an Azure Event Hub instance, and we would appreciate guidance on the best way to route traffic through Azure Firewall.

Current Setup:

Azure Event Hub is deployed in Tenant A and currently accessible via its public endpoint (<namespace>.servicebus.windows.net)

We are able to connect to it from a VM in Tenant B when the public IP is whitelisted in the Azure Event Hub's integrated firewall

However, for security and logging purposes, we would prefer to route traffic through Azure Firewall in Tenant A, instead of allowing direct public access

Constraints:

Private Endpoint is ruled out

VNet Peering and Site-to-Site VPN are also not allowed due to network segregation policies

We attempted to create a DNAT rule in Azure Firewall, forwarding traffic from its public IP to the Event Hub FQDN on port 5671 (AMQP over TLS). While the TCP connection works, the SSL handshake fails — likely because Event Hub expects the client to connect using its original FQDN due to TLS certificate name validation.

Questions:

Is there any supported way to force traffic from Tenant B to go through Azure Firewall to access the Event Hub in Tenant A, ?
Is it possible to assign a public FQDN to Azure Firewall (e.g., via Azure DNS or public domain), and use it to forward traffic transparently to Event Hub?

Addiitonally what are all the Security Measures can be considered part of using Azure eventhub integrated firewall We considered so far:

Enforce TLS 1.2+ on all Event Hub communications

Use SAS tokens scoped by namespace or Event Hub

Restrict source IPs in Event Hub firewall (only trusted IPs)

Enable diagnostic logs to Log Analytics / Sentinel Any guidance or alternative architecture recommendations would be highly appreciated.

2 answers

Your answer

Answer 1

Hello Suki Azure,

Thank you for posting your question in the Microsoft Q&A forum.

To enable secure access from Tenant B to Event Hub in Tenant A while routing traffic through Azure Firewall, consider a DNS-based forwarding approach with SNI preservation. Assign a custom public FQDN (e.g., eventhub-proxy.contoso.com) to Azure Firewall’s public IP and configure Layer 7 application rules (not DNAT) to forward traffic to Event Hub’s original FQDN (namespace.servicebus.windows.net) while preserving the TLS handshake. This ensures certificate validation succeeds without exposing Event Hub directly.

If SNI preservation is insufficient, deploy a reverse proxy (Nginx/HAProxy) behind Azure Firewall to terminate and re-encrypt TLS while rewriting the Host header. For enhanced security, combine this with IP whitelisting, SAS token authentication, and Azure Sentinel logging. While Private Link or ExpressRoute would be ideal, they are ruled out here making DNS-based routing with Azure Firewall the most viable option. Always validate performance impact and compliance requirements before implementation.

For detailed guidance, refer to Microsoft’s documentation below:

https://learn.microsoft.com/en-us/azure/firewall/features#application-fqdn-filtering

https://learn.microsoft.com/en-us/security/benchmark/azure/baselines/event-hubs-security-baseline

If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue. Your contribution to the Microsoft Q&A community is highly appreciated.

Suki Azure 66 Reputation points

2025-05-12T02:57:54.4666667+00:00

@Suwarna S Kale Before proceeding with a public domain configuration, I attempted to simulate the setup by adding a host file entry on the source VM in Tenant B — mapping the Azure Firewall public IP to the Event Hub FQDN (e.g., namespace.servicebus.windows.net). In parallel, I configured an Azure Firewall application rule to allow outbound traffic on port 443 to the Event Hub FQDN.

However, despite this setup, I’m still encountering a TLS handshake failure from the .NET Event Hub SDK client.

Appreciate your continued guidance.

Answer 2

Shravan Addagatla 690 Microsoft External Staff Moderator

Hello @Suki Azure

In addition to Suwarna S Kale's response, I am adding a few points as outlined below.

As you mentioned that you want to connect Azure Event Hub in Tenant A from a VM in Tenant B through Azure Firewall in Tenant A, the recommended approach is to create a User Defined Route (0.0.0.0/0 -> Next Hop to Azure Firewall) on the VM Subnet in Tenant B. This will force the traffic to Azure Firewall in Tenant A via VNet peering. Additionally, create an application rule on the Azure Firewall to allow the traffic to Azure Event Hub.

Since you mentioned that Private Endpoint, VNet Peering, and Site-to-Site VPN are not allowed due to network segregation policies, creating a DNAT rule in Azure Firewall and forwarding the traffic from the VM public IP to the Event Hub FQDN through the Firewall would be the best option.

However, I replicated the same scenario and successfully connected to the Azure Event Hub using the Azure Firewall DNAT rule, as shown in the screenshot below.

Azure Firewall DNAT Rule User's image

You need to configure your own DNS server on the VNet to forward DNS queries to the appropriate endpoint. I used the Host file on the Azure VM to test this scenario.
User's image

Whitelisted Azure Firewall public IP on the Azure Event Hub

User's image

To enhance security, consider adding layers such as IP whitelisting and SAS token authentication, alongside logging to Azure Monitor or Azure Sentinel.

Regarding general security for Azure Event Hub, your current measures (TLS enforcement, SAS token usage, IP restriction, enabling Azure Defender for threat detection, implementing NSGs to restrict access, using Service Tags for firewall rules, and logging) are robust.

Refer these articles:

https://learn.microsoft.com/en-us/azure/azure-monitor/logs/workspace-design
https://learn.microsoft.com/en-us/azure/sentinel/connect-services-diagnostic-setting-based

I hope this has been helpful!

If above is unclear and/or you are unsure about something add a comment below.

Please click "Accept" the answer, if any answer/reply helped, so that others in the community facing similar issues can easily find the solution. This can be beneficial to other community members.

Suki Azure 66 Reputation points

2025-05-12T02:25:13.1733333+00:00

@Shravan Addagatla Thank you for your prompt response and for outlining the various options. As there were several suggestions, I’ve opted to proceed with the DNAT-based approach for now, as the necessary configurations and rules are already in place on our side.

To validate the connectivity, I’ve deployed a new Azure VM in a separate tenant, configured specifically for testing. The Azure Firewall DNAT rule is set to translate requests from the firewall’s public IP on port 443 to the Event Hub FQDN on port 443.

During initial testing:

Using browser-based https:// access or basic connection checks, the traffic appears to reach the Event Hub successfully via the firewall.

However, while testing the .NET SDK-based client connection (based on the Microsoft documentation here: https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-dotnet-standard-getstarted-send?tabs=passwordless%2Croles-azure-portal), I’m encountering the following issue:

Error: System.TimeoutException: Creation of RequestResponseAmqpLink did not complete in 0 milliseconds at various points in the EventHubConnection.GetPropertiesAsync() and EventProcessorClient.StartProcessingAsync() methods.

Please advise if there are any specific configurations (e.g., SNI passthrough, DNS overrides, or SDK-level overrides) that can be applied to address this, or if a reverse proxy approach is unavoidable in such scenarios.
Shravan Addagatla 690 Reputation points Microsoft External Staff Moderator

2025-05-12T11:09:45.6233333+00:00
Hi Suki Azure

It appears that your .NET SDK-based client is encountering a system.TimeoutException while attempting to establish an AMQP link with Azure Event Hubs. This issue might be due to port restrictions or SDK configuration settings. Here are some troubleshooting steps:

Ensure that AMQP ports (5671, 5672) are open in your firewall and NSG settings. If your network blocks these ports, try switching to AMQP WebSockets, which uses port 443. You can refer this article for similar issue. https://stackoverflow.com/questions/78453809/eventprocessorclient-fails-to-start-processing-eventhub-messages-creation-of-r

Increase the TryTimeout value in your SDK configuration to allow more time for the connection.

If none of the solutions work, it's advisable to check the logs on Event Hub to diagnose the problem. It would be helpful to seek assistance from the Event Hub team. You can open a new query with the Event Hub team for this type of error message, since you mentioned the traffic was reaching the Event Hub successfully via the firewall.
Shravan Addagatla 690 Reputation points Microsoft External Staff Moderator

2025-05-13T08:40:47.9233333+00:00

Hi Suki Azure

Just checking in to see if above information was helpful. If you have any further questions on this issue, please let me know.
Suki Azure 66 Reputation points

2025-05-13T10:26:25.6066667+00:00

Thanks for your support. I’ve now switched the protocol to AMQP over WebSockets, and the connection appears to be stable. Based on our current setup—where we use a hosts file entry mapping the Azure Firewall public IP to the Event Hub FQDN, along with a DNAT rule forwarding port 443 to the Event Hub FQDN—we’re seeing successful connectivity from the Azure VM to Event Hub over port 443.

That said, I have a few follow-up questions before considering this approach for production:

Are there any limitations or best practice concerns with using port 443 (AMQP over WebSockets) instead of 5671 (native AMQP) for production workloads?

Would it be advisable to set up a custom domain with DNS forwarding, or is it acceptable to maintain manual host file entries across the ~5 source VMs?

Despite the traffic flowing through Azure Firewall, I don’t see any logs in Log Analytics Workspace. All diagnostic categories have been enabled. Could you advise on what might be missing or misconfigured to get visibility into this traffic?

Appreciate your insights.
Shravan Addagatla 690 Reputation points Microsoft External Staff Moderator

2025-05-13T15:19:42.06+00:00
Hi Suki Azure

As far as I know, here are some considerations when using port 443 (AMQP over WebSockets) instead of port 5671 (native AMQP) for production workloads:

Limitations

WebSocket's introduce additional latency compared to native AMQP over TCP (port 5671), which can impact high-throughput messaging scenarios.

While WebSocket's are useful for environments where direct TCP connections are blocked and this could sometimes lead to unstable the connections.

AMQP over WebSocket's requires additional tunneling, which can add complexity to debug.

Best Practices

Use Native AMQP When Possible: If your network allows direct TCP connections, prefer port 5671 for better performance and lower overhead.

If using port 443, ensure proper connection pooling and keep-alive settings to maintain stability.

Conduct performance testing under production-like conditions to determine if WebSockets meet your workload requirements.

You can refer this article: amqp-protocol-guide#connections-and-sessions

Note: - Since you mentioned planning to move production, I recommend opening a new question to our EventHub team to confirm the details above, as I don't have much expertise on EventHub.

Would it be advisable to set up a custom domain with DNS forwarding, or is it acceptable to maintain manual host file entries across the ~5 source VMs?

Using a custom domain with DNS forwarding is generally more scalable and manageable than maintaining manual host file entries across multiple VMs. Since you mentioned there are 5 VMs, so it is acceptable to use manual host file entries, which are more suitable for small-scale setups.

Despite the traffic flowing through Azure Firewall, I don’t see any logs in Log Analytics Workspace. All diagnostic categories have been enabled. Could you advise on what might be missing or misconfigured to get visibility into this traffic?

If you're unable to the logs, please ensure that diagnostic settings are correctly configured to send logs to the right Log Analytics Workspace.

Verify that the necessary log categories (such as AzureFirewallDNATRule and AzureFirewallApplicationRule) are selected.

Run queries in Log Analytics using Kusto Query Language (KQL) to check if logs are being ingested.

If logs are still missing, consider checking for structured logging settings and ensuring that firewall rules are actively generating traffic.

Refer the below articles:

https://learn.microsoft.com/en-us/answers/questions/2224617/all-logs-are-not-showing-in-the-log-analytics-work
https://learn.microsoft.com/en-us/answers/questions/1253575/not-receiving-firewall-diagnostic-data
Shravan Addagatla 690 Reputation points Microsoft External Staff Moderator

2025-05-14T13:37:36.4466667+00:00

Hi Suki Azure

Did you had a chance to review my last response. Thank you.

Please let me know if you have any questions on network side.

Share via

How to route cross-tenant traffic through Azure Firewall to Azure Event Hub (FQDN required, Private Endpoint ruled out)

2 answers

Your answer