An Azure service that provides a platform-managed, scalable, and highly available application delivery controller as a service.
Hello @heng yeow (nova)
Thanks for sharing the network configuration and screenshots.
Since your Application Gateway Standard_v2 and the VM hosting your HTML page are deployed in separate virtual networks, and you've already configured VNet peering, focus on the effective outbound NSG rule and connectivity to the destination VM.
The Outbound NSG diagnostic: Deny result suggests that an NSG rule is blocking the tested connection. However, we should identify the specific rule before making any changes.
1. Verify the outbound NSG rules
In the Azure portal, navigate to Network security groups > [Application Gateway subnet NSG] > Outbound security rules.
Check whether an explicit Deny rule takes precedence over the default Allow rules.
One important consideration is your Application Gateway deployment type:
- Standard_v2 without Network Isolation: Microsoft requires outbound Internet connectivity and does not support outbound NSG rules that deny connectivity.
- Application Gateway with Network Isolation enabled: More restrictive outbound NSG rules are supported, including rules that allow specific backend destinations.
For a Network Isolation-enabled deployment, you can configure an outbound Allow rule for the destination VM using the following values:
For a standard deployment without Network Isolation, avoid adding restrictive outbound Deny rules that conflict with Microsoft's documented Application Gateway requirements.
2. Verify connectivity across the peered VNets
Since you've already configured peering between fornaxNet and SPD-SIT-Network, check that both peering connections are established and that the relevant virtual network traffic is permitted.
Also verify the destination VM's NSG inbound rules. The VM must permit connections from the Application Gateway subnet on the port where the web server is listening.
VNet peering provides network connectivity, but it doesn't automatically override NSG restrictions.
3. Verify the backend web server
Confirm that the VM hosting the HTML page is running a web server and that the page is accessible using the VM's private IP address and configured HTTP/HTTPS port.
You can use Azure Network Watcher Connection Troubleshoot to test the destination VM's private IP and port.
If the test still reports Outbound NSG diagnostic: Deny, review the NSG rules affecting the tested source and destination before making further changes.
4. Check the custom error page configuration
Another important point about your intended design.
Azure Application Gateway custom error pages are configured using a publicly accessible URL to an HTML file. The gateway retrieves the file and stores it locally for use when displaying custom error responses.
Therefore, hosting the HTML page only on a private VM in a peered VNet doesn't satisfy the documented custom error page URL requirement.
If your goal is to configure a custom error page, consider hosting the static HTML file at a publicly accessible HTTPS endpoint, such as Azure Blob Storage, rather than relying on private VNet connectivity.
Additional clarification
Could you confirm:
- Is Network Isolation enabled on your Application Gateway Standard_v2 deployment?
- Which NSG rule is reported as denying the connection?
- Are you using the VM as a backend server, or only as the host for the custom error page?
This distinction is important because the networking requirements for backend connectivity and custom error page retrieval are different.
Hope this helps clarify the configuration.
References:
Application Gateway infrastructure configuration
Private Application Gateway deployment
Application Gateway custom error pages
Azure Network Watcher Connection Troubleshoot
Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.