Azure Application Gateway works from Azure VM but not from on-premises network

Question

Azure Application Gateway works from Azure VM but not from on-premises network

Henrique Faria 5

Description

I am experiencing a connectivity issue with Azure Application Gateway (v2) publishing an internal application.

The application is accessible without issues when accessed from a virtual machine inside Azure, but fails when accessed from the on-premises network, even though the same DNS name is used in both scenarios.

Scenario

Azure Application Gateway is used as a reverse proxy for an internal application

Access works correctly from Azure

Access fails from the on-premises network

The same FQDN/DNS name is used from both locations

Architecture (simplified)

On-premises network connected to Azure via Site-to-Site VPN

Azure Application Gateway (v2) publishing the application

Backend: internal virtual machine

DNS resolves the application FQDN to the private IP address of the Application Gateway

Traffic is HTTPS (TCP 443) end-to-end

Observed behavior

From an Azure VM:

DNS resolves correctly to the private IP of the Application Gateway

HTTPS access works as expected

From the on-premises network:

DNS resolves to the same private IP of the Application Gateway

Browser fails to establish the connection

Goal

I would like to understand why traffic originating from Azure works correctly while traffic from the on-premises network does not, and which configuration might need adjustment.

Any guidance, troubleshooting steps, or best-practice recommendations would be greatly appreciated.

0 comments

1 answer

Your answer

Answer 1

Thanmayi Godithi 10,385 Microsoft External Staff Moderator

Hi @Henrique Faria,

Thank you for reaching out on the Microsoft Q&A forum.

Since the same FQDN resolves to the private IP of the Application Gateway and access works without issues from an Azure VM but fails from the on‑premises network, this points to a network connectivity or security configuration issue between on‑premises and the Application Gateway subnet. DNS resolution and the backend application itself are unlikely to be the cause.

Below are the most common areas to review in this scenario:

1. Application Gateway subnet NSG

Even though traffic is coming over the VPN from on‑premises, it must still be explicitly allowed on the Application Gateway subnet.

Verify the NSG allows inbound TCP 443 from your on‑premises IP address ranges.
Check for any higher‑priority deny rules that might be blocking this traffic.

https://learn.microsoft.com/azure/application-gateway/configuration-infrastructure#network-security-groups

2. User‑Defined Routes (UDR) on the Application Gateway subnet

If a UDR is associated with the Application Gateway subnet, ensure that:

Return traffic to on‑premises is routed via the VPN gateway
It is not sent to Internet or a firewall/NVA without symmetric routing, which can cause silent connection failures.

https://learn.microsoft.com/azure/application-gateway/configuration-infrastructure#user-defined-routes

3. VPN routing and address space propagation

On the Site‑to‑Site VPN, please confirm that:

The Application Gateway subnet address range is included in the Local Network Gateway (on‑prem side)
The same address range appears in the effective routes within the Azure VNet
There is no CIDR overlap between on‑premises and Azure address spaces

https://learn.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpngateways

Why Azure access works

Access from an Azure VM succeeds because the traffic stays entirely within Azure, bypassing VPN routing, on‑premises firewalls, and return‑path constraints that can affect on‑prem connectivity.

Please let us know if the above helps or if you need any further assistance.
If this answer was helpful,please 'Accept the answer' and kindly consider upvoting it. For any follow‑up questions, feel free to leave a comment.

Henrique Faria 5 Reputation points

2025-12-22T11:38:57.3633333+00:00

Hi @Thanmayi G D ,

We identified that there is a firewall/NVA in the routing path associated with the Application Gateway subnet. Even after updating the UDR to route on-premises traffic via the Virtual Network Gateway, the issue persists when accessing the application from on-premises.

Given this, we suspect that the firewall in the return path may be causing asymmetric routing or interfering with HTTPS traffic between the Application Gateway and the on-premises network.

To validate this hypothesis, I would like to confirm with you:

Is it a recommended or valid troubleshooting step to temporarily disassociate the firewall/UDR from the Application Gateway subnet, allowing the subnet to rely only on system routes so that return traffic to on-premises flows directly via the VPN Gateway?

From a Microsoft best-practice perspective, should the Application Gateway subnet generally bypass firewall inspection for on-premises return traffic to avoid asymmetric routing issues?

This change would be temporary and used only to confirm whether the firewall is the root cause.

Thank you in advance for your guidance.

Regards,
Henrique Faria
Thanmayi Godithi 10,385 Reputation points Microsoft External Staff Moderator

2025-12-23T07:49:39.9066667+00:00

Hi @Henrique Faria,

Thank you for the detailed analysis — your approach and reasoning are absolutely on the right track.

Yes, temporarily disassociating the firewall/UDR from the Application Gateway subnet is a valid and recommended troubleshooting step. Allowing the subnet to rely solely on system routes ensures that return traffic to on-premises flows directly via the Virtual Network Gateway, which is an effective way to confirm or rule out asymmetric routing or firewall-related interference.

Application Gateway subnets are generally not intended to traverse firewalls/NVAs for on-premises return traffic. Because Application Gateway is a stateful Layer-7 service, introducing firewall inspection in the return path can lead to TLS state mismatches and silent connection failures, even when routing appears correct.

Using this change temporarily to validate whether the firewall is the root cause is a sound and well-justified diagnostic approach.

Kindly let me know once the testing is complete so we can proceed further.
Henrique Faria 5 Reputation points

2026-01-02T16:36:28.7866667+00:00

Hi @Thanmayi G D ,

Thank you for the detailed guidance.

As part of the troubleshooting, we did disassociate the Azure Firewall from the traffic path to validate whether it was causing any asymmetric routing. However, even after disassociating the firewall, the issue persisted when accessing the Application Gateway from the on-premises network.

During further analysis, we identified that some subnets are still missing association with the appropriate User-Defined Route (UDR) tables. This could impact the return path for on-premises traffic, especially over the Site-to-Site VPN.

At this moment, we have not yet been able to complete the connectivity tests after correcting these UDR associations. We are currently aligning the remaining route table configurations to ensure proper routing via the VPN Gateway.

Once the UDR associations are fully corrected and validated, we will proceed with additional tests and provide an update with the results.

Thank you for your continued support.

Regards,
Henrique Faria
Thanmayi Godithi 10,385 Reputation points Microsoft External Staff Moderator

2026-01-05T18:33:12.99+00:00

Hi @Henrique Faria,

Thank you for the update.

Your analysis is correct, missing or inconsistent UDR associations can still break the return path for on-premises traffic, even after removing the firewall from the flow. For S2S VPN scenarios, all involved subnets must consistently route on-premises prefixes to the Virtual Network Gateway.

Once the remaining UDRs are properly associated, please retest connectivity without the firewall in the path to establish a clean baseline. If it works, that will confirm the issue was routing consistency rather than Application Gateway itself.

Please share the results once testing is complete.

Please 'Accept the answer' and kindly consider upvoting it. For any follow‑up questions, feel free to leave a comment.

Share via

Azure Application Gateway works from Azure VM but not from on-premises network

Description

Scenario

Architecture (simplified)

Observed behavior

Goal

1 answer

Your answer