My idea is to connect a Application Gateway with a App Service in a single VNET, but I’m getting a 502 if I try to access my public IP.
I’ve been reading already this question but I cannot find how to solve my issue.
Right now I have this setup:
Main VNET
Subnet 1 -> Application gateway
Subnet 2 -> App Service
What I tried until now was this configuration using access restrictions on the app service using the public IP of the gateway and also the IP for the private VNET:
Even with this I’m having this 404 on the health probe.
Should I add in another way the APP Service to the VNET? Is this the good one? What am I doing wrong here?
2
Answers
I tried to replicate the same issue in my workaround and got the below results
I am able to access the app service using application gateway while restricting the IP address in the App service
I have followed the below steps to access the app service through application gateway using private endpoint
I have created the application gateway and configured the
I have created the private endpoint with same V-net
Created the virtual machine to access the app service
Connected the bastion service to check weather I am able to access the app service
Luckily because you are receiving a 404 that rules out several other potential causes related to reachability. In the image you provided for your Backend Settings, the "Override with New Hostname" switch is set to No, which means that whatever hostname you reach your App Gateway with will be passed as the hostname to your App Service. Typically, App Service uses a subdomain of *.azurewebsites.net and if you send either the wrong hostname or no hostname it will respond with a 404. You can test this by hitting your App Service by the IP address in the browser; you will receive a 404.
If you switch this to Yes, you have two options: You can opt to override the hostname with the FQDN from your Backend Pool, which in your case is an azurewebsites.net subdomain, or you can set this manually. Either should work in your case.
On top of this, you can configure a custom probe. If you do not see a probe listed, it’s because you are using the default, which sends a hostname of "127.0.0.1" to the backend pool member. This is the hostname being used to reach your App Service’s IP address which is likely why probes are failing with a 404.
By creating a custom probe you can opt to pick the hostname from the Backend Settings or use a custom one. You’ll also see you can adjust the range of acceptable status codes from the default 200-399. This can be useful in the future if you have a backend that requires authentication and returns a 401 Unauthorized as App Gateway probes are not capable of performing authentication.
Source Documentation on App Gateway probes: https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-probe-overview